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