[Article] Authentication Protocols Comparison and Analysis

Table of contents

1. Introduction
2. About protocols
3. SSO process initiation mechanism
4. Identity providers
5. Security token types
6. Single sign-out
7. Security issues
8. Conclusion
9. References

Introduction

Currently, it is very common to see a lot of web applications and systems requiring users to register to the application or the system by creating a new account. However, from the user’s perspective, it is impractical to remember all usernames and passwords for each application. As a solution, users tend to reuse the same passwords, use weak passwords, or maintain a list of all usernames and passwords. All of these pose security threats. Single Sign-On (SSO) is a well-known solution that enables users to keep the same username and password for multiple web applications. SSO benefits can be summarized as follows:

• SSO provides the ability to maintain the same authentication and/or authorization attributes for multiple web applications or systems
• From the application developer’s perspective, SSO will reduce the complexity of having to understand and implement identity security in their applications
• This will be beneficial for the application maintainers as well. They will be able to reduce their user management cost, as a result

In this article, the following authentication protocols will be compared and contrasted.

• SAML 2.0
• WS-Federation Passive profile (Passive STS)
• OpenId
• CAS (Central Authentication Service)

About protocols

SAML 2.0

This is an XML-based protocol developed by the Security Services Technical Committee of OASIS. SAML uses a security token to pass information of the principal (which is typically the user) between the Identity Provider and the service provider (the application). SAML2 has a modular architecture, which consists of three major components: core, bindings, and profiles. SAML2 is a flexible and extensible protocol that can be customized according to the needs to be used with other standards.

OpenID

OpenID is a lightweight protocol. It has a decentralized, user-centric architecture. Original OpenID authentication protocol was developed by Brad Fitzpatrickis and is now managed by the OpenID Foundation. Users are able to create accounts at their preferred OpenID providers, and then use those accounts to login to other web applications that accept OpenID authentication.

WS-Federation Passive Requestor Profile

Similar to SAML 2, WS-Federation protocol also has a modular architecture. As a result, this is flexible and extensible and is able to solve general web security problems. This protocol has been developed by IBM and Microsoft. WS-Federation depends on different subcomponents, such as the WS-Security framework, WS-Trust, WS-SecurityPolicy and WS-Security, which are used for different perspectives in the SSO process.

Central Authentication Service (CAS)

CAS is also an authentication system that provides enterprise SSO service. This protocol is invented by Yale University to provide a trusted way for an application to authenticate a user. CAS allows multi-tier authentication via a proxy address and has a centralized architecture. CAS is an open and well-documented protocol that hasan open-source Java server component, a library of clients for Java, .Net, PHP, Perl, Apache, uPortal, and others.

SSO process initiation mechanism

The SSO process can be initiated using either of the following methods:

• Service provider initiated – the application initiates the SSO process when the user tries to log in
• Identity provider initiated – the user visits the identity provider first using the browser, and will then visit the web application

This mechanism has got its names because the entire process started at the identity provider.

OpenID supports only service provider initiated SSO and the end-user is required to enter the OpenID manually to the relying party (the web application). SAML supports both forms, which means that it is possible to offer portals for users;using the IDP initiated flow, the user can be first authenticated to the IDP, then the user will be able to launch the application. Both CAS and WS-Federation Passive profiles support the service provider initiated.

Identity providers

OpenID has the ability to auto-discover its identity provider. It is also a key advantage of the OpenID protocol, e.g. the OpenID

https://myidentityprovider.com/bob/ indicates explicitly that Bob’s identity provider can be found at

https://myidentityprovider.com. This provides simplicity to the application providers when it comes to configuring an application for SSO. However, for the enterprise, this may lead to drawbacks. Application or service providers do not trust all OpenID providers and this a major issue. As a solution, this should be limited only to a set of trusted identity providers. In OpenID, this can be achieved by the Directed Identity mechanism.

SAML2 service providers are coupled with its Identity Providers. SAML2 has a discovery protocol based on Identity Provider Discovery Service Protocol. The Home Realm Discovery mechanism is used in WS-Federation for this purpose. There is no specific method that’s used to identify the home realm of the request. Some common methods are fixed-based (home realm is fixed or known), requestor IPbased (home realm is determined using the requestor’s IP address), prompted (user is prompted), or uses a discovery service (a specific service is used to) and a shared cookie (a shared cookie from a shared domain is used). As described above, CAS is also a centralized protocol. Therefore, it uses a single server for identity management.

Security token types

Security tokens are used to prove the user’s identity in the SSO process. It contains user identity claims and also information on authentication events. Each protocol has defined its own type for the security token in their specification. OpenID protocols use plain text for request and response messages in a set of request parameters defined in the specification. SAML assertions contain security information in SAML2. The service provider requests and obtains an identity assertion from the identity provider and the authentication and authorization will be handled based on that assertion token. Apart from that, SAML works with any other token types that are embedded in a SAML assertion. In the WS-Federation, WS-Trust is responsible for enabling applications to construct trusted message exchanges and security tokens brokerings. Therefore, security tokens used in WS-Federations should be WS-Trust supported. A few examples are SAML assertions, X509 certificates, and Kerberos. CAS uses a secure cookie containing a string identifying a ticket-granting ticket as the mechanism for exchanging secure messages. This cookie is called the ticket-granting cookie.

Single sign-out

While SSO means logging in to multiple applications using the same username and password, single logout is a way to remove all sessions (both at the IdP and all of the SPs) at once when the user logs out from one application. SAML 2 supports single sign out, but OpenId does not. CAS also supports this feature. Whenever a ticket-ranting ticket has explicitly expired, the logout protocol will be initiated in CAS. SSO to the various web applications is maintained via session cookies in the browser, and the WS-Federation sign-out process will destroy these cookies so that the user will need to provide credentials again in order to access to those applications. Single sign-out can be initiated by either an SP or the (primary) STS, which will send sign-out messages to all relying parties.

Security issues

Eventhough SSO makes our lives easier, these protocols may lead to some security issues. Phishing attacks are one of the major security concerns in OpenID protocol. In OpenID, the relying party controls authentication to the IDP; the RP can redirects the user’s credential to a fake identity provider to steal sensitive data. This can be mitigated in the application level by properly checking the validity of the IDP’s response message signature and the domain name of the IDP. Man-in-middle and replay attacks are also possible in OpenID. SAML2 is vulnerable to XML Signature Wrapping attacks as that is an XML-based protocol. The adversary can modify the message structure by injecting malicious elements without invalidating the XML Signature.

Phishing attacks are possible with CAS. This can happen to users who are logged in with the already set Ticket Granting Cookie (TGC). If the user clicks on a malicious link, the service ticket (ST) will be appended to that link URL as a query string. The CAS server will redirect the URL to a phishing or malicious site. Since the URL to the application contains ST, it can be stolen by a fake application. This is also a common security attack in CAS.

The following table provides a summarized comparison of the selected SSO protocols

Conclusion

OpenID is an easy-to-implement, light-weight protocol compared to others. However, SAML2 and WS-Federation Passive Profile have some clear advantages over OpenID when it comes to enterprising SSO. As a result, most Software-as-a-Service (SaaS) vendors are widely integrating previously stated protocols into their applications. CAS is an older protocol that has a centralized architecture unlike OpenID. As a result, it will be easy for the user management. On the other hand, if the system operates mostly in the Microsoft world, WS-Federation is more suitable.

In conclusion, anyone can comfortably pick any of the standards by considering factors such as partners, vendors, customers, and systems when implementing SSO to their system.

References

https://www.cs.wustl.edu/~jain/cse571-07/ftp/websso/

https://www.unicon.net/opensource/cas

https://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf