Xem mẫu
Secure Authentication Process for High Sensitive Data E-Services
)LJXUH7KHORJLQFRQ¿JXUDWLRQHQWU\LQWKHORJLQFRQ¿J[POIRUWKHDSSOLFDWLRQ
)LJXUH7KH:HE[POFRQ¿JXUDWLRQ¿OHHQWU\GHFODULQJWKHORJLQIRUP
2204
Secure Authentication Process for High Sensitive Data E-Services
Focusing on Pitagora’s Authentication process, DIWHUWKHGH¿QLWLRQRIWKH6HFXULW\`RPDLQWKH VHUYOHWVSHFL¿FDWLRQVGH¿QHDVWDQGDUGPHWKRGRI FRQ¿JXULQJWKHORJLQSURFHVVIRU:HEDSSOLFDWLRQV WKURXJKWKHVSHFL¿FDWLRQLQ7RPFDW¶V Web.xml ¿OHRIWKH85/RIWKHORJLQSDJHDQGWKHORJLQ error page (see Figure 3).
By means of a standard JSP page, the user could insert login and password that was sent to WKHORJLQPRGXOHVSHFL¿HGLQWKH$&7,21WDJ ,QWKLVFDVHWKHSUHGH¿QHGPHWKRGIRUVHUYOHW form-based authentication j_security_check, that accepted as parameters username (named j_username) and password (namedj_password) DQGUHIHUUHGWRWKHVSHFL¿HG6HFXULW\`RPDLQ was used.
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 FUHGHQWLDOVZLWKWKHXVHUSUR¿OHLQIRUPDWLRQVWRUHG 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:
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.
• increase of costs and time spent for logon to multiple services: for each service the XVHUKDGWRSURYLGHVHUYLFHVSHFL¿FFUHGHQ-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¿OHVUHSRVLWRULHVZLWKYDULDEOHVFKHPD and variable authentication policies;
• usability problems: user had to interact with multiple logon interfaces.
From the account management point of view,
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
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,
2205
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 Figure4). The advantages given by the introduction of SSO architecture in a pre-exist-ing multiservices intra-domain scenario could be summarized as follows:
(2) failed logon transactions, (3) time used to logon to secondary domains, (4) costs DQGWLPHXVHGIRUXVHUVSUR¿OHVDGPLQLVWUD-tions;
• improvement to users security: the user has to manage only a couple of username/pass-word;
VHFXUHDQGVLPSOL¿HGDGPLQLVWUDWLRQZLWK 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-¿JXUDWLRQLQFOXGLQJWKHDELOLW\WRFKDQJH an individual user’s access to all system resources in a coordinated and consistent manner;
• improvement of services usability.
• reduction of:(1)time spent by the users dur-ing logon operations to individual domains,
From the point of view of economic feasibil-ity, most available Return-On-Investment (ROI)
Figure 4. User Single Sign-On to multiservice domain
2206
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 SUREOHPVFDQJHQHUDWHVLJQL¿FDQWVDYLQJV6WXGLHV by Forrester Research (www.forrester.com) con-¿UPWKDWHOLPLQDWLQJSDVVZRUGFKDRVFDQOLJKWHQ 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
• indirectly: the user information is used to UHWULHYHRWKHUXVHULGHQWL¿FDWLRQDQGFUHGHQ-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
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-ÀHFWWKHGUDZEDFNVUDLVHGE\WKHSUHYLRXVVROXWLRQV 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:
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, DSDVVZRUGEDVHGPHFKDQLVPFDQQRWEHVXI¿FLHQW DQGDFHUWL¿FDWHEDVHGDXWKHQWLFDWLRQHJEDVHG RQ;FHUWL¿FDWHVLVSUHIHUDEOH
Another important aspect is related to the security of the server where the authentication LQIRUPDWLRQHJSDVVZRUGVRUFHUWL¿FDWHVLV stored. A robust SSO implementation should ensure the security of that server to prevent con-¿GHQWLDOGDWDIURPEHLQJDFFHVVHGE\DPDOLFLRXV
• directly: the user information is forwarded to a secondary domain as part of a secondary logon;
party. Encryption is a viable solution for securing the storage of the user credentials.
2207
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-VWUXFWXUHKRVWHGE\6RXUFH)RUJHQHWDQG¿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 by Yale University that implements a SSO mecha-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 VHVVLRQFRRNLHVVHHWKHGDWDÀRZLQ)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\DQGLWVQXPHURXVFOLHQWOL-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 WUDQVPLWVDQGFHUWL¿HVWKHLULGHQWLWLHV
CAS implementation, however, was not com-pletely suitable for Pitagora’s needs and, hence it was extended with the integration of strong DXWKHQWLFDWLRQPHFKDQLVPVDQGGLJLWDOFHUWL¿-cates, leading to the implementation of CAS++, as described in the following section.
CAS++
An improved version of CAS architecture has EHHQGHYHORSHGWRIXO¿ODOOWKH3LWDJRUD¶VRSHQ issues and requirements. This solution was named
2208
...
- tailieumienphi.vn
nguon tai.lieu . vn