GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK

Antti Pyykkö, Mikko Malinen, Oskari Miettinen GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK TJTSE54 Assignment 29.4.2008 Jyväskylä University Department of Computer Science and Information Systems Jyväskylä

TABLE OF CONTENTS 1 INTRODUCTION... 3 2 THE 'ORDINARY' SSO... 3 3 OVERVIEW OF THREE DIFFERENT SSO SYSTEMS... 5 3.1 Active Directory (AD)... 6 3.2 Google SSO... 9 3.3 Facebook SSO... 11 4 DISCUSSION... 14 REFERENCES... 16

3 1 INTRODUCTION In this study we have taken a brief look at what SSO (Single Sign-On) is and what it means. We have tried to explain the SSO as shortly and simply as possible. Besides making it clear what an 'ordinary' SSO is, we have compared three different SSO systems and studied how they differ from each other both technically and in principle. 2 THE 'ORDINARY' SSO According to Fleury et al (2006) Single sign-on (SSO) is the ability to allow multiple actions to take place on behalf of a user, without requiring multiple authentications by that user. In quite a same way Anchan and Pegah (2003) say that Single sign-on is a mechanism whereby a single user-id and password pair will allow a user to access all authorized computer resources in a distributed, multiplatform computing environment, without the need for multiple authentication information. However, the most comprehensible definition for SSO can be found from the Wikipedia: Single sign-on (SSO) is a method of access control that enables a user to authenticate once and gain access to the resources of multiple software systems. (Wikipedia 2008 - Single sign-on) In other words, the user gives his/her username and password only once and is able to access a few different services without repeating this action. A simple example of this could be for instance Google s services: once you sign in e.g. in Gmail, you are able to use other Google services like Google Calendar or Google Docs without having to signing on in them again. What is common to nearly all ordinary SSO services is that they consist of services brought by a single service provider. In our example above the service provider is Google. Before the SSO systems, the user had to sign in singly every service at a time. Figure 1 illustrates this situation that is, user using few services with no SSO system available.

4 Figure 1: Using few services with no SSO system available. (Source: The Open Group) As seen in Figure 1, the User has both the Primary and Secondary Domain Signons and Shells where the Domains can be seen as services brought by a single service provider. Each Domain has its own sign-on system and management information base that manages the user account. In order to use a service the user needs to sign in singly each service, even though they are connected to each other at least in principle via the producer. Using the ordinary SSO changes the case quite different.

5 Figure 2: The ordinary Single Sign-on. (Source: The Open Group) In this case, the services are under SSO system through which all the Secondary Domains are trusted fellow services with the Primary Domain. Now the user needs to sign in only once in order to use also all the other (secondary) services which one is able to access from the Primary Domain the user signs in first. Unlike seen in the Figure 1, there is only one User Account Manager that handles the user s account information on behalf of the Domains. 3 OVERVIEW OF THREE DIFFERENT SSO SYSTEMS In this chapter we compare three different SSO systems with each other and try to open up them for the reader. The chosen SSOs are Microsoft s Active Directory (AD), Google SSO and naturally Facebook SSO. When selecting the SSOs for this assignment, we tried to choose three systems that differ from each other, still being essential and good to know.

6 3.1 Active Directory (AD) Active Directory (AD) is an implementation of Lightweight Directory Access Protocol (LDAP) directory services by Microsoft that manages information about users and their resources, and allows users to access and manipulate this information. By using Active Directory, operators can manage all elements of their networks, including computers, groups, users, security policies etc. across a domain. In addition, multiple domains can be managed simultaneously. Domains may have trust for each other meaning that domains may share authentication information (user authenticated to domain A will automatically be authenticated to domain B). (Microsoft 2008; Wikipedia 2008 Active Directory) Active Directory holds information about the objects in hierarchical tree model. Objects have three categories: resources, services and users. Each entity (for example a user) has its unique identifier (Distinguished Name (DN)) and attributes, for example first name, last name and password. Attributes are defined in schemas, where attribute syntax is also presented. For example, attribute email might require a value with @ -character. Figure 3 illustrates a single user object in Active Directory. (Wikipedia 2008 Active Directory; Dulaney et al. 1999)

7 Figure 3: User properties in Active Directory AD is common in large computer networks where ability to manage different users and resources effectively is needed; for example, Jyväskylä University s (JYU) network is operated using Active Directory. Signing in to JYU s domain can be seen as a single sign-on function client communicates with Active Directory in order to gain access to applications/services/resources on the network. Procedure follows this pattern:

8 Figure 4 - Kerberos authentication (Microsoft 2008) The figure presents how Windows uses Kerberos authentication protocol as primary method for authenticating users. Authentication is based on tickets; ticket is a validation to use network resources. When user logs on to a domain client s logon credentials are sent to Kerberos authentication service (KDC in this case), which checks their validity from Active Directory. If whole authentication process succeeds, KDC gives client a session ticket that tells which services/resources user can access. Each application server then verifies that all accessing users have a valid session ticket. If application server needs to contact another application server, it can use this ticket to impersonate client and that way access other service. This can only happen, if trust exists in network within domains. (Microsoft 2008; Dulaney et al. 1999) However, this SSO method is problematic as not all services can be easily mapped to Active Directory. Some applications might offer web-based authentication (like Korppi does) and therefore users need to continue logging in to different applications, as there was no SSO present. In summary, Active Directory is a good way to simplify network management in terms of restrictions and policies, but does not offer easy way to make a true SSO system where a single login would be enough for everything.

9 3.2 Google SSO Google SSO system uses SAML (Security Assertion Markup Language) technique, which is a XML standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions) (Wikipedia 2008 - Security Assertion Markup Language). The Google SSO is a good example of a SSO system, where there is only one service provider who does not have to worry about the trust issues between the primary domain and the secondary domains, that is, the external service/application providers. In this case, the SSO system uses identity provider services to check whether the user is granted the access to the service he/she has requested or not. The basic functioning of the Google SSO system is explained in the Figure 5 below.

10 Figure 5: Logging in to Google Apps using SAML (Source: Google 2008 - Single Sign-On (SSO) Service for Google Apps) 1. The user requests to get an access to a hosted Google application (Gmail, Google Calendar, Google Docs...) 2. Google generates a SAML authentication request, which is embedded into the URL for the partner s SSO service. There is also the URL of the Google service embedded in the SSO URL. 3. Google redirects the user s browser to the partner. The redirected URL includes the SAML authentication request. 4. The URL reaches the partner that decodes the SAML request and extracts the URL for both the Google s authentication service (ACS, Assertion Consumer Service) and the user s destination URL. The partner

11 authenticates the user by either requesting the user for valid username and password or by checking for valid session cookies. 5. The partner generates a SAML response that includes the authenticated username. 6. The partner encodes the SAML response and returns it to the user s browser that forwards the information to Google s authentication service. 7. Google ACS verifies the SAML response. If the response is successfully verifies, authentication service redirects the user to the destination URL, he/she originally requested. 8. The user has been redirected to the destination URL and is logged in to the Google s application (or Google Applications). According to Google they are providing extremely reliable safekeeping for their customers to ensure the most secure, reliable, and private environment for your data (Google 2008 - Welcome to Google Apps). Since Google has tens of millions of customers, both individuals and companies, it is easy to believe that the security is and will be quite a big issue in their service planning and implementation. In brief, Google divides its security roughly under three subtitles: Physical security, Threat identification and management and Safe access. The last-mentioned, safe access includes among others a mention about the protection during the transmission of data on the wire, so that confidential data is not intercepted on the network (Google 2008 - Welcome to Google Apps). In general SAML-based SSO systems are considered highly secure. When it comes down to single sign-on systems, SAML is a prevalent standard used popularly in many companies. The OASIS (Organization for the Advancement of Structured Information Standards) Security Services Technical Committee, which has created SAML, has taken extensively into account different kinds of security and privacy threats and when used properly, SAML provides a workable and secure technique to build up SSO systems for web applications. 3.3 Facebook SSO The initial Facebook Platform API was released on August 2006, and since, developers around the globe have been able to build applications for Facebook. Official release of Facebook Platform on May 2007 also opened up the site itself,

12 giving developers stronger distribution models and access to all the integration points Facebook uses to build applications. According to Facebook itself, Facebook Platform has unlocked an access to its core value: the social graph. (Facebook 2008 - Facebook Developers High-Level Specification) "The Facebook Platform is a standards-based Web service with methods for accessing and contributing Facebook data." In addition to the Interface (API), these methods include FBML (Facebook Markup Language), FQL (Facebook Query Language) and FBJS (Facebook JavaScript). Facebook API uses a RESTlike interface, which means that every Facebook method call is made over the Internet by sending HTTP GET or POST requests to the Facebook API REST server. With the API, developers can add social context to the applications by utilizing social data like profile, friend, photo and event data. (Facebook 2008 - API - Facebook Developers Wiki) FBML is a subset of HTML, which enables a developer to gain access to many of the integration points Facebook has to offer. An example flow for how the HTML for a web app canvas is rendered is illustrated in Figure 6. Application server, which has to take care of all the business logic, calls the APIs on Facebook and produces FBML as a result, which is then presented to the user. (Facebook 2008 - Random questions - Facebook Developers Wiki)

13 Figure 6 - An example flow on Facebook architecture (Facebook 2008 - Facebook Developers High-Level Specification) Furthermore, Facebook uses a certain API key system to authenticate applications that make requests to the Facebook API server. Authentication process is illustrated in the following two figures: Figure 7 - External Facebook web application authentication process In order for a Facebook API client to use the API, the user of the client application must be logged in to Facebook. To ensure this, (1) users are redirected to a Facebook login page, which will prompt the user to log in if

14 necessary. An API key, which is uniquely assigned to the vendor, is passed along with every request. API key identifies, among other things, that the source IP for the call is acceptable. (2) Upon successful authentication, if the user has never logged in to this application before, he/she will be asked to accept the terms of service for using the application. (3) Finally, for web-based applications, the user is redirected to URL defined by the developer along with an auth_token parameter. Figure 8 - External Facebook web application session establishment The application then exchanges this token for a session key via the facebook.auth.getsession() method. This session key is then used when making request calls to the Facebook API. We presume, that users are allowed to access their Facebook applications through Facebook in a similar manner by opening sessions to applications they have joined before. There is very limited amount of information about this procedure and therefore we cannot describe this process any more specifically. 4 DISCUSSION In our essay we began by explaining what SSO is and the basic idea behind it. After that we proceeded by presenting three different SSO systems: AD, Google SSO and Facebook SSO, and gave a brief overview of principles and techniques behind them. To summarize the benefits of SSO system we can conclude that SSO is very important to the user because then users do not have to sign in singly every service they need, and they only need one pair of login credentials to access all their services. This reduces the number of authentication problems related to forgotten passwords and therefore enhances the security by reducing number of login credentials users need if the amount of accounts would grow too big, users would have to write their login information down in order to remember all of them. By using SSO, operators can more easily restrict services user may access and therefore make the system more secure. Application developers also

15 benefit from SSO systems, as they do not have to think about security and authentication in their applications. This is very important in Facebook, as users are allowed to make their own applications and integrate them to Facebook by using Facebook SSO. (The Open Group 2008; Huntington Ventures Ltd 2006) Still, SSO does not come without any problems; traditional single sign-on systems are under high load as all traffic to system goes through them. This requires fault tolerant signing systems to prevent authentication problems if one of the authentication services goes down. From the three different SSOs we studied in this research, the AD system is designed for more local computer systems whereas Google SSO and Facebook SSO are clearly developed for distributed web services. Furthermore the AD system requires substantially more administration and control as access to use one must be requested and granted. Added to this the AD system is intended for more administrative tasks, unlike the other two systems. In principle, the main difference between Google SSO and Facebook SSO is that Facebook does not use a third party as an identity provider like Google does. Another difference is that Google provides only applications developed by itself, whereas Facebook also provides applications developed by its users. This means that Facebook needs to handle lots of trust issues considering cooperation between Facebook, application developers and the users, which must also have been a big affair to take into consideration while designing their SSO. From technical point of view, Google and Facebook differ in the way their platforms work: unlike Google, Facebook uses a REST-like interface. Google SSO system uses SAML technique, which is a XML standard for exchanging authentication and authorization data between security domains. Facebook uses a certain key-token authentication system through its REST-like interface, which allows external applications to gain access to Facebook API and thus making signing on singly possible for the users. For further research we recommend study on e.g. subjects privacy and data security within SSO systems and more specific knowledge about the functioning of authority and authentication in different SSO systems.

16 REFERENCES Anchan, D. & Pegah, M. 2003. Regaining single sign-on taming the beast. In Proceedings of the 31st Annual ACM SIGUCCS Conference on User Services (San Antonio, TX, USA, September 21-24, 2003). SIGUCCS '03. ACM, New York, NY, 166-171. Dulaney, E., Sankar, V. & Sankar, S. 1999. Active Directory: An Overview [online]. 29th Street Press [refered 25.4.2008]. Available in the wwwaddress <http://www.windowsitlibrary.com/content/155/07/1.html>. Facebook 2008. API - Facebook Developers Wiki [online]. Facebook [refered 28.4.2008]. Available in the www-address <http://wiki.developers.facebook.com/index.php/api>. Facebook 2008. Facebook Developers High-Level Specification [online]. Facebook [refered 28.4.2008]. Available in the www-address <http://developers.facebook.com/specification.php>. Facebook 2008. Random questions - Facebook Developers Wiki [online]. Facebook [refered 28.4.2008]. Available in the www-address <http://wiki.developers.facebook.com/index.php/random_questions>. Fleury, T., Basney, J., & Welch, V. 2006. Single sign-on for java web start applications using myproxy. In Proceedings of the 3rd ACM Workshop on Secure Web Services (Alexandria, Virginia, USA, November 03-03, 2006). SWS '06. ACM, New York, NY, 95-102. Google 2008. SAML Single Sign-On (SSO) Service for Google Apps [online]. Google [refered 24.4.2008]. Available in the www-address <http://code.google.com/apis/apps/sso/saml_reference_implementatio n.html>. Google 2008. Welcome to Google Apps [online]. Google [refered 24.4.2008]. Available in the www-address <http://www.google.com/a/help/intl/en/admins/security.html>. Huntington Ventures Ltd 2006. Single Sign On Authentication [online]. Huntington Ventures Ltd [refered 27.4.2008]. Available in the www-

17 address <http://www.authenticationworld.com/single-sign-on- Authentication/>. Microsoft 2008. Windows 2000 Security Technical Overview [online]. Microsoft [refered 25.4.2008]. Available in the www-address <http://technet.microsoft.com/en-us/library/bb742513.aspx>. The Open Group 2008. Introduction to Single Sign-On [online]. The Open Group [refered 21.4.2008]. Available in the www-address <http://www.opengroup.org/security/sso/sso_intro.htm>. Wikipedia 2008. Active Directory [online]. Wikipedia [refered 25.4.2008]. Available in the www-address <http://en.wikipedia.org/wiki/active_directory>. Wikipedia 2008. Security Assertion Markup Language [online]. Wikipedia [refered 24.4.2008]. Available in the www-address <http://en.wikipedia.org/wiki/security_assertion_markup_language>. Wikipedia 2008. Single sign-on [online]. Wikipedia [refered 18.4.2008]. Available in the www-address <http://en.wikipedia.org/wiki/single_sign-on>.