Electronic Business: Concepts, Methodologies, Tools, and Applications (4-Volumes) P228 pptx

2204 Secure Authentication Process for High Sensitive Data E-Services )LJXUH7KHORJLQFRQ¿JXUDWLRQHQWU\LQWKHORJLQFRQ¿J[POIRUWKHDSSOLFDWLRQ )LJXUH7KH:HE[POFRQ¿JXUDWLRQ¿OHHQWU\GHFODULQJWKHORJLQIRUP 2205 Secure Authentication Process for High Sensitive Data E-Services Focusing on Pitagora’s Authentication process, DIWHUWKHGH¿QLWLRQRIWKH6HFXULW\'RPDLQWKH VHUYOHWVSHFL¿FDWLRQVGH¿QHDVWDQGDUGPHWKRGRI F R Q ¿ J X U L QJW KHORJ L QSURFHVVIR U :H E D S SOLFD W LRQV WKURXJKWKHVSHFL¿FDWLRQLQ7RPFDW¶V Web.xml ¿OHRIWKH85/RIWKHORJLQSDJHDQGWKHORJLQ error page (see Figure 3). By means of a standard JSP page, the user could insert login and password that was sent to WKHORJLQPRGXOHVSHFL¿HGLQWKH$&7,21WDJ ,Q WKLV FDVH WKHSUHGH¿QHGPHWKRGIRU VHUYOHW form-based authentication j_security_check, that accepted as parameters username (named j_username) and password (named j_password) DQGUHIHUUHGWRWKHVSHFL¿HG6HFXULW\'RPDLQ was used. This solution was, however, not fully satisfac- tory for the goals of the project. Albeit application server authentication gave some notable advan- tages, as for instance no need of code customiza- tion and clear separation between business and security components and high reliability levels, it raised a major problems: it did not allow dif- ferent implementations for different applications, binding all the services to an unique authentica- tion process. Logically different applications that, potentially, require different authentication mechanisms with different requirements can- not live with this solution that imposes a single authentication approach for all the applications deployed on the same application server. For this reason, also this solution was not adopted, since it did not provide a suitable envi- ronment for Pitagora’s applications. Component Level Authentication To conclude the roadmap, the most adopted solu- tion in current e-services scenario is described, relying on the insertion of components responsible for the authentication process at the top of the structure depicted in Figure 1. In this manner, there is a strict integration between business and security components and it is possible to customize the authentication process for single application needs. This solution implements a decentralized authentication mechanism that requires the inser- tion of customized code inside the business com- ponents to manage the communication protocols with the requestor, validate the received requestor F U H G H Q W L D O V Z L W K W K H X V H U S U R¿OHLQ IRU P D W L RQVWRUHG in the local user repositories, and allow or deny the access request. Also if this decentralized approach implied different security implementations focused on services goals and allowed ad-hoc security implementations for each service, there were many drawbacks that suggested refusing this solution: • increase of costs and time spent for logon to multiple services: for each service the XVHUKDGWRSURYLGHVHUYLFHVSHFL¿FFUHGHQ- tials; • username/password proliferation: for se - curity concerns, the user was stimulated to choose a different username/password for each service and, hence, she had to man- age, protect, and remember several of these information pairs; • increasing of administration cost and time: administrators had to deal with multiple SUR¿OHVUHSRVLWRULHVZLWKYDULDEOHVFKHPD and variable authentication policies; • usability problems: user had to interact with multiple logon interfaces. From the account management point of view, this approach required an independent manage- ment of accounts in each domain and the use of different authentication mechanisms. Several usability and security concerns had been raised, leading to a rethinking of the logon process aimed at co-ordinating and, where possible, integrating user logon mechanisms and user account manage- ment tools for different domains. The description of the most widespread meth- ods to implement an authentication infrastructure, 2206 Secure Authentication Process for High Sensitive Data E-Services suggested that an optimal solution had not been found out. In the following, the idea of adopting an emergent solution, named Single Sign-On, that seemed the most suitable approach for se- curing authentication processes in e-service, is put forward. SINGLE SIGN-ON: A SOLUTION FOR SECURING AUTHENTICATION PROCESS A service/architecture that provides the requested coordination and integration of access control pro- cesses is called Single Sign-On (SSO) (Galbraith et al. 2002; Single Sign-On, The Open Group, 2005) (see Figure 4). The advantages given by the introduction of SSO architecture in a pre-exist- ing multiservices intra-domain scenario could be summarized as follows: •reduction of: (1) time spent by the users dur- ing logon operations to individual domains, (2) failed logon transactions, (3) time used to logon to secondary domains, (4) costs DQGWLPHXVHGIRUXVHUVSUR¿OHVDGPLQLVWUD- tions; • improvement to users security: the user has to manage only a couple of username/pass- word;  VHFXUHDQGVLPSOL¿HGDGPLQLVWUDWLRQZLWK a centralized administration point, system administrators reduce the time spent to add and remove users to the system or modify their access rights (authorization); • improvement of security through the en - hanced ability of system administrators to maintain the integrity of user account con- ¿JXUDWLRQLQFOXGLQJWKHDELOLW\WRFKDQJH an individual user’s access to all system resources in a coordinated and consistent manner; • improvement of services usability. From the point of view of economic feasibil- ity, most available Return-On-Investment (ROI) Figure 4. User Single Sign-On to multiservice domain 2207 Secure Authentication Process for High Sensitive Data E-Services models available for SSO focus on cost reduction rather than on the alleviation of damages, for example, deriving from intrusions. While this is a rather conservative approach, experience has shown that even minor achievements like reduc- ing Help Desk calls by eliminating password SUREOHPVFDQJHQHUDWHVLJQL¿FDQWVDYLQJV6WXGLHV by Forrester Research (www.forrester.com) con- ¿UPWKDWHOLPLQDWLQJSDVVZRUGFKDRVFDQOLJKWHQ internal Help Desk burden by 50%. Anectodical evidence has been brought up of a case where a Single-Sign-On solutions eliminated 95% of all password-related support calls. Helping users gain quick, secure access to password-protected applications can save everyone many minutes of wasted time. Also, whenever sales force and executives travel, they still can get access to the applications they need. All these factors create a boost in productivity. Also, integration and main- tenance of SSOs being minimal, invest ments in existing infrastructure are preserved. The Total Cost of Ownership (TCO) for SSOs compares favorably with other solutions on the market. As clearly highlighted by the above list, many of the advantages provided by a SSO solution re- ÀHFWW KHG U D Z ED FN VU D L VH GE\WKHSUHY LRXVV ROXW LRQV based on security customization at component level. In the SSO approach, the primary domain is responsible for collecting and managing all user credentials and information used during the authentication process, both to the primary domain and to each of the secondary domains that the user may potentially require to interact with. This information is then used by Single Sign-On services within the primary domain to support the transparent authentication to each of the second- ary domains whereby the user actually requests to interact. The information provided by the user to the primary domain can be used in several ways to logon to secondary domains: • directly : the user information is forwarded to a secondary domain as part of a secondary logon; • indirectly : the user information is used to U H W U LHYH R W K H U X V H U L G H Q W L ¿ F D W L RQD QGFUHGHQ - tials information, stored within the Single Sign-On management information base. The retrieved information is then used for a secondary domain logon operation; •immediately : a session is established with a secondary domain as part of the primary domain session initialization. Client ap- plications are automatically invoked and communications performed at the time of the primary logon operation; •temporarily : information is stored or cached and used when the secondary domain ser- vices are requested. SSO provides a uniform interface to user accounts management interface, allowing a coordinated and synchronized management of component domains. The aim of any SSO solution should be mak- ing single sign-on to multiple sites as secure as giving a username and password at each site. To achieve this goal, different security issues need to be taken into consideration. First, SSO solutions should be based on strong authentication mechanisms; with the traditional password-based mechanism, the theft of a user password could compromise the whole system and even if the passwords are not stolen, storing pass- words on a single server makes it a single point of attack. Therefore, for high security environments, DSDVVZRUGEDVHGPHFKDQLVPFDQQRWEHVXI¿FLHQW DQGDFHUWL¿FDWHEDVHGDXWKHQWLFDWLRQHJEDVHG RQ;FHUWL¿FDWHVLVSUHIHUDEOH Another important aspect is related to the security of the server where the authentication LQIRUPDWLRQHJSDVVZRUGVRUFHUWL¿FDWHVLV stored. A robust SSO implementation should ensure the security of that server to prevent con- ¿GHQWLDOG DWDIURPEHLQJDFFHVVHGE\DPDOLFLRXV party. Encryption is a viable solution for securing the storage of the user credentials. 2208 Secure Authentication Process for High Sensitive Data E-Services A SSO solution should then be designed to guarantee that the key information cannot be determined. For instance, keys could be stored on a smart card or derived each time the user logs on using the password. The security of user’s credentials should be preserved also during their transmission. It is therefore mandatory to use SSL-encrypted con- nections to protect the authentication information, transmitted during the authentication process. Finally, a particular challenge in SSO systems is to provide for complete retrieval of identity information while preserving its privacy. Innova- tive SSO systems should be able to help the user in determining the consequences of releasing her identities to a counter-part in terms of potential danger to her privacy. Criteria are needed for evaluating tools with respect to the privacy features they are expected to enforce. This problem could be addressed by obscuring the identity of each user so that to each participant is presented a unique pseudonym. SSO solution clearly seemed to be suitable to Pitagora Project needs, addressing all require- ments of security, reliability, and performance. Many implementations have been presented to the Internet community such as, the Central Authentication Service developed by Yale Uni- versity (Aubry, Mathieu & Marchal, 2004; Central Authentication Service, 2004), Liberty Alliance project (Liberty Alliance Project, 2005; Galbraith, et al. 2002), a business and technology consortium of more than 130 global organizations that was constituted in 2001, and its SSO implementation SourceID (SourceID, 2005), founded in 2001 by Ping Identity Corporation Company, Shibboleth (Shibboleth Project, 2005), an open source imple- mentation, of Internet2/MACE, Java Open Single Sign-On (JOSSO) (Java Open Single Sign-On, 2005), an open source J2EE-based SSO infra- VWUXFWXUHKRVWHGE\6RXUFH)RUJHQHWDQG¿QDOO\ Microsoft Passport (Microsoft .NET Passport, 2005), one of the most known commercial Single Sign-On implementation. Central Authentication Service Central Authentication Service (CAS) (Aubry, Mathieu & Marchal, 2004; Central Authentica- tion Service, 2004) is one of the frameworks that imposes to open source community as an optimal solution in SSO scenario, and consequently also in Pitagora’s environment. Central Authentication Service was developed b y Ya l e U n i v e r s i t y t h a t i m p l e m e n t s a S S O m e c h a - nism to provide a Centralized Authentication to a single server through HTTP redirections. When an unauthenticated user sends a service request, this request is redirected from the application to the authentication server and back to the application if the user has been authenticated. The informa- tion is forwarded by the authentication server to the application during the redirections by using VHVVLRQFRRNLHVVHHWKHGDWDÀRZLQ)LJXUH CAS is composed of Java servlets running over any servlet engine and provides a Web- based authentication service. Its more interesting characteristics are security, proxying features, ÀH[LELOLW\UHOLDELOLW\DQGLWVQXPHURXVFOLHQWOL- braries. In particular, the most important security features are three: ++++ The CAS Server is therefore the only entity that manages passwords to authenticate users and WUDQVPLWVDQGFHUWL¿HVWKHLULGHQWLWLHV CAS implementation, however, was not com- pletely suitable for Pitagora’s needs and, hence it was extended with the integration of strong DXWKHQWLFDWLRQ PHFKDQLVPV DQG GLJLWDO FHUWL¿- cates, leading to the implementation of CAS++, as described in the following section. CAS++ An improved version of CAS architecture has EHHQGHYHORSHGWRIXO¿ODOOWKH3LWDJRUD¶VRSHQ issues and requirements. This solution was named 2209 Secure Authentication Process for High Sensitive Data E-Services CAS++ and it was an open source SSO system, developed by Siemens Mobile Communication S.p.A. and University of Milan, Department of Information Technology of Crema (DTI), based RQW KHX VHRI FHU WL¿FDWHVD QGI X OO\LQWHJ U DWH GZLW K the JBoss security layer. CAS++ solution integrated the CAS system with the authentication mechanism implemented b y a P u b l i c K e y I n f r a s t r u c t u r e ( PK I ) . C A S + + u s e d standard protocols such as HTTPS, for secure communications between the parties, and X.509 GLJLWDOFHUWL¿FDWHVIRUFUHGHQWLDOVH[FKDQJH It is a fully J2EE compliant application in- tegrable with services coded with every Web- based implementation language. It enriched the traditional CAS authentication process through WKHLQWHJ UDW LRQRI ELRPHW U LFLGHQWL¿FDWLRQE\ ¿Q- gerprints readers) and smart card technologies. 7KH VWURQJ DXWKHQWLFDWLRQSURFHVVÀRZ ZDV composed by the following steps (see Figure 6):  WKHXVHUUHTXHVWVDQLGHQWLW\FHUWL¿FDWHWR WKH&$&HUWL¿FDWLRQ$XWKRULW\ 2. the user receives from the CA a smart card WKDW FRQWDLQV D ; LGHQWLW\ FHUWL¿FDWH signed with the private key of the CA, that FHUWL¿HVWKHXVHULGHQWLW\7KHFRUUHVSRQG- ing user private key is encrypted with a symmetric algorithm (e.g., 3DES) and the key contained inside the smart card can be decrypted only with a key represented by XVHU¿QJHUSULQW.)LQJHUSULQW8VHU  WRDFFHVVDVHUYLFHWKHSXEOLFNH\FHUWL¿FDWH along with the pair username/password, is encrypted with the CAS++ public key (KPuCAS++) and sent to CAS++;  &$6 GHFU\SWV WKH FHUWL¿FDWH ZLWK LWV SU LYDWHN H\ YHU L¿H V W KHV LJ QDW X UHRQ W KHF H U- WL¿FDWHZLWKWKH&$SXEOLFNH\DQGYHUL¿HV WKHYDOLGLW\RIWKLVFHUWL¿FDWHE\LQWHUDFWLQJ with the CA; 5. CAS++ retrieves from the CA information DERXWWKHYDOLGLW\RIWKHXVHUFHUWL¿FDWH  LIWKHFHUWL¿FDWHLVYDOLG&$6H[WUDFWVWKH information related to the user, creates the ticket (TGC, Ticket Granting Cookie) and Figure 5. CAS Authentication Flow (from http://www.esup-portail.org /consortium/espace/SSO 1B/cas/ eunis2004/cas-eunis2004-article.pdf) 2210 Secure Authentication Process for High Sensitive Data E-Services returns it to the user encrypted with the pub- lic key of the user (KPuUser). At this point, to decrypts the TGC, the user must retrieve the private key stored inside the smart card E\PHDQRIKHU¿QJHUSULQW$VVRRQDVWKH card is unlocked, the private key is extracted and the TGC decrypted. This ticket will be used for every further access, in the same session, to any application managed by the CAS++ Single Sign-On server. For every further access in the session, the user was authenticated by the service providing only the received ticket (TGC, Ticket Granting Cookie). Note that, to improve security, any com- munication between entities (PKI, CAS++ and User) was based on SSL (Security Socket Layer). The advantages of this mechanism were that the account management was centralized and sepa- rated by the real application and the user had not to remember username and password, since they ZHUHORJLFDOO\FRQWDLQHGLQWKHFHUWL¿FDWHXVHG during authentication phase. The introduction of VPDUWFDUGVDQG¿QJHUSULQWVUHDGHUVGLGQRWDIIHFW the system performance and did not require huge additional costs. CAS++ addressed authorization managing the association of users’ identity with roles and leav- LQJWRWKHVSHFL¿FVHU YLFHWKHWDVNRIGH¿QLQJDQG managing the authorization policies (who can or cannot execute which action on which resource). CAS++ returned to the services the association between user and role. Federation CAS++ is however not the best solution for Pitagora’s needs. For instance, the concept of federation (Galbraith et al. 2002), strictly related to the concept of trust, could integrated in the CAS++ solution because introduced the concept of dynamic joining of SSO systems. The Liberty Alliance protocol is the most representative ex- DPSOHRIIHGHUDWLRQ,WZDVLPSOHPHQWHGWRGH¿QH a federated SSO system. The Liberty Alliance SURWRFROGH¿QHGWKUHHPDLQDFWRUV(1) Principal, )LJXUH6LQJOH6LJQ2QDXWKHQWLFDWLRQZLWKFHUWL¿FDWH 2211 Secure Authentication Process for High Sensitive Data E-Services that is the services requestor, characterized by an LGHQWLW\SUR¿OH(2) Identity Provider (IdP), that provides authentication assertions to the Princi- pal; and (3) Service Provider (SP), that supplies services to the Principal. The Liberty infrastructure is based on the con- cepts of Circle of Trust and Identity Federation: • Circle of Trust is a set of SPs and IdPs that have trusted business relationships, based on Liberty architecture, and operational agreements and whereby can transact busi- ness in a secure and apparently seamless environment. •Identity Federation represents the linked ³ORFDOLGHQWLWLHV´WKDWXVHUVKDYHGH¿QHGIRU multiple SPs. When an user authenticates to a particular service, the provider supplies the user with an assertion of the authentication event. An identity federation is said to ex- ist between the provider and other service providers, when they are in the same Circle of Trust. The authentication assertion is used to link user identity across business boundaries. A user should be able to select the services that the user wants to federate and defederate to protect user privacy and to select the services to which the user will disclose authorization as- VHUWLRQV 7KLV PHFKDQLVP FRXOG DOORZ D ³XVHU customization” of the Circle of Trust. Focusing on the authentication process, the ¿UVW VWHS WR HQDEOH IHGHUDWHG 6LQJOH 6LJQ2Q between all the providers is to establish a Circle of Trust between IdPs and SPs. Single Sign-On implementation in Liberty protocol is based on the assumption that the user has already feder- ated at least one Service Provider with an Identity Provider of the same Circle of Trust. Before that a user can access a resource/service, the user has to logon at the Identity Provider. The user has to provide the username and password and, if authen- tication succeeds, the Identity Provider shows the federated Service Providers available for the user. After the selection, the user is redirected to the Service Provider. The Service Provider sends then a request to the Identity Provider for authentica- WLRQFRQ¿UPDWLRQ,IWKH,GHQWLW\3URYLGHUVHQGV through an HTTP redirection transparent for the user, a positive response, the user gains access to the Service Provider. If the Identity Provider sends a negative response, the user is redirected to authenticate again using the Federation Single Sign-On process. This solution added to CAS++ implementation could give a complete answer that IXO¿OVDOO6LHPHQVVHFXULW\UHTXLUHPHQWV CONCLUSIONS $URDGPDSWKDWGHVFULEHGDQGUHFDOOHGWKHÀRZ that brought to the adoption of single sign-on approach to secure critical remote applications, managing high sensitive data and services, is presented. First, three methodologies, currently adopted to secure critical e-services, have been described: operating system level authentica- tion, application server level authentication, and components level authentication. Second, the case provided a description of single sign-on technol- ogy. Then, CAS++ system is introduced, and, ¿QDOO\LWLVGHVFULEHGKRZLWFRXOGEHLPSURYHG by mean of federation approach. REFERENCES Anisetti, M., Bellandi, V., Damiani, E. & Reale, S. (2005). Localize and tracking of mobile antenna in urban environment. In Proceedings of Inter- national Symposium on Telecommunications, Shiraz, Iran. Ardagna, C.A., Damiani, E., Frati, F. & Montel, M. (2005). Using open source middleware for 2212 Secure Authentication Process for High Sensitive Data E-Services securing e-Gov applications. In Proceedings of the First International Conference in Open Source Systems(OSS 2005), 172-178, Genova, Italy. Aubry, P., Mathieu, V., & Marchal, J. (2004). ESUP-Portal: Open source single sign-on with CAS (Central Authentication Service). In Pro- ceedings of EUNIS04 - IT Innovation in a Chang- ing World, Bled, Slovenia. Bettini, C., Jajodia, S., Sean Wang, X. & Wije- sekera, D. (2002). Provisions and obligations in policy management and security applications. In Proceedings of the 28th VLDB Conference, Honk Kong, China. Central Authentication Service (2004). Retrived August 6, 2006, from http://jasigch.princeton. edu:9000/ display/CAS Cremonini, M., Corallo, A., Damiani, E., De Capitani di Vimercati, S., Elia, G. & Samarati, P. (2005). Security, privacy, and trust in mobile systems. In M. Pagani (Ed.), Mobile and wireless systems beyond 3G: Managing new business opportunities. (pp. 312-341) Hershey, PA: IRM Press Damiani, E., Khosla, R. & Grosky, W. (2003). Human-Centered e-business. MA: Kluwer Aca- demic Publishers. Damiani, E. & Montel, M. (2005). Open source HOHFWURPDJQHWLF ¿HOG PRQLWRULQJ DV HJRYHUQ- ment service. In Proceedings of the Conference on e-Government Electronic Democracy: The challenge ahead (TCGOV 2005), Bozen, Italy. Feldma n, S. (2000). The changi ng ga ce of e-com- merce. IEEE Internet Computing, 4(3), 82–84. Fleury, M. & Scott, S. (2003). The JBoss Group: JBoss administration and development third edi- tion (3. 2 . x S e r i e s). I n d i a n a p o l i s , I N: J B o s s G r oup, LLC, Sams Publishing. Galbraith, B., Hankison, W., Hiotis, A., Janakira- man, M., Prasad, D. V., Trivedi, R., & Whitney, D., (2002). Professional Web services security. Wrox Press, Birmingsham, UK. Java Open Single Sign-On (JOSSO). (2005). Re- trieved August 6, 2006, from http://sourceforge. net/ projects/josso/ JBoss (2005). Open source application server. Retrieved August 6, 2006, from http://www. jboss.org Liberty Alliance Project. (2005). Retrieved August 6, 2006, from http://www.projectliberty.org/ Microsoft .NET Passport. (2005). Retrieved August 6, 2006, from http://www.passport.net Montel, M. (2004). Security aspects in a Web ac- cessible monitoring system for the environmental impact of mobile networks of 3rd generation. Unpublished bachelor degree thesis, Free Uni- versity of Bozen. Shibboleth Project. (2005). Retrieved August 6, 2006, from http://shibboleth.internet2.edu/ Single Sign-On, The Open Group. (2005). Re- trieved August 6, 2006, from http://www.open- group.org/ security/sso/ SourceID Open Source Federated Identity Man- agement. (2005). Retrieved August 6, 2006, from http://www.sourceid.org/index.html ENDNOTES 1 J2EE (Java 2 Platform, Enterprise Edition) is a platform for building distributed enterprise D S SOLFDW LRQV-((F R P S U LVHVDVSHFL¿FDWLRQ   reference implementation and set of testing suites. 2 EJB (Enterprise Java Bean) is a software component, which provides a pure Java 2213 Secure Authentication Process for High Sensitive Data E-Services environment for developing and running distributed applications. EJBs are written as software modules that contain the business logic of the application. 3 The Java Naming and Directory Interface ( J N D I ) i s p a r t of t h e J a v a p l a t f o r m , p r o v i d i n g WKHDSSOLFDWLRQVZLWKDQXQL¿HGLQWHUIDFHWR multiple naming and directory services. This work was previously published in the Journal of Cases on Information Technology, edited by M. Khosrow-Pour, Volume 9, Issue 1, pp. 20-35, copyright 2007 by IGI Publishing (an imprint of IGI Global). . customiza- tion and clear separation between business and security components and high reliability levels, it raised a major problems: it did not allow dif- ferent implementations for different applications, . is a set of SPs and IdPs that have trusted business relationships, based on Liberty architecture, and operational agreements and whereby can transact busi- ness in a secure and apparently seamless. domain and the use of different authentication mechanisms. Several usability and security concerns had been raised, leading to a rethinking of the logon process aimed at co-ordinating and,