Computer Systems Security 2013/2014. Single Sign-On. Bruno Maia Pedro Borges

Transcription

1 Computer Systems Security 2013/2014 Single Sign-On Bruno Maia Pedro Borges December 13, 2013

2 Contents 1 Introduction 2 2 Explanation of SSO systems OpenID SAML CAS Protocol authentication process OpenID authentication process SAML authentication process CAS authentication process Benefits and drawbacks of SSO systems 7 5 Security caveats of the different protocols OpenID caveats SAML caveats FEUP s Single Sign-On System OpenID U.Porto AAI (shibboleth) Conclusion 12 1

3 Computer Systems Security - Single Sign-On 2 1 Introduction The Single Sign-On (SSO) is a mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple IDs and passwords. There are various types of SSO architecture. Some of them are dealing with a single set of credentials and the others are dealing with multiple sets of credentials. In the former case, there are token-based system and PKI-based system. The Kerberos-based and cookie-based are belong to the token-based SSO system. In the latter case, there are credential synchronizationbased system, secure client-side credential caching system and secure serverside credential caching system. There are several SSO mechanisms available, we chose to detail the most common ones on this report, OpenID, SAML and CAS. 2 Explanation of SSO systems 2.1 OpenID The OpenID is an open, decentralized, free framework for user-centric digital identity. It is a protocol that solves the problem of having an individual login and password for every web site which supports OpenID. There are some terminologies for the process of authentication in OpenID. First, relying party (RP) is a website wanting to verify an OpenID identity URL. Sometimes it called a consumer. If you want people to log into your site using OpenID, then you are the RP. Second, OpenID provider (IdP) is a website which makes assertions as to whether or not the user at the end of the browser owns the URL they say they do. It is named also as IdP (Identity Provider). Last, user is a person who wants to take a service of RP by authenticating with OpenID. This protocol doesn t need previous trust between the service and the identity provider. 2.2 SAML SAML (Security Assertion Markup Language) is a new standard that uses XML to encode authentication and authorization information. Because its based on XML, SAML is platform-independent. SAML is also authentication method-neutral: for example, it could be used to set up federations between PKI- and kerberos-based authentication infrastructures. SAML is a product of the OASIS Security Services Technical Committee and it dates from 2001; the most recent update of SAML is from The SAML specification defines three roles: the principal (typically a user), the identity provider (IdP), and the service provider (SP). This protocol requires the SP to be recognized by the IdP by the means of a previously shared certificate with a XML wrapper.

4 Computer Systems Security - Single Sign-On CAS CAS (Central Authentication system) is an open source protocol whose purpose the usage of same credentials for multiple services using only one centralized identity provider. Every actor in this protocol communicates through XML with CAS namespace. This protocol tickets are issue for every application that the user tries to access. 3 Protocol authentication process 3.1 OpenID authentication process The OpenID is designed for web environment. The SSO of OpenID is a kind of cookie-based system. You can see the figure 1 which describes authentication process. SP 1 1.Access 6.Permission 2.Auth.Req. 5.Response U ser SP 2 3.Login Req. 4.User info. submit IdP Figure 1: Process of authentication in OpenID-based system. A user contacts to SP1 with an URL. SP1 asks the user s information to IdP IdP asks its credential to the user after redirecting the user to the log-in page in IdP. The user types his id and password in the login page.

5 Computer Systems Security - Single Sign-On 4 IdP authenticates the user with user information and sends a certificate to SP1. SP1 verifies the validity of certificate. If the result of verification is success, SP1 responses to the user with authenticated page SP 1 1.Access 4.Permission U ser SP 2 2.Auth.Req. 3.Response IdP Figure 2: Process of SSO in OpenID-based system. The Figure 2 shows the process of SSO with Authentication assertion. A user contacts to SP2 with an URL. SP2 asks the user s information to IdP. After the IdP receives SP2 s request, verifies the certification with session value and recognizes the user who was authenticated in spi before. IdP gives authentication response to SP2. After SP2 verifies the user s valid authentication, SP2 responses to the user with authenticated page.

6 Computer Systems Security - Single Sign-On SAML authentication process The SAML authentication process is designed for web environment. This SSO is based on SAML Assertions, all the communications use SOAP and go as follows in figure 3. User SP Service provider IdP Identity Provider User acesses URL in app A App generates auth request B HTTP POST to IdP w/auth Request Auth request is passed, verified User is sent to login page at IdP C User logs in SAML token is generated Redirect to app w/ SAML token D E User is logged in to service provider Figure 3: Process of authentication in SAML system. A - a user opens their web-browser and goes to mybank.ca which stores information about all his bank accounts, but mybank.ca doesn t handle authentication itself B - to authenticate the user mybank.ca constructs a SAML Authnrequest, signs it, optionally encrypts it, and encodes it. After which, it redirects the user s web browser to the Identity Provider (IdP) in order to authenticate. The IdP receives the request, decodes it, decrypts it if necessary, and verifies the signature. C - With a valid Authnrequest the IdP will present the user with a login form in which they can enter their username and password.

7 Computer Systems Security - Single Sign-On 6 D - Once the user has logged in, the IdP generates a SAML token that includes identity information about the user (such as their username, , etc). The Id takes the SAML token and redirects the user back to the Service Provider (mybank.ca). E - mybank.ca verifies the SAML token, decrypts it if necessary, and extracts out identity information about the user, such as who they are and what their permissions might be. mybank.ca now logs the user into its system, presumably with some kind of cookie and session. At the end of the process the user can interact with mybank.ca as a logged in user. The user s credentials never passed through mybank.ca, only through the Identity Provider. 3.3 CAS authentication process CAS is a SSO centralized authentication system, based on issue tickets. The figure 4 represents a CAS login process. U ser Web Application A G ET CAS Server B 302 C G ET Login URL P rotected Resource C A S C L I E N T E G ET D 302 Logout URL Validation URL H 200 F G ET G 200 Figure 4: Process of authentication in CAS system.

8 Computer Systems Security - Single Sign-On 7 A - a user opens their web-browser and goes to mybank.ca which stores information about all his bank accounts, but mybank.ca doesn t handle authentication itself B - to authenticate the user mybank.ca redirects the user s web browser to the CAS server in order to authenticate. C - The user sends his credentials to the CAS server or Ticket Granting Cookie in the case of an already authenticated user. D - The user s web browser back to the CAS client URL and also sends a cookie with the ST (Service Ticket) which is opaque to every actor except the CAS server. E- The user sends the ST to the CAS client. F - The CAS client sends the ST back to the CAS server. G - The CAS server answers to the request of the CAS, with the validity of the Service Ticket and additional information about the user. H - In case of a valid ST the CAS client sends a OK to the web browser and additional information to maintain the session. 4 Benefits and drawbacks of SSO systems Benefits: Unique accounts but several authentications Each time users access an application Security (password stealing) Protect password transmission Do not transmit passwords to applications Easy to change password to multiple accounts Less passwords and account details to remember. Easy service registration Simplify applications Delegate developments without delegating authentication Abstract authentication LDAP, NIS, database, NT, Active Directory, X509 certificates,... Drawbacks:

9 Computer Systems Security - Single Sign-On 8 If authentication details are lost, access to multiple services can be compromised If authentication details are leaked, access to multiple services can be compromised Privacy can be compromised if identity provider logs your internet activity based on your logins 5 Security caveats of the different protocols In this section we ll describe a few caveats, in form of fictitious examples, from the OpenID and SAML protocols. 5.1 OpenID caveats Alice signed in with the IdP and sets domain mybank.ca, as trusted The IdP won t ask Alice for it s credentials when accessing mybank.ca A cross-site request forgery exploit is possible. Take the following as an example: Alice goes to which has the following code snippet: <iframe id =" login " s r c =" http ://mybank. ca/login? openid_url =bob. dylan. s inger " width ="0" height ="0"></ iframe > <iframe id =" t r a n s f e r " s r c =" http ://mybank. ca/ transfer_ green_ money? amount=10000& t o =notevilcorp " width ="0" height ="0"></ iframe > Since Alice, is already signed in, the trusted domain, mybank.ca, the second snippet will be ran successfully without Alice s interaction (or knowledge). Suppose the SP (Service Provider) does not implement secure communication channel, like https. In this case the user s details are subject to being sniffed when the IdP (Identity Provider) sends the reply back to the user with the return URL and login parameters and information which can lead to replay attacks. This can be solved with a bit of ease. The server must implement a nonce, which specifies that the information will only be valid once. This protection only works if is it Alice (the user accessing the SP) and not Mallory(a user trying to impersonate Alice) to process the message first. In the eventuality of Mallory intercepting the message first and immediately resets the TCP connection, Alice will never get the return URL and Mallory will be impersonating Alice. The risk of phishing can also occur, imagine that Alice goes to weareangels.com and tries to login using is openid identity ( but the relying party redirects Alice to, a carbon copy of the login idp real site

10 Computer Systems Security - Single Sign-On 9 instead of the real one, now Alice gives her credentials to Mallory without even realizing. This problem can easily occur because using OpenID we are trusting on the relying party to redirect the users to the real IdP login page. 5.2 SAML caveats Imagine that Alice tries to login into using the SAML protocol, but her DNS was spoofed. This means that Mallory can possibly impersonate the SAML IdP, by doing so Mallory can easily obtain Alice credentials for later usage. This is one example of a man in the middle attack. In another other occasion, Alice tries to login into again using SAML, but this time everything is fine with the DNS provider. The problem this time is that Mallory rewrite the HTTP response and sends Alice login artifacts to his own site instead of the correct one. Now all, systems used by Alice through SAML can be accessed by Mallory. 6 FEUP s Single Sign-On System 6.1 OpenID URL: Since December 5th is set to be deactivated on 1st January 2014 onwards. This will be a step backwards on the direction openness of FEUP s services. This service can be used to authenticate any person who has credentials to FEUP s information system. The user identity is identified by shown at figure 7. Figure 5: FEUP s OpenID client identifier page. In the url shown in figure 8 a login user can see every authentication made using openid (date/time, url, ip address, result (authorized/not authorized)).

11 Computer Systems Security - Single Sign-On 10 Figure 6: FEUP s OpenID client history page. The biggest advantage of this service is that any person can use this service to create an application which uses the authentication of FEUP (e.g.: U.Porto AAI (shibboleth) URL: This service allows a up.pt wide sign-on. This service uses shibboleth, which is an open source application that implements the SAML protocol. The biggest disadvantage of this service is the mandatory service provider, SAML metadata XML with the identity provider. This will lead to an harder development of new applications by students for example. Figure 7: U.Porto AAI entry point.

12 Computer Systems Security - Single Sign-On 11 Figure 8: U.Porto AAI authentication by password challenge. Figure 9: U.Porto AAI limitations For what we know the only services that use this identity provider are sigarra.up.pt and moodle.up.pt. And we don t know how open are the administrators of this system to allow third party apps to take advantage of this service. For example, in the figure 9 we can see an limitation of this implementation which doesn t not allow users to logout from services without restarting the browser. This can lead to potential security risks if for some reason the user doesn t close the browser completely in a shared computer.

13 Computer Systems Security - Single Sign-On 12 7 Conclusion There are a lot of SSO protocols available, we chose only investigate a few in the time window available. We learned a lot about implementation and working internals of SAML, CAS and especially OpenID. We think that UP s and FEUP s SSO identity providers doesn t give developers and users the best experience. There is much work that can be done in this area. The thing we regret the most is the impossibility, because of the complexity and time availability, of implementing our own SSO identity provider, client and service so we could show a real live demo of a communication protocol between all the participants. References CAS (Central Authentication Service) - Apache Directory Server - Interoperability - Apache Software Foundation. URL https: //cwiki.apache.org/confluence/display/dirxinterop/cas+(central+ Authentication+Service). Open-source Single Sign-On with CAS. URL elibrary/archives/general/esup_fr/e040427m.pdf. Choosing an SSO Strategy: SAML vs OAuth2 Mutually Human. URL choosing-an-sso-strategy-saml-vs-oauth2/. Jan De Clercq. Single sign-on architectures. In Infrastructure Security, pages Springer, Thomas Groß. Security analysis of the saml single sign-on browser/artifact profile. In Computer Security Applications Conference, Proceedings. 19th Annual, pages IEEE, Hyun-Kyung Oh and Seung-Hun Jin. The security limitations of sso in openid. In Advanced Communication Technology, ICACT th International Conference on, volume 3, pages , doi: /ICACT Gunnar Peterson. Dynamic security assertion markup language. IEEE SECU- RITY & PRIVACY, Eugene Tsyrklevich and Vlad Tsyrklevich. Single sign-on for the internet: a security story. BalckHat USA, 2007.