Web Single Sign-On System. For WRL Company

Transcription

1 1 Web Single Sign-On System For WRL Company Si Xiong June 2005 Department of Internetworking Royal Institute of Technology (KTH), IT-University Stockholm, Sweden Master of Science Thesis Supervisor: Johan Montelius Examiner: Björn Pehrson 1

2 2 Abstract The thesis deals with web-based authentication and single sign on solution. The main contributions of the project described by this report include a detailed investigation of different SSO architectures and technologies, as well as a comparison of the existing web SSO systems. This project also contributes a design of web SSO Service as a solution to existing problems with web based authentication and authorization. The solution allows users to authenticate to web-based services across many web servers using a central SSO service. So they do not need to sign-on multiple times to each different web server or application. The current implementation is built up and configured within the existing WRL company network environment only. However, the system is designed as reusable components that can be easily plugged into any J2EE applications. Its extensible architecture can also potentially support different authentication methods and across different platforms. Keywords: Single Sign-On, Kerberos, Authentication, Open Source, JAAS. 2

3 3 Content Abstract...2 Content...3 Acknowledgment...5 Chapter 1 Introduction Background Software Project Research Problem and Object Organization...7 Chapter 2 Conceptions and Theories Identification, Authentication and Authorization (IAA) Getting Access to Objects Multiple Sign-On Single Sign-On Definition of Single Sign-On The Benefits of Single Sign-On Different Flavors of Single Sign-On Different SSO Architecture Single Sign-On With Multiple Sets of Credentials Single Sign-On With Single Set of Credentials Analysis and Comparison Single Sign-On vs Password Synchronization Password Synchronization Introduction Comparison of Password Synchronization and Single Sign-On...23 Chapter 3 Design and Implement Kerberos-based Authentication Introduction to Kerberos Architecture and Functionality How It Works Ticket Specification in Kerberos Kerberos Delegation Case Study about Related Solutions Passport Solution WebAuth Solution CAS Solution

4 Cosign Solution Solution Comparison Summary Technology Requirement HTTP Client-Server Communication Safe Redirection Secure Sockets Layer (SSL) Secure Cookie WSSO Solution Design Consideration Structure and Components Authentication Model Security Overview...64 Chapter 4 Conclusion and Future Work Conclusion Future Development...68 Appendix...70 Appendix A...70 Appendix B...73 Appendix C...75 References

5 5 Acknowledgment This thesis is accomplished with kind help of a lot of people to whom I wish express my sincere thanks. First, I wish express my deep gratitude to Björn Pehrson, for his valuable advices and for being my examiner. Thanks to my supervisor Johan Montelius, for reading through my thesis draft time after time, discussing with me and giving me so many valuable suggestions. I also would like to thank the Wuhan Railway Logistic Company for giving me the opportunity to do this work. Thanks to engineer Jibo Zhou, for his technical help and programming advices, and for his patience debugging my mistakes. I should say thanks to Lin Ji, Yuecong Xie, Min Yuan and all the friends who have always given me kind help and supports. Last but not least, I am eternally grateful to my dear parents, who always encourage me from my homeland far away. Without their deep love and support in my life, I could not get through this thesis in the end. I really want to say thanks to all the people, I will remember them for all my life. 5

6 6 Chapter 1 Introduction 1.1 Background Since the wide spread of the HTTP protocol, more and more companies are offering the web-based application services to provide user access via the Internet. The Wuhan Railway Logistics (WRL) company now has many web-based applications and resources running within its scope. While most of the web services are open to all, some commercial information and particular functions require a certain access control to make sure that only authorized users can make use of them. In order to be granted accesses to these restricted web services, users have to authenticate themselves to all the application servers. As each application is complete in itself, which means it relies on its own database and login process, multiple systems bring multiple user IDs and passwords. Keeping a large number of passwords in mind and repeatedly entering them to login to different application servers are really big burdens for the end-users. Maintaining such a huge amount of credentials is also the biggest headache for the system administrator and help-desk. One possible solution to solve this problem requires some way for a user to authenticate him/her self only once, using a single password and then get access to all the web applications and resources in this company that user is authorized to use, without re-authentication. This is called the Single Sign-On (SSO) solution. 1.2 Software Project My task is finding out an appropriate solution to allow users with standard web browsers, using a strong security mechanism, log into many web services seamlessly, without the inconvenience of having to memorize a large number of credentials and authenticate themselves time after time. The solution should meet these basic design goals and constraints: Work with standard web browsers and easy to use. High level password security. Provide the single sign-on experience for end users Simple to configure and integrate with existing web application systems. Cost effective to maintain and manage. 6

7 7 1.3 Research Problem and Object There are many good solutions from different companies. What is the most important thing to do is making appropriate technological decisions about which system architecture to use, which authentication method to choose and which security mechanisms to support, based on the existing environment, objectives and specific requirements of this company. 1.4 Organization The remainder of this report is organized as follows. Chapter 2 provides the reader with a basic introduction to web authentication and an overview about the single sign on. Later in this chapter, the current single sign-on approaches will be presented. The architectures behind the technologies are also analyzed and a light evaluation of these models is done. Chapter 3 surveys various existing web single sign-on solutions. The differences between these solutions will be explained in detail as well as the advantages and limitations they bring along. Also, I will present the design of my own solution, and explain some of the technologies should be used for implementation in detail. Finally, I give a conclusion for the whole project and compose a comprehensive SSO model by combining the common functions and strengths of different solutions for the future development. 7

8 8 Chapter 2 Conceptions and Theories The following parts will first define the function of identification, authentication and authorization in a network, and give a short description of how to reach the remote protected objects. Then, I will introduce the basic sign on model and describe the disadvantage of this multi sign on system. Later on, the single sign on model will be presented, especially with the focus on the different SSO architectures. Last in this chapter, I will compare the SSO solution to the password synchronization. 2.1 Identification, Authentication and Authorization (IAA) One of the primary reasons for the use of networks is the distribution and access of the remote objects. It is really important to protect the sensitive information and services from unauthorized users. So the identification, authentication and authorization for the user to request the restrict resource become very indispensable Getting Access to Objects Authentication, identification and authorization are three important components for a distributed network to control access to the protected resources. [1] Identification In order to be granted access to restricted applications and information, first, the user needs to identify him/her self as the one who has the permission to visit this object. Identification, according to a current compilation of information security terms, is "the process that enables recognition of a user described to an automated data processing system. This is generally by the use of unique machine-readable names". --M. E. Kabay Authentication After the user presents the authenticating information to the authentication authority, the authority needs to verify the claimed identity and grant the access to the protected objects. Schou and Corey defined Authentication as "A positive identification, with a degree of certainty sufficient for permitting certain rights or privileges to the person or thing positively identified." In simpler terms, it is "The act of verifying the claimed identity of an individual, station or originator". 8

9 9 The four major types of authenticating information commonly used today are based on: Something you know (e.g. a password) Something you have (e.g. a smart card) Someone you are (biometrics, e.g. the fingerprint) Or some other information (e.g. the IP address) The most familiar form of authentication is entering a username and the corresponding password. More secure and reliable methods exist such as smart cards, Biometrics and etc. You can also combine more than one method together to maker the authentication stronger. Authorization Once the user has been authenticated successfully, he/she can be granted the access to any object he/she has the permission. Authorization is the gate-keeping function which is responsible for finding out if the identified person is allowed to use the requested resource. Figure shows the process which results in getting access to a restricted object Multiple Sign-On Figure2.1.1 getting access to restricted objects Most distributed systems were assembled from different components. Each of the component acts as an isolated security domain independently. This means, every domain has its own database and should be separately managed. In order to be granted access to these restricted web resources, users have to authenticate themselves to each of the components with which he wishes to interact. [2] This scenario is illustrated as following: 9

10 10 Figure Legacy approach to user sign on to Multiple Systems Using password seems like a great way to protect your system. But, too many passwords are as bad as no password at all. The problems with Multiple Sign-On From the user view In the multi sign-on environment, the end-user who wants to use services housed in different servers has to sign-on multiple times. It s very annoying to be interrupted to perform login tasks over and over again. Worst of all, users have to remember large numbers of passwords. And administrators have to face the nightmare of dealing with a lot of task related to the password. From the enterprise view Reduce Security What might happen if users must memorize too many passwords? They may have some bad habits that reduce the system security, such as 10

11 11 Using the same password for all the systems. Choosing a simple and insecure password. Writing passwords down and post them on the screen for the whole world to see Increase Costs The 1996 Network Applications Consortium (NAC) study revealed that 70 percent of calls to companies' Help desks were password-reset requests from users who had forgotten a password. Meta Group alleges that Organizations spend $25 each time they have to process a lost password incident. Let s suppose on average a user will need four password resets per year, an organization of 1000 users will waste $100,000 per year on password resets. Decrease Productivity According to a 1996 NAC study, users in large enterprises spend an average of 44 hours per year performing logon tasks to access a set of four applications. It is really a waste of time. Obviously, multiple sign-on is very troublesome, so the single sign-on solution has been introduced to solve this problem. 2.2 Single Sign-On Definition of Single Sign-On The Open Group defines Single Sign-On as: Single sign-on (SSO) is the mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where that user has access permission, without the need to enter multiple passwords. [2] 11

12 12 Figure2.2.1 the Single Sign-On (This figure is from For short, Single Sign-On is the technology where a user only need to authenticate him/her self once, then has the ability to access other protected resources without having to re-authenticate The Benefits of Single Sign-On From the user view Figure the benefits of Single Sign-On In an SSO environment, users only need to authenticate themselves once. This effectively solves the annoying stop-and-go problem which is caused by multiple login requests. Best of all, the SSO solution frees users from remembering a large number of identities and associated passwords. From the enterprise view 12

13 13 For the enterprise, SSO delivers a tremendous return on their investment. Potential Increase in Security With only one password to remember, it is more reasonable for the user to choose a single complex and more secure password instead of using multiple simple and insecure passwords. This potentially increases the system security. Improve Productivity Employee productivity is dramatically improved, with less time users spend logging into multiple applications and recovering the forgotten passwords. Reduction in Costs Meta Group estimates 33% reduction in help desk volume when using an enterprise Single Sign-On solution. By reducing the number of passwords the user must remember, SSO effectively reduces the password-related workload to the helpdesk and lowers the costs associated with managing passwords across multiple distributed applications Different Flavors of Single Sign-On There are three main types of single sign-on: web SSO, Legacy SSO and Federated SSO. Web Single Sign On: Wed-based SSO is a widely deployed single sign-on technology sometimes also called web access management. It enables a user to provide the credentials, if authentication succeed, it will establish a relationship of trust that grant user the access to all web resources for which he/she have permissions. [3] Legacy Single Sign On: Legacy SSO is also called Enterprise SSO. Like web SSO, legacy SSO is also a technology designed to manage multiple login to target applications after a single authentication event. It has a very similar structure to the web SSO. While web SSO only manages the web-based service, legacy SSO extends the SSO functionality to the traditional legacy applications and network resources (windows GUI based applications, for example), typically within an enterprise s internal network. [3] Federated Single Sign On: Federated SSO is similar to the web SSO but has a much broader concept. It uses Simple Object Access Protocol (SOAP) and Security Assertion Markup Language 13

14 14 (SAML) to enables users to sign on once into a member of the affiliated group of organizations, then seamlessly access all the web sites within that trusted federation without requiring re-authentication. [4] The main advantage of a federated SSO is extending the SSO environment from a user s home domain to other foreign domains. Federated SSO allows the enterprises to maintain the control of its local services and expose these resources to a larger class of users not directly administered by it. Mostly, this solution is used by the businesses to build a complete framework for secure B2B and B2C e-business. The most famous federated SSO is the Liberty Alliance Project. 2.3 Different SSO Architecture Today, there are various SSO architectures, each with different properties and underlying infrastructures. Jan De Clercq, the Security Consultant of HPCI Technology Leadership Group, defined two main architectures to get Single Sign-On: solutions that deal with one set of user credentials and solutions that deal with multiple sets of user credentials. [5] Now, I will present each of the architecture in more detail and give a light evaluation and comparison of these models Single Sign-On With Multiple Sets of Credentials Secure Client-side Credential Caching The Secure Client-Side Credential Caching mechanism is a client-based SSO solution which keeps all the authentication information into a client-side credential storage. It allows the end-users to authenticate themselves once, and then has the system automatically provide the information for subsequent request without the users intervention. If the credentials are valid, the user will be authenticated transparently to the other application servers. A good example of the Secure Client-Side Credential Caching mechanism based SSO solution is Credential Manager that Microsoft offers in Windows Server 2003 and Windows XP. [6] 14

15 15 Figure Client-side Credential Caching Mechanism This solution requires a high secure credential cache resides on client-side. It is very crucial to store the cached credentials securely as the credentials may be used to access some sensitive information or confidential web service. So, it s not recommended to be used from portable client devices or some Operation Systems with a bad security reputation. Since all the authentication data is stored in the client-side credential cache, this architecture has little flexibility. The user will get sign-on problems if he/she is not using his usual workstation (when travelling, for instance). Although it is relatively simple for the user to set up and configure, every time a new application server is added, the new authentication information should be added into the client-side credential cache. This makes the solution a little discommodious. Secure Server-side Credential Caching The Secure Server-Side Credential Caching mechanism is also called the server-based SSO solution. The same as the Secure Client-side Credential Caching architecture, this approach also uses a central repository to store all the authentication information. But in this architecture, the cache is located on server-side. It uses a central server to take on the task of administering all the different passwords and providing the needed information directly to the application asking for them. The good examples of this SSO solution are Tivoli SecureWay and ETrust SSO. [7] 15

16 16 Figure Server-side Credential Caching based SSO In a secure server-side credential caching mechanism, the primary credential database contains the user s primary credentials as well as the mappings between the primary credentials and the secondary credentials. The secondary credential database only keeps a copy of the secondary credentials. It is important that in this approach, we should keep the mappings between these credential databases synchronized. There are three main approaches to achieve the data synchronization: 1. Integrating the credential synchronization services into the primary credential database. 2. Using an external software to handle the credential synchronization process. 3. Administrators perform the synchronization by themselves (not recommended). Depending on the need of credentials synchronization, it is necessary to set a trust relationship between the secondary authentication authorities and the primary authentication authority. Using the SSO with server-side credential caching, authentication is possible from any workstation that has access to the requested application server. And no user interaction will be needed when a new application server is added. But this architecture increases the number of authentication authorities by the new server that stores and protects the users credentials. 16

17 Single Sign-On With Single Set of Credentials SSO solution with single set of credentials is often implemented by some services which provide the management of authentication information. This solution uses a standardized scheme to handle authentication which is located on a centralized authentication infrastructure. A major feature of this single set of credentials SSO architecture is the rather homogeneous environment which means: using a single account naming format and authentication protocol which are supported by every entity in the whole network system. There are two flavors of SSO with single set of credentials: PKI-based SSO and Token-based SSO. Both of them only use a single set of credentials which is recognized by many different authentication authorities. PKI-based Single Sign-On The PKI-based SSO solution makes use of pubic key cryptography to authenticate users. It requires the use of a Certification Authority (CA) system to issue and manage users digital identities. [8] Figure shows the PKI-based SSO model. The user first identifies him/her self to a trusted authentication authority and gets a public key certificate. In a subsequent authentication request, whenever he/she tries to access a protected resource, the user creates a token, includes its own digital certificate (public key in it) and signs it with the private key. The target server receives the request and contacts with the CA to proof the user s identity. Since the secondary CA s certificate is issued by the primary CA, there is a trust relationship between the secondary CA and the primary CA which enables any secondary CA will accept the certificate issued by the primary CA. The most famous PKI-based SSO product is Entrust GetAccess. 17

18 18 Figure PKI-based Single Sign-On Model But still, there are a lot of limitations of the public key infrastructure. First, the length of the private key is a big strongpoint but also the possible problem to the PKI-based solution. The private key is a very long series of random binary data (usually represented in Base64) need to be closely protected. It is hard to write the private keys down on paper or keep it in mind, but easy to transfer over a network. So, it is not easy to steal somebody s private key. Often, private keys are stored into user s usual work station, but it will cause some trouble if the user has to work in some other place. Although this problem can be solved by storing the private key on some hardware devices such as USB keys or smart-cards which could offer the maximum protection, it needs some extra cost. A sample RSA private key is shown below: 18

19 19 Figure sample RSA private key (copy from RSA website) Moreover, I agree with the opinion that PKI has been exaggerated as the technology to solve many network security problems. Still, there are many risks of public key infrastructure. For more detail about the PKI risk analysis, you can check the article Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure written by Carl Ellison and Bruce Schneier. [9] Implementing a PKI is not only difficult and expensive, but also difficult to manage. The complexity of PKI technology has foreclosed its growth in many enterprises. Token-based Single Sign-On In a token-based SSO architecture, the user will receive a temporary token after he/she has logged into the primary authentication authority. This temporary token will be used to proof the user s authenticity to every service he/she requests. There is a trust relationship between the primary authentication authorities and the secondary authentication authority. This relationship enables the user could be authenticated to a secondary authentication authority with the temporary token issued from the primary authentication authority without a re-authentication. A typical example for this authentication strategy is the Kerberos authentication protocol. MS Passport is another widely used token-based SSO solution. 19

20 Analysis and Comparison Figure Token-based Single Sign-On The following table will make a comparison of these different kinds of architectures against their advantages and disadvantages. Secure Client-side Credential Caching Pros Can deal with different sets of credentials. Does not require a homogeneous authentication infrastructure environment Relative easy to set up Minimum modification of the application Cons Requires a very secure client-side credential cache Multiple sets of credentials complicate life of user and administrator. Little flexibility Lack of industry standardization in password specifications The end-user controls password management. No central management control. 20

21 21 Secure Server-side Credential Caching Token-based SSO PKI-based SSO Can deal with many different credentials Does not require a homogeneous authentication infrastructure environment Few user interruptions when new application added Single set of credentials simplifies life of user and administrator. No user interruption when new application is added. Single set of credentials simplifies life of user and administrator. High level secure by using asymmetric cryptography No user interruption when new application is added Requires a credential synchronization mechanism Lack of industry standardization in password specifications Multiple sets of credentials complicate life of user and administrator. Need high available authentication server Often rely on symmetric cryptography, relative less security. Require extra software on application. Need high available authentication server Complex certificate validation logic requires a lot processing on the client side. All services and applications must be PKI-enabled Little flexibility or extra cost to store private keys. Need trusted Certificate Authority SSO with multiple sets of credential provides the advantage that the user only needs to remember one password to log on multiple systems. But in my opinion, it s not a good solution. Since it can deal with many different credentials, users and administrators must manage the passwords of the different credential sets, so password maintenance will be more complex in this type of SSO architecture, although this architecture could partially resolve the "key to the kingdom" problem. Moreover, Single Sign-On with multiple sets of credential is not a clean approach as there are still many authentication authorities at which the user has to sign-on. This solution only hides the problem of multi sign-on to the users instead of really solving it. Using SSO with single set of credential, the amount of authentication authorities at which the user has to login is reduced to only one (the primary authentication authority). 21

22 22 Every secondary domain including an authentication authority trusts the primary authentication authority, and only one sign-on is needed to get access to the whole domain. Single Sign-On use one set of credentials can indeed simplify the users' life and the Helpdesk s jobs. With this SSO architecture, users only need to remember one set of credentials to across multiple systems and administrators only need to keep track of one entry for every user in the credential database. That s why most existing single sign-on products are designed base on this single set of credentials architecture. 2.4 Single Sign-On vs Password Synchronization Password Synchronization is not Single Sign-On! Many people think that single sign-on means all applications use the same password, password synchronization is also one of the SSO solutions. However, it s not true. Password synchronization and SSO are two different things Password Synchronization Introduction Password synchronization is the technology of changing all the passwords for different applications to the same value. This means that once using the password synchronization mechanism, user can enter uniform passwords to login to all the synchronized applications and resources which need authentication. [10] Since there is no client-side software needed, password synchronization is very easy to implement. This flexible and scalable architecture does not need user s interaction when new application servers are added. The following figure shows the model of the password synchronization: 22

23 23 Figure Password Synchronization Model Solution in this case is based on passwords on all systems have the same value. However, this is also a weakness of this method. 1 Using password synchronization, all the applications have to use the compatible password policies and all the passwords need to be the same. This means, we have to adopt the password policy of the weakest application server. 2 Having the same password for multiple systems increases the potential damage. If someone deciphers the password on one system, all the systems will be vulnerable. Therefore, it is very important to ensure the security of all the systems. (This could also be the problem for some SSO solutions.) Although someone prefer to define password synchronization as one method of single sign-on, I insist that, strictly says, password synchronization is not a real SSO solution as it does not change the sign-on process for support systems. What a password synchronization system has really done is just distributing and synchronizing a main password to ensure that all passwords are the same across every system the user logs into. The user is still required to login each time he/she requests a new application, even though he/she can use uniform passwords Comparison of Password Synchronization and Single Sign-On Password synchronization and Single Sign-on, both of them has its own strengths and weaknesses: 23

24 24 Implement Process Login times Manage credential data Password policy Security Password Synchronization Easy to implement -- no client software, limited server-side agents. Simply changing all applications to use the same passwords. The user is still required to login to each system using the same passwords. Managing passwords only. Using the same passwords. Has to adopt the weakest password policy of the system. Credentials are kept identical on all platforms -- Key to the Kingdom argument Single Sign-on Depend on different architectures and technologies might be very complex. Using single username and password to login to one specific server which will take charge of the client authentication to all the other servers. The user only needs to login to the primary authentication authority once. (primary sign-on) Using specific protocols to manage the client authentication and the secrete information. Only one password, but can use strong password policy to ensure security. Single point of failure, may also has the Key to the Kingdom problem. 24

25 25 Chapter 3 Design and Implement There is a considerable amount of single sign-on solutions for the web which can be classified into two types. The first one is scalable enough to cover large numbers of institutes even an entire country. The second one is designed to work mainly in a single institution, such as a University or an enterprise. The scope of this project is the second type. 3.1 Kerberos-based Authentication We choose Kerberos as the underlying technology for achieving single sign-on because it is a mature protocol and has been widely deployed. [11] Introduction to Kerberos Kerberos is a network authentication protocol, developed as part of MIT's Project Athena, designed to provide strong authentication for client/server applications, using secret key cryptography mechanism. During the authentication process, it can also encrypt all of the communications to ensure the user privacy and the data integrity as a security feature Architecture and Functionality Kerberos V5 is a token-based authentication scheme through a trusted third party. The end user and the service do not trust each other, but both trust a common authentication server which is called the Kerberos Key Distribution Center (KDC). The KDC shares the secret keys with both of the user and service. These secret keys from each principal are encrypted in a local database of the KDC, used to prove the principals identities and to establish the encrypted sessions between the KDC and the principals. [12] The KDC will issue tow types of Kerberos Ticket to the clients: A master ticket, also known as the ticket-granting ticket (TGT) A service ticket (ST) The TGT is used for you to initialize an identity request. When you get the TGT, you can use your TGT to request the ST for specific services. Your TGT authenticates you to the Kerberos server, and your ST authenticates you to the appropriate service. 25

26 How It Works The following is the key exchange scenario to explain how TGT and ST work: Figure key exchange scenario of Kerberos (This figure is copy from Microsoft) The client first sends a message to the KDC to request the issuance of a TGT. This request includes the username of the client in cleartext, but does not contain the password. The KDC sends back a TGT which contains a session key to the client. The session key is encrypted by a key which is derived from the client's password. That means, only this client can decrypt the TGT using his/her password and fetch the session key. The client decrypts the TGT, extracts the session key, then sends a request to the KDC for a ST. The ST is valid only for communication between the client and the requested server; no one else can use the ST. Therefore, while requesting the ST, the client should specify the name of the server request. And the requested server should be already registered with the KDC. 26

27 27 The KDC constructs a ST for the server. This ticket contains the client's authentication data and a new cryptographic key which is called the sub-session key. The KDC encrypts the ST with the secret key which is a shared secret between the KDC and the server. So, only this server can decrypt the ST, get the client s information and fetch the sub-session key. The KDC creates a message, wraps the ST and copies the sub-session key inside of it. Notice: the sub-session key is now contained both in the message and the ST inside the message. The KDC encrypts the message with the session key. Thus, only the client has the session key can decrypt the message and extract the sub-session key and the ST. But the client cannot decrypt the ST because he/she does not know the server s secret key. Only the server can decrypt the ST. Then, the KDC sends the message to the client. The client decrypts the message which is received from the KDC using the appropriate session key. Then, he/she fetches the sub-session key as well as the ST inside the message and sends the ST to the server requested. The server receives the ST, decrypts it using its secret key, and fetches the authentication data of the requesting client as well as the sub-session key. Now, both the client and server hold the same sub-session key which can be used for secure communication with each other. Then, the server responds the client's request, and a new secure session is established between them. After the client got the TGT, when he/she wants to access another server, he/she only needs to ask the TGS to issue the corresponding ST for the other server application without re-authentication to the AS Ticket Specification in Kerberos In some specification, sometimes, the KDC could also be divided into two components: [13] Authentication Server (AS) : Provide the long term ticket TGT Ticket Granting Server (TGS): Provide the short term ticket ST Notation c client principal 27

28 28 s a v t tgs server principal clients address validity timestamp ticket-granting server K x private key of x K c,s session key for c and s {info}k x info encrypted in private key K x {info}k c,s info encrypted in session key K c,s Two types of credentials. tickets (T x,y = x s ticket to use y) = y, {x, a, v, K x,y }K y. authenticators (A x,y = authenticator from x to y) = {x, t, K subsession }K x The following figure shows the complete Kerberos authentication protocol. Figure Complete Kerberos Authentication Protocol 28

29 29 Message Specification 1 as_req: c, tgs, 2 as_rep: {K c,tgs }K c, {T c,tgs }K tgs 3 tgs_req: {A c,s }K c,tgs {T c,tgs }K tgs 4 tgs_rep: {K c,s }K c,tgs {T c,s }K s 5 ap_req: {A c,s }K c,s {T c,s }K s 6 ap_rep: {ts}k c,s (optional) Messages 1 and 2 are used only when the client first logs in to the system; messages 3 and 4 are used whenever the client asking for a new server application; message 5 is used each time the client authenticates him/her self to the application server; message 6 is an optional step, it s only used when the user requires mutual-authentication by the application server Kerberos Delegation Suppose the client requires the server S to perform a very complex task, server S must make a request to another server T to perform the sub-task. Using credential delegation, the client can pass his/her identity to an intermediary server S, allowing the server S to authenticate to another server T and make further request on the behalf of the client. 29

30 30 Kerberos has the ability to support credential delegation. When the Kerberos client sends a ticket to a server, he/she can add some additional information into the ticket, so the server can reuse the received ticket to request other tickets on behalf of the client to the Kerberos KDC. This provides SSO support. Figure Kerberos Delegation 3.2 Case Study about Related Solutions There are a number of good solutions for web single sign-on exist Passport, WebAuth, CAS, Cosign and etc, each has its own advantages and risks. Not like the simple, insecure authentication solutions users passwords are stored in a central cache and circulated to every application they accesses, for instance. All of the solutions have a Kerberos-based architecture, issuing ticket-granting ticket for service ticket. In this part, I will introduce these four solutions in detail, point out the different features and make a light evaluation Passport Solution Passport is an implementation of Single Sign-On system developed by Microsoft. It s one of the most widely used SSO solutions in the world. 30

31 31 Source: Components and Roles Passport Server The Passport server is the single and central location to maintain the entire user accounts information and handle the authentication process for all the passport-enabled websites. When the websites need to authenticate a user, they just delegate this task to Passport. Theses websites only need to understand the authentication assertions sent from the passport server, without handling the authentication process by themselves. Passport Manager Passport manager is a small piece of code that runs on a passport-enabled website and communicates with the passport server. This manager is responsible for managing shared secret key, decrypting tickets, encrypting and storing them as cookies. It is also used to generate login requests and redirect the user to the passport server. Authentication Model Initial Passport authentication flow, unauthenticated access to the protected resource: 31

32 32 Figure unauthenticated access to the protected website 1. An unauthenticated user issues a request, attempts to access a passport-protected website. 2. As the request does not include a valid authentication ticket, the client is redirected to the logon page on the passport server, appending a unique identifier which identifies the web site from where the user is redirected. 3. After checking the validity of the siteid within the request string, the Passport logon server presents the client with a logon form over a Secure Sockets Layer (SSL) connection. The user supplies his/her Passport credential and sent it back to the logon server. 4. The credential is checked against the account information that Passport stores. If the user is verified, the logon server set a passport cookie and re-directs the user's browser back to the original URL. The response contains a Passport profile data encrypted by original site s secret key in the query string. 5. The client requests the original protected resource again with the encrypted authentication ticket and profile information attached. The website decrypts the 32

33 33 receiving ticket using its shared secret key, checks the profile information, and then grants user access to the requested website. It also saves the site ticket as a cookie in the site domain so that the user stays authenticated in subsequent requests. After successful login, Passport's single sign-on feature allows the user to get authenticated with other protected website without having to re-enter his/her password. The Single sign-on flow: Figure single sign-on after initial authentication 1 An authenticated user attempts to access another passport protected website. 2 As the request does not include a valid authentication ticket, the client is redirected to the logon page on the passport server, appending a unique identifier which identifies the web site from where the user is redirected. 33

34 34 3 The Passport server checks the cookie stored in Passport domain, generates a ticket for the requested website, and then refreshes the Passport visited sits cookie. Then, it re-directs the user's browser back to the original website. This response contains a Passport profile data encrypted by website s secret key in the query string. 4 The client requests the original protected resource again with the encrypted authentication ticket and profile information attached. The website decrypts the receiving ticket using its shared secret key, checks the profile information, and then grants user access to the requested website. It also saves the site ticket as a cookie in the site domain so that the user stays authenticated in subsequent requests. Logout To sign out, a user only need to click the sign out logo, then, all the Passport cookies from participating sites during browser session will be deleted. Additionally, all the Passport cookies are temporary cookie which means these cookies will be deleted when the browser session is closed. Furthermore, these cookies also will expire after a certain period of time. Security Overview The password is only sent to the central Passport server via SSL. Cookies with credentials are encrypted with Passport key and stored only within the Passport service. Profile information are encrypted with participating sites key, stored within the Passport service and shared with participating sites. Passport uses the Triple DES encryption scheme. When a website registers with Passport, it gets a crypto key that only sharing with the passport server. Server and site use this shared secret key to encrypt and decrypt the query strings passed between them WebAuth Solution WebAuth is an open-source single sign-on solution designed by the Stanford University. Source: 34

35 35 Components and Roles The WebAuth architecture involves two main components: [webauth1] Login Server The role of the login server is that of the trusted, central authentication service which interacts directly with users. It is responsible for handling the login requests and verifying usernames and passwords with backend authentication services. It also issues cookies to users for providing single sign-on functionality and to application servers for providing authentication information. Application Server The application server acts as an authentication enforcer. It redirects the un-authenticated users to the login server and verifies authentication information returned from the login server. It issues cookies to users to maintain authenticated application sessions and provides user authentication information to applications. Authentication Model Before handling the authentication process, there is an additional phase between the login server and each application server to generate a shared symmetric key for cookie protection. Initial WebAuth authentication flow, unauthenticated access to the protected resource: 35

36 36 Figure Unauthenticated access to protected Web application 1. An unauthenticated user issues a request, attempts to access a protected web resource from application server. 2. As the user has not been identified yet, the request does not include an app-token cookie. So, the application server constructs a request-token which is encrypted by a session key shared between the application server and the login server. The user is redirected to the login server with the request-token. 3. The login server decrypts the request-token using the session key and presents the client with a logon form over a Secure Sockets Layer (SSL) connection. The user supplies the username/password and sent it back to the logon server. 4. The login server verifies the credential and generates two token: proxy-token and the id-token. The proxy-token is paced into a cookie for the login server to provide single sign-on in future request. The id-token is sent back to the application server as a receipt. 36

37 37 5. The user re-requests the original resource, passing along the id-token in the URL. 6. The application server checks the id-token, rewrites the id-token into an app-token, and creates an app-token to be placed into a cookie for future requests. Access to the resource will be granted to the user. 7. For the future access, the user requests with a valid app-token cookie, the application checks it and grants access. After successful login, Webauth's single sign-on feature allows the user to get authenticated with other protected web resource without entering password. Single Sign-On flow: Figure single sign-on after initial authentication 1. The authenticated user request another protected web resource from application server 2. As the request does not include an app-token, the application server constructs a 37

38 38 request-token which is encrypted by a session key shared between the application server and the login server. The user is redirected to the login server along with the request-token. 3. The login server decrypts the request-token using the session key and detects the user has a valid proxy-token. It constructs an id-token and the return URL, which will contain the response-token, as well as the requested-token. 4. The user is redirected to the original resource, along with the id-token. 5. The application server checks the id-token, rewrites the id-token into an app-token, and creates an app-token to be placed into a cookie for future requests. 6. User s browser saves the app-token cookie; the application serves the original request to the user. Logout Logging out of an application involves deleting all the session cookies associated with this application on the server. The easiest way to logout of all applications is exiting the web browser. The user could also go to the WebAuth server's logout page so any proxy-tokens could get removed. Security Overview WebAuth uses a very similar structure to the Passport solution. The central login server shares the symmetric keys with each application server to encrypt and decrypt the tokens sent, so only the relative recipient can read the contents. The password is only sent to the central login server via SSL. All the communications between the browser, the application server and the login server are also protected by SSL. As all the information about the authenticated user is kept on the user s browser in the form of cookies, the application server does not need to communicate with the login server to validate the cookies. This makes the central authentication server is very distributable and thus the whole system is highly scalable CAS Solution Central Authentication Service (CAS) is an open-source single sign-on solution designed by the Yale University. 38

39 39 Source: Components and Roles CAS server The CAS server is the centralized authentication server which responsible for authenticating users, transmitting and certifying the identities of authenticated users to CAS clients. The CAS server is the only server that knows user passwords. CAS clients Any web application equipped with the CAS client library, or any web server using CAS model, is called CAS client. It is responsible for delivering resources only to clients authenticated by the CAS server. Authentication Model Initial CAS authentication flow, unauthenticated access to the protected resource: 39

40 40 Figure Unauthenticated access to protected Web resource 1. A non-authenticated user attempts to access a resource protected by a CAS client. 2. As no service ticket (ST) is given, the user is re-directed to the login URL to use the central authentication service, appending a query string identifying the service requested. 3. The CAS server checks the existence of a valid Ticket Granting Cookie (TGC). As the user has not yet been authenticated, the CAS server sends a login form that prompts the user for the userid and password. 4. The user returns the credentials back to the CAS server. If the userid and password are correct, the server generates a TGC and sends it to the browser as a non-persistent cookie. Then, the CAS server re-directs the user to the service URL appending a ST. 5. The application extracts the ticket, passes the ST and service name back to the CAS server for verification (using the CAS validation URL). 6. CAS checks whether this supplied ticket is valid and associated with the requested service. After successful validation, the CAS server destroys the ST and sends the userid back to the application. 7. The CAS client grants the access to the user and sets the ST cookie for continued access. After successful login, the single sign-on feature allows the user to get authenticated with other protected web resource without re-entering password. Single sign-on flow: 40

41 41 Figure single sign-on after initial authentication 1. An authenticated user attempts to access a resource protected by a CAS client. 2. As no service ticket (ST) is given, the user is re-directed to the login URL to use the central authentication service. 3. As the user has already been authenticated, there is a valid TGC. The CAS server checks the TGC, provides a ST and redirects the browser to the CAS client calling service 4. The application extracts the ticket, passes the ST and service name back to the CAS server for verification (using the CAS validation URL). 5. CAS checks whether this supplied ticket is valid and associated with the requested service. After successful validation, the CAS server destroys the ST and sends the userid back to the application. 41

42 42 6. The CAS client grants the access to the user and sets the ST cookie for continued access. Logout The TGC can be destroyed by calling the CAS logout URL (or it will expire after eight hours). The credentials are stored in non-persistent (session) cookies which will be deleted by the browser when the browser session is closed. Security Overview The password is only sent to the central CAS server via SSL, none of the applications could gain access to the user s credential. The authentication ticket uses a 50-byte random number. The Ticket Granting cookie only contains session key without user data, it allows the CAS server to validate the user without requiring them to re-enter the credentials. The Service Ticket is 20-byte number designed as a one-time-use-only credential but not a session key. A Web application only ever sees its own ST. It will expire as soon as the web application verified it. All the cookies are host cookies so only the originating host gets them back Cosign Solution Cosign is an open source project recently developed at the University of Michigan to provide a secure single sign-on web authentication system. Source: Components and Roles Cosign Server The Cosign server is made up with two service modules: the CGI module and the Daemon module. The CGI module handles most of the user interface for user to login and logout of the central Cosign server. It is also responsible for registering each service a user logs into which will tie the user's central login cookie to their session on individual application servers. The Deamon module handles the ticket cache. It is responsible for maintaining the 42

43 43 state of all user sessions and keeping track of all of the service cookies that represent the web applications which the user has accessed. Filter In cosign parlance, the authentication filter is the piece of software required on a web or application server to participate in the single sign-on & proxy environment. Cosign system uses a filter to determine the protected web resource. The filter is responsible for assuring the user is authenticated when he/she requests a restricted service. The filter is also used to collect the user s authentication information which will be used by some authorization mechanisms for further access decisions. Authentication Model Initial Cosign authentication flow - unauthenticated access to a protected resource: 43

44 44 Figure unauthenticated access to protected Web resource 1. An unauthenticated user attempts to access a protected web service. 2. The authentication filter on this service checks for the existence of a service cookie. As the user has not visited this protected service before, there is no service cookie presented. So, the authentication filter generates and sets a service cookie, then redirects the user to the Cosign server. 3. The Cosign server checks if this user has a valid login cookie set. As there is no login cookie exists, the service cookie register fails. The Cosign server generates and sets a login cookie, then presents a login form to the user. 4. The user enter the userid and password, sends them back to the cosign server, 44

45 45 along with the login cookie and the service information. 5. The Cosign server verifies the credentials. If authentication succeeds, the server associates the login cookie with the service cookie, and re-directs the user back to the original URL requested, along with the service cookie. 6. The application filter checks the service cookie with the Cosign server. The server verifies that the user is actively logged in and returns the userid. 7. The cosign filter checks response message, grants user permission to access the service he/she originally request, and caches this information as necessary, so it doesn t need to access the Cosign server to validate every request to the web resource. After successful login to the central Cosign server, Cosign's SSO feature allows the user to get authenticated with other protected web resource without re-entering password. Single Sign-On flow, authenticated access to the protected service: 45

46 46 Figure single sign-on after initial authentication 1. An authenticated user issues a request to access a protected web service. 2. The authentication filter on this service checks for the existence of a service cookie. As the user has not visited this protected service before, there is no service cookie presented. So, the authentication filter generates and sets a service cookie, then redirects the user to the Cosign server. 3. As this user already has a valid login cookie set, the Cosign server check the login cookie, associates the login cookie with the service cookie, and re-directs the user back to the original URL requested, along with the service cookie. 4. The application filter checks the service cookie with the Cosign server. The server 46

47 47 verifies that the user is actively logged in and returns the userid. 5. The cosign filter checks response message, grants user permission to access the service he/she originally request, and caches this information as necessary, so it doesn t need to access the Cosign server to validate every request to the web resource. Logout Users can logout of all Cosign-protected services by visting a centralized logout URL. Security Overview Cosign is a single sign on system which is designed to allow access to restricted websites using a centralized sign on mechanism. Cosign SSO solution has a very special architecture. It issues both the login cookie and the service cookie before the user is validated. Users only need to send the password to the central Cosign server via SSL. Once the authentication succeeds, these two cookies will be associated with internal state. Unlike other cookie-based SSO solutions, Cosign does not use a domain or public cookie to allow cross-server authentication. Both the Cosign server and the departmental web servers have their own cookie. All the Cosign cookies are host cookies that only the originating host could get them back. This means, a compromise of a service will only affect that service but not the whole system. All the cookies which are used in the system only contain the session keys without users data. The service keys and authentication keys are 93-byte base64 encoding of randomly-generated strings, even if compromised, no sensitive information about the user or service will be revealed Solution Comparison This comparison mainly focuses on the reliability and security based-on the solution designs. As all the systems are still in development, they may well change over time, so this table should only be treated as an indicator. Reliability Passport It will be vulnerable both to the network and server failures. (As the "granting cookie" is signed by login server s private key, and encrypted by the symmetric key shared between the application server 47

48 48 and login server, the server failure will invalidate all the authentication cookies). WebAuth It will be vulnerable to network failure. Strong resilient server capability (As the cookies are still in the browser and not tied into the login server, even if the server is down, existing sessions do not need re-authentication). CAS Cosign It will be vulnerable both to the network and server failures. (The CAS server holds a credential cache in the server memory. The server failure will cause all cookies in use become invalid and re-authentication of all user sessions will be required.) Strong resilient server capability (As the cookies are still in the browser and not tied into the Cosign server, even if the server is down, existing sessions do not need re-authentication). Security Passport Using the Triple DES encryption scheme. Passwords are only sent to the central Passport server protected by SSL. WebAuth Passwords are sent only to the central login server over SSL. Communications between the browser, the application server and the login server use SSL. Shared symmetric keys are used to encrypt tokens between the login server and application servers; servers private keys are used to encrypt tokens so only this server could decrypt it. Both the application server and login server use randomly-generated 128-bit AES keys to encrypt their tokens. CAS Passwords are sent only to the CAS server protected by SSL. All the communications with CAS server is over SSL. No domain cookie is used in this system. All CAS cookies are host cookies sent only to the originating server that set it. So, a compromised service host will only affect that service without representing a compromise of the whole system. All the CAS cookies are random strings without user data. Even if it is compromised, no revealed sensitive information about the 48

49 49 user or service will be betrayed. Sessions only has hard timeout Cosign Passwords are sent only to the central Cosign server over SSL. Communications between the browser and the authentication filter and Cosign server are protected by SSL. No domain cookie is used in this system. All Cosign cookies are host cookies sent only to the originating server that set it. So, a compromised service host will not represent a compromise of the Cosign system as a whole. All the Cosign cookies only contain the session keys which are randomly-generated strings, even if compromised, no sensitive information about the user or service will be revealed. Session have both idle timeout and hard timeout Summary Both the Passport and the WebAuth use a very similar architecture. They make use of a central authentication server which shares the symmetric keys with each application server for encrypting and decrypting the tokens sent, so only the recipient can read the contents. Figure high-level architecture of Passport and WebAuth solutions Passport is one of the most widely used web SSO solution in the world. But its old 49

50 50 design has a series of security weaknesses such as Cookies problem, Key management, and etc. There are also a number of different ways to attack to the Passport, e.g. Fake merchant attack, Active attack, DNS attack and Cookie attack. David P. Kormann and Aviel D. Rubin give an itemized analysis in their paper Risks of the Passport Single Sign-On Protocol. [14] WebAuth uses randomly-generated 128-bit AES keys instead of using the Triple-DES encryption scheme, which seems a little more secure than Passport solution. Moreover, WebAuth could use a real Kerberos authentication, which means: the cookie shared with the login server really is a Kerberos ticket-granting ticket and the cookie issued for access to an application server really is a Kerberos service ticket. This could solve many of the security problems associated with ticketing systems. Both Passport and WebAuth use a widely scoped cookie to transfer the authentication assertion between the login server and the target application server. As all the information about the authenticated user is kept on the user s browser in the form of cookies, the departmental application server does not need to communicate with the central authentication server to validate the cookies. This makes the authentication server is very distributable and thus the whole system is high scalable. But unfortunately, this stateless design also brings some relative security limitations. The cookie which the application server consumes may contain some sensitive information about the user, and it can be read by any web server in the domain, so, any vulnerable server could compromise it. Browser hacks and cross-site scripting attacks, for instance. The ability to intercept a cookie and use it for an attack is a weakness in this architecture. And let s assume what will happen if any one of the shared secret keys between the authentication server and application server is compromised. In the worst case, it might give hacker access to the users authentication tickets, and then it would be catastrophic as the whole system is compromised. Unlike the two web-sso solutions mentioned above, Cosign and CAS do not use a domain cookie to allow cross-server authentication. Both of them have a real good design. 50

51 51 Figure high-level architecture of CAS and Cosign solutions CAS and CoSign also use the cookies, and just like other cookie-based solutions, they are technical vulnerable to some attacks too. But the cookies they use only contain a random key, even if it is compromised, no confidential information about the user or service will be revealed. So, this architecture seems more secure as it is impossible for an attacker to obtain any sensitive information relating to the users or sessions from the cookies. The biggest drawback of these two solutions might be the lack of technical documentation, especially the Cosign solution. I can find nothing valuable on its website except an overview and the source codes, so it s a little hard to get the technology details of this solution. In CAS solution, all the CAS credentials are cached in the CAS server memory and can not be retrieved from the hard disk. The session cookies in the browser are random strings which are simply an index map onto the user in the credentials cache. So, if the CAS server fails down, all the browser cookies in use will become invalid, and re-authentication of all user sessions will be required. This causes a single point of failure problem. However, this design can also provide some benefit. If some users refuse to accept cookie, it will only reduce the SSO functionality of CAS, but will make all the other cookie based solutions unusable. Moreover, the design of ST probably is the best feature in CAS solution. ST is a one-time-use-only opaque and will expire as soon as the web application verified it. The web application only handles its own ST. 51

52 52 Although someone might think that CAS heavily relies on the J2EE application server could be a big burden, as in my project, the existing application system is also JAVA-based and we do not need additional cost to set up the J2EE environment, so this shouldn t be a big trouble. As we see from the descriptions and the tables above, each of the solution has particular strengths and weaknesses. We should carefully consider the existing environment before choose a particular SSO solution. 52

53 Technology Requirement Before we start our project, there are some important techniques we should understand: the HTTP communication between the client and server, the implementation of safe redirection, the use of secure sockets layer and secure cookie HTTP Client-Server Communication The Hypertext Transfer Protocol, an application-layer protocol, is one of the most important parts to implement the World Wide Web. HTTP is primarily used to transfer hypertext documents and other files from Web servers to Web clients. [15] HTTP is a client/server-oriented, request/reply protocol. The simplest communication consists of an HTTP Request message sent by an HTTP client to an HTTP server, and an HTTP Response message returned from the HTTP server back to the HTTP client. When a TCP connection is set up, the HTTP communication takes two steps which are described as follows: 1. Client Request: The client sends an HTTP request message which is formatted according with the HTTP standard. This message specifies the target resource that the client wants to interact, and optionally contains some information to be provided to the server. 2. Server Response: The server receives the HTTP request and interprets it. Relative to the HTTP request, it takes some operations, creates an HTTP Response message and sends it back to the original client. This HTTP response message indicates whether the request succeeds or fails, and optionally contains some appropriate information that the client requested. The basic HTTP communication scenario is shown as following: 53

54 Safe Redirection Figure Basic HTTP Client/Server Communication A redirection is a type of command sent from the server that directs a browser to another location. In most SSO solutions, it is used to send unauthenticated users from web application to the central authentication server, and send them back to the original application after authentication succeeded. Generally speaking, most redirections are transparent to the end-users. There are two ways of user redirection using Java: using the HttpServletResponse object's sendredirect method or sending HTML and JavaScript to the client, which initiates a POST. The second one obviously has strong advantages when compared to the first one. First, the HTML form action is a POST which means the query string information is not visible from web browser. This efficiently hides the full URL and prevents the reply attack by copying-and-pasting the URL string. Second, using HTML and JavaScript, there is no restriction on the amount of information which can be passed to the server. [16] When a user is redirected from generic application server to central authentication server, he/she usually may send the following information: 1. Action: what the member server wants, for example, authentication. 2. Return URL: original URL to the requested resource. 3. Server identifier: the identity of the application server Secure Sockets Layer (SSL) Why we need SSL? True Kerberos authentication is not available on the most standard web browsers people use. 54

55 55 Kerberos authentication is mediated by a departmental HTTP server; this means the server must receive and handle passwords. Obviously nobody wants to transmit his/her password in clear over an insecure network. SSL Overview Secure Sockets Layer (SSL) is a handshake protocol originally developed by Netscape for to providing privacy and reliability between two communicating applications via the Internet. It is used for allowing a server to authenticate itself to a client, allowing a client to authenticate him/her self to the server, and allowing both of the client and server to establish an encrypted connection between them. [17] The SSL is an application independent protocol includes two sub-protocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol is used for defining the format used to transmit data. The SSL handshake protocol is used for exchanging a series of messages between the server and client after an SSL connection is established. The SSL protocol is supported by most standard browsers, such as Netscape Navigator and Internet Explorer. Once the web server has a digital certificate, the SSL-enabled browsers can communicate securely with the server using SSL ( URLs that require an SSL connection start with https instead of http ). The SSL protocol uses both asymmetric key exchange and symmetric key exchange. It takes a security handshake to initiate a secure connection between the client and the server using asymmetric key. During the handshake, the client and server both agree on a secret key. Confidentiality and integrity of the exchanged data between them is based on the symmetric cryptography. The key exchange is designed as following: Client connects to server via https. Server sends its certificate and authenticate to the client. They use the public-key encryption technique to generate a shared secret session key to encrypt all communications between them. An encrypted SSL connection is now established. Many web sites obtain confidential user information by using the private key to encrypt data that's transferred over the SSL connection. SSL can be used to protect any TCP/IP based connections. Since it is located between the Network layer and the Application layer, the application level protocols do not need to be changed Secure Cookie A cookie is a text-only string of information that is sent to your browser from a World Wide Web Server you visited. Web servers and browsers typically use cookies to capture information for subsequent communications, which provides continuity and state across HTTP connections. After a browser received a cookie, it will then send that 55

56 56 cookie back to the server whenever it visits. The browser will only send the cookie to the server that originally set it. [18] Most cookies are made up of six parameters: name, value, domain, path, expiration date, and secure flag. There are two flavors of cookie: Persistent Cookies: Cookies are usually written to a cookie file on the hard drive with a defined expiration time. They could be retained until they expire. Session Cookies: Cookies are stored in the temporary memory space without a specified expiration. They will be discarded as soon as the browser is closed. Persistent Cookie is inherently insecure because an attacker could copy this cookie information to another machine where he or she could masquerade as the victim. Session Cookies can't be copied, read, or sniffed, this effectively protect users from a cookie file attack. The cookie information can be accessed by a higher level server-side language or by JavaScript on the client-side. 3.4 WSSO Solution What does WSSO mean? WSSO means Web Single Sign-On. WSSO also means WRL (Wuhan Railway Logistics Company) Single Sign-On. The WSSO system is designed base on the CAS system. It also inherits a number of good ideas from other web SSO solutions Design Consideration The design makes the following high-level assumptions about solution architecture and infrastructure: For now, the project will only specify an SSO solution for HTTP distributed applications. The project will not create a federated system similar to the Liberty alliance at present. It assumes all user credentials will be stored in a single enterprise user directory. The solution should work with standard web browsers; no client-side software required. 56

57 57 Try to reduce exposure of user passwords to application web servers. If needed, users credentials are only passed to the central well-protected server through an encrypted tunnel. Authentication and authorization is centralized to a unique server. Have strong security by using the Kerberos-based authentication mechanism. Provide group-based authorization service to implement access control. Automatic HTTP redirections should be used, from applications to the WSSO server for unauthenticated users, and back to applications when the users are authenticated. Support both application logout and single logout. Support ending a session due to hard time-outs and soft time-outs Have extensible framework for future development. For example, the solution should be extensible to support different authentication mechanisms and across various platforms. 57

58 Structure and Components Browser Figure Architecture End-users interact with the web-based applications and WSSO server via web browsers. The browser is responsible for accepting all valid cookies set by the WSSO server and filter. The WSSO system requires some standard browser features as follows: SSL supported; Understand basic JavaScript and perform HTTP redirections; Store cookies. These requirements are met by all standard web browsers, such as Microsoft Internet Explorer, Netscape Navigator. WSSO Filter The WSSO filter is not a part of the central WSSO server. It is a light-weight plug-in 58

59 59 that resides on the application server and acts as an enforcement agent for authentication. The filter is responsible for ensuring all accesses to the protected resources are only permitted by users that have been authenticated and appropriately authorized. The WSSO filter Redirects the unauthenticated user to the WSSO server for login. Validates service tickets against the WSSO server. Issues cookies to user to maintain the authentication state. Invalidates the user's authentication state when a valid logout request is received. WSSO Server The WSSO server is the core of the system. All logging issues, session management, authentication and authorization services reside within this WSSO server. The WSSO server is made up with two service modules: the authentication module and the authorization module. Authentication Module The authentication module is responsible for handling login and logout requests, interacting with end-users to gather authentication information, verifying the credentials using a Kerberos-based authentication, and issuing the authentication responses. It sets the ticket granting cookie in browser when authentication succeeds to establish a session that exists until the user logs out or the authentication ticket time-out, and also issues the service ticket of the requested service to the authenticated user. Authorization Module The authorization module provides two kind of service: access control and verification sending. The authorization module is responsible granting or denying access to protected resources based on an access control policy. It checks the user s attributes and relative permissions, and then determines whether the authenticated user has the necessary privileges to access the requested resource. It responds to unauthorized requests with an error message and responds to authorized requests by allowing the desired access. This module is also responsible for verifying service ticket. It checks the ST and service identity received from service, sends back the verification including the user identity and destroys the ST immediately. 59

60 60 Generic Web Application Application that uses the web-based technologies is called Web Application. Web application is a dynamic extension of the Web server. There are two types of Web applications in WRL Company s existing network environment: Static web applications: refer to some static files resided on the web server s hard disk. Dynamic web applications: invoke some programs running on the web server and application server. Active Directory The active directory contains shared information about the security policies, user profiles and other configuration data. The active directory is used by the WSSO server for various kinds of information, such as passwords, user attributes, system configurations, etc Authentication Model Initial authentication flow: 60

61 61 Figure unauthenticated access to the protected resource 1. A non-authenticated user attempts to access a restricted protected web. URL examples of service request: 61

62 62 2. Since there is no service session exists and no service ticket (ST) is given, the user is re-directed to the login URL to use the central authentication service, passing the web service as a service parameter in the query string. URL examples of WSSO logins: 3. After received the request string, the WSSO server first checks whether the web service is an authorized service. Only the services appear on an authorized service list are permitted to request WSSO server. This effectively prevents the cross-service attacks. After validated the web service, the WSSO server checks the existence of a valid Ticket Granting Cookie (TGC). As the user has not yet been authenticated, no TGC is given. So, the server sends a login form that prompts the user for the user identify and password. 4. The user returns the user identity and password back to the WSSO server to do the Kerberos-based authentication. The authentication module determines whether or not it can decode a Kerberos ticket-granting ticket in the Active Directory for the given user identity with the corresponding password. If the credentials are invalid, the WSSO server will display the reason of failure (wrong user identity or wrong Password, for instance), and present the user with some help information. 5. If authentication succeeded, the authorization module checks the Directory to handle a group-based authorization process for access control. Based on the user's attributes it determines whether the user is permitted to access the requested service. For example, the user must be a member of a particular group. If the authenticated user do not have right to access the requested service, the WSSO server will display an error message. If the authenticated user has the appropriate privilege to request the service, the WSSO server will generate a TGC and sends it to the browser as a non-persistent cookie. Then, the server re-directs the user to the service URL appending a ST parameter on the request. URL examples: 6. The filter extracts the service ticket of the HTTP request query string, passes the ST and service identity back to the WSSO server for verification. URL examples of WSSO validation: 7. The WSSO server s authorization module verifies the ticket and service identity, sends the validation information back to the application in a XML format and destroys the ST immediately 8. From the validation information, the WSSO filter receives the authenticated user name and establishes an authenticated browser session. Then, it grants the access to the user and sets the ST cookie. If a valid session exists on the web or application server, there is no need to call the WSSO server for authentication. 62

63 63 Single Sign-On flow: Figure single sign-on after initial authentication 63

64 64 1. An authenticated user attempts to access a restricted resource. 2. As no ST is given, the user is re-directed to the central WSSO server, appending a query string identifying the service requested. 3. The WSSO server receives the query string and checks whether this service is an authorized service first. As the client has already established a session with CAS, the web browser presents a secure cookie containing a string identifying a ticket-granting cookie to authentication module of the WSSO server. If the TGC is valid, the authorization module checks the Directory to handle a role-based authorization process for access control. Based on the user's attributes it determines whether the user is permitted to access the requested service. If the authenticated user do not have right to access the requested service, the WSSO server will display an error message. If the authenticated user has the appropriate authority, the WSSO server redirects the browser to the original service URL, appending a ST parameter on the request. 4. The filter extracts the service ticket of the HTTP request query string, passes the ST and service identity back to the WSSO server for verification. 5. The WSSO server s authorization module verifies the ticket and service identity, sends the validation information back to the application in a XML format and destroys the ST immediately 6. From the validation information, the WSSO filter receives the authenticated user name and establishes an authenticated browser session. Then, it grants the access to the user and sets the ST cookie. If a valid session exists on the web or application server, there is no need to call the WSSO server for authentication. Note: All the re-direction is transparent to the user. Logout Since all the cookies are non-persistent cookies, the simplest way to logout is closing the relative browser. This solution provides the single logout feature as well as the departmental logout from any application. URL examples of WSSO logout: Security Overview Credential Security Users only need to send their passwords to the central WSSO server over SSL. Generic web applications never see any password; just receive the service tickets which are authentication assurances issued from the central server. This reduces the exposure of users credentials to the other web applications and efficiently improves the password 64

65 65 security. Re-authentications are transparent to users by using an authentication ticket which is called Ticket Granting Cookie (TGC). The TGC can be treated as the user s passport to the central WSSO server. It allows the user to get the service tickets from the WSSO server without re-entering password. The TGC does not contain any sensitive information about the user. It is simply a session identifier like some adequate secure random data used between the web browser and the WSSO server. (The value stored in this cookie is the host info of the WSSO server, a link to the authentication service, and an index into the session pointer on the WSSO server.) Thus, this cookie is not guessable in a reasonable period of time through brute-force attacks, even it is compromised, no confidential information about the user will be revealed. The service ticket is an opaque string that is used by the client as a credential to obtain access to a service. It s only usable for the service to which it was sent and only valid for one ticket validation attempt. Whether validation is successful or not, it will be destroyed immediately, so any future validation attempts of that same ticket will fail. The service ticket cookie is a session cookie stored by the application server. All the WSSO tickets are non-persistent cookies and stored in the memory of the browser, so they will be destroyed when the browser exits. They are only visible to servers that set them. This means that service tickets are only sent to the web server where the service is running. And ticket-granting cookies are only visible to the WSSO server. Note: All the communications with WSSO server is protected by SSL, which protect the credentials against the man-in-the-middle attack and impersonation attack. Authentication and Authorization Service WSSO server performs authentication using a Kerberos-based approach. Active Directory server is an LDAP3-compliant directory server and supports Kerberos V5 authentication mechanisms. The authentication module in WSSO server determines whether or not it can decode the Kerberos ticket-granting ticket in the Active Directory for the given userid with corresponding password sending from the end-user. If the credential is valid, the user will be successfully authenticated. WSSO server performs authorization using a groups-based approach. System administrator sets different rules for end-users belong to different groups that allow appropriate access to network resources. "Allow access to anyone in these groups, except if they belong to any of those groups. Deny access to anyone else". This means a user is allowed to access a restricted resource if he/she belongs to any group in the 'Groups to allow' list and do not belong to any group in the 'Groups to deny' list. 65

66 66 In this project, I use the JAVA Authentication and Authorization Service (JAAS), a framework and programming interface, to design and implement both Kerberos-based authentication and group-based access control capabilities. Why choose JAAS? JAAS is an ideal tool for authentication and access control in a multi-user environment. The JAAS can be used for two purposes: Authentication: determine who is executing Java code, regardless of what kind the code is (a stand-alone JAVA application or a servlet, for instance). Authorization: make sure that the user has the appropriate permissions to perform the actions. JAAS provides a standard Pluggable Authentication Module (PAM) based authentication framework which allows applications to remain independent of the underlying authentication mechanism, and supports user-based authorization. It is a useful mechanism for implementing single sign-on in a network environment, especially in a web applications system base on JAVA. [19] The detail of JAAS programming is described in the appendix. Single Logout Design Logout issues for the SSO system are real complex. For example, what do users actually expect when they logout of an application? Does logging out of one application also trigger logging out of all the other authenticated applications the user visited during the same browsing session? Most web SSO systems only provide the single sign-on feature. Usually, they do not provide single logout across the same set of applications. In the WSSO design, I attempt to add a server-based single logout feature. Whenever the WSSO server generates a service ticket, it also creates a login record to remember the service login and stores a login list in the user s session. When the server receives a single logout request, it loops through the login list of service tickets and sends the "logout" request to all the appropriate services. Time-out Management To meet several function requirements, different tickets have different time-out period. Ticket time-out management is an important issue in a web SSO authentication and authorization environment. Typically, there are two kinds of time-out: Idle time-out is the length of time where the connection will be automatic terminated if a user is idle for a certain amount of time without any interaction to the server. 66

67 67 Absolute time-out is the maximum lifetime that a ticket is valid. After a certain amount of time, the user is forced to re-authenticate and a new ticket should be issued. The time-out is used to prevent problems with the possibility of re-play attacks if people forget to log out or leave for a long time. The authentication ticket (TGC) has both idle timeout (which defaults to 1 hour) and absolute timeout (which defaults to 8 hours). As the service ticket is designed as a one-time-use-only credential and will be destroyed immediately after first use, it only has the maximum lifetime about 3 minutes. Redundant Server Setting Like the CAS server, WSSO system has the Single Point Failure problem too. The WSSO server also holds a credential cache in the server memory. The cookie in browse is just session cookie which not written into the hard disk. Moreover, the cookie is a random string used for mapping onto the user in the credential cache. If the server turns down, all the cookies in use will become invalid and all the existing user sessions will be required to re-authenticate. For reducing the risk of failure, it is recommended to set up redundant WSSO servers. So, the WSSO server is designed to support replication between multiple servers. Figure set up redundant WSSO server In theory, it is possible to configure by setting redundant WSSO server. But the design and configuration should be a little complex as all the cached data need high level synchronization. 67

68 68 Chapter 4 Conclusion and Future Work 4.1 Conclusion Designing and implementing Single Sign-On system with a comprehensive security solution is a rather complex problem. Since there is no universal single sign-on standard exists, the method used to implement SSO varies with the requirements. There is no one size fits all solution. Selection of the right method for you depends on many factors. So, you have to realize the actual situation, understand what your needs are and develop a set of specific requirements before you design and implement the SSO authentication system. The WSSO solution allows users, with standard web browsers, to authenticate to web applications across different web servers, using a standard username/password central authentication and authorization service. It provides an enterprise-wide web single sign-on and access control solution that can be administered in a consistent and transparent manner. The WSSO helps users for reducing the number of passwords the users have to remember, making web service login easier, reducing the cost of helpdesk, and potentially improving security by eliminating the need to writing down the passwords that unauthorized users may see them. In fact, the WSSO solution had better not be treated as a security issue. It is more like a customer convenience issue as well as a cost savings issue. This solution should not be used as an authentication method for very sensitive information and service. I propose that use this solution to provide a SSO authentication service for the systems which only require moderate levels of security. 4.2 Future Development To meet different levels of requirements, this solution could be upgraded and extended to incorporate support for various authentication mechanisms and interface modes. The solution Should have a generic authentication module to provide different authentication methods such as password-based, Kerberos-based, PKI-based and etc. Should have an authorization module to determine the user s privilege for access control. Should have a federation services module based on Liberty profile schema, 68

69 69 adopting SAML protocol and Liberty distributed computing policy to implement Liberty federation. Should have an identity management module to manage all the user and service identities. Should have a utility module to provide utility functions such as exception handling, data format, symbol resolve and any other miscellaneous functions. By combining the common functions and special advantages of different Single Sign-On solutions, I provide a comprehensive SSO model. The high-level architecture of the model is shown as follow: Figure 4.2 high-level architecture of a comprehensive SSO model This comprehensive model covers most functions demand and can be used as a blueprint for the further development of Single Sign-On solution. 69

70 70 Appendix Appendix A JAAS Authentication using Kerberos Using JAAS authentication from your application typically involves the following steps: 1. Instantiate a LoginContext 2. Pass a CallbackHandler to the LoginContext, for gathering or processing authentication data 3. Perform authentication by calling the login method 4. Perform Privileged actions using the returned Subject after login succeeds Below is a basic diagram of how to implement Kerberos-based JAAS Authentication: Figure Kerberos-based JAAS Authentication 70

71 71 The JAAS login configuration entry for a client application. Krb5LoginModule use the native ticket cache to get the TGT available in it. The authenticated identity will be the identity of the Kerberos principal that the TGT belongs to. Create the Login Configuration Sample { com.sun.security.auth.module.krb5loginmodule required; }; This entry is named "Sample" and it specifies that we use the Krb5LoginModule in the com.sun.security.auth.module package to performs Kerberos authentication. This Krb5LoginModule is required to "succeed" in order for authentication to be considered successful. The Krb5LoginModule succeeds only if the name and password supplied by the user are successfully used to log the user into the Kerberos KDC. [JAASker1] Instantiating the LoginContext import javax.security.auth.login.*; import com.sun.security.auth.callback.textcallbackhandler;... LoginContext lc = new LoginContext("Sample", new TextCallbackHandler()); During initialization, the LoginContext finds the configuration entry "Sample" in the JAAS configuration file to determine which LoginModules to load. The LoginModule doesn t communicate with the user directly. It invokes a CallbackHandler to perform the user interaction and obtain the requested information. We use the TextCallbackHandler which outputs information to and reads input from the command line. Calling the LoginContext's login Method try { lc.login(); } catch (LoginException) { // Authentication failed. } The login method calls methods in the Krb5LoginModule to perform the login and authentication. The Krb5LoginModule will utilize the TextCallbackHandler to obtain the user name and password. Then the Krb5LoginModule will use this information to get the user credentials from the Kerberos KDC. 71

72 72 Figure the relationship among the JAAS configuration elements. 72

73 73 Appendix B JAAS Authorization Once authentication has successfully completed, JAAS provides the ability to enforce access controls upon the principals associated with the authenticated subject. This means permissions can be granted based on who runs the codes. There are three basic requirements for using JAAS authorization: 1. The user must be authenticated. 2. Principal-based entries must be configured in the security policy. 3. The Subject which is created as the result of successful authentication must be associated with the current access control context. Access Control Implementation: Figure JAAS Authorization JAAS supplements this architecture by providing the method, Subject.doAs, to dynamically associate an authenticated subject with the current AccessControlContext. Permissions which associate a set of resources (with some possible actions) are the heart of authorization. In this project, we need to create a special URL permission class for controlling access to resource like URLs. JAAS treats groups simply as named principals. Therefore, it supports group-based access control, allowing permissions to be assigned to different groups instead of individual users. For example, a user may be a member of the group Market and the permissions to access the supply and demand information may be assigned to the 73

74 74 Market group, giving the user access as well. Group-based access control makes managing authorization much easier. 74

75 75 Appendix C Glossary ACL API CA DEC Access Control List Application Programmers Interface Certificate Authority Data Encryption Standard. Specifies the interface to which an application programmer can write code. A data encryption standard developed by the US government based on classified research. AS HTTP HTTPS IP (Kerberos) Authentication Server Hypertext Transfer Protocol SSL-encrypted Hypertext Transfer Protocol Internet Protocol Kerberos KDC Key Distribution Center An authentication protocol for use on inherently insecure networks such as the internet. LDAP Lightweight A protocol for accessing online directory 75

76 76 Directory Access Protocol service PKI RSA Public Key Infrastructure SAML Security Assertion Markup Language A public-key encryption and authentication algorithm. an XML framework for exchanging security information over the Internet SOAP Simple Object Access Protocol SSL Secure Sockets Layer XML Extensible Markup Language A recommendation for creating specialpurpose markup languages. 76

77 77 References [1] M. E. Kabay, Identification, Authentication and Authorization on the World Wide Web, Oct 16, nd_authorization_on_the_world_wide_web.html [2] The Open Group, Introduction to Single Sign-On, 20 May, [3] Laura Taylor, Understanding Single Sign-On, 28 May, [4] Sun, Sun Java System Access Manager Technical Overview -- Federation Management, [5] Jan De Clercq, Single Sign-On Architectures, [6] Jan De Clercq, Introducing Credential Manager, December [7] Computer Associates, etrust Single Sign-On, [8] Diana Berbecaru, Antonio Lioy and Marius Marian, PKI-Based System Management, 26 October, [9] Carl Ellison and Bruce Schneier, Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure, Computer Security Journal, v 16, n 1, 2000, pp [10] M-tech Information Company, Definition of Password Synchronization, [11] MIT, Kerberos: The Network Authentication Protocol, April 22, [12] J. Kohl and C. Neuman, The Kerberos Network Authentication Service (V5), September 1993, Network Working Group 77

78 78 [13] B. Clifford Neuman and Theodore Ts'o, Kerberos: An Authentication Service for Computer Networks, USC/ISI Technical Report number ISI/RS , Volume 32, Number 9, pages 33-38, September [14] David P. Kormann and Aviel D. Rubin, Risks of the Passport Single Sign-on Protocol, July [15] Doug Lawson, Communication between client and server, [16] Abraham Kang and Donald Levy, Security for J2EE Applications, November 1, [17] CISCO, Introduction to Secure Sockets Layer, [18] Netscape, Persistent Client State HTTP Cookies [19] Mayank Upadhyay and Ram Marti, Single Sign-on Using Kerberos in Java, May 2, [20] BNX Systems, Enterprise Single Sign-On: Balancing Security & Productivity, November 15, [21] Peter Kohler, Simple Single Sign-On Solution for Web Applications, Feb 2004 [22] Ram V Marti, Charlie Lai and Ming Yung, Single Sign-on using the JAAS and Java GSS-API, 2002 [23] Gary Tagg, Implementing a Kerberos Single Sign-on Infrastructure, 2000 [24] NAC, ENTERPRISE-WIDE SECURITY: AUTHENTICATION AND SINGLE SIGN-ON, July 14, 1996 [25] Timo Tervo, Single Sign-On Solutions in a Mixed Computing Environment, September on.htm 78

79 79 [26] Diana Kelley PLANNING FOR SINGLE SIGN ON (SSO),