Modern companies and IT organizations have many applications, both internal and customer facing. With these many applications your users are faced with the challenge of not only managing multiple sets of credentials, but are also forced to login to each and every individual application separately. This creates a bad experience for your users.
To improve user experience, IT created a concept called Single Sign On (SSO). The idea was users could sign on once, and the SSO software would automatically authenticate them for all their applications. This not only helped the user experience, but also helped IT by cutting down on the number of ‘forgot password’ tickets opened and when users left the organization, it made de-authenticating them really easy. The idea is great, but in practice it frequently stopped short at authentication.
Even authentication had its limits. Using a unified user repository like Active Directory and LDAP can solve the issue of having a single set of credentials—but only within a single organization, and users still technically had to apply those credentials by logging in to be authorized. Solutions like Kerberos can make logging into applications within your IT transparent, but this is limited to primarily Windows, to a single organization, and doesn’t help us in this ever increasing mobile and cloud world, especially when it comes to hosted applications (SaaS) outside of your datacenter.
This obviously does not fulfill the promise of SSO for users or IT. So how do you build your applications to enable this?
The solution is a combination of Single Sign On and Federation, where the credentials are unified for federation to target apps, authentication happens once and the credentials are sent to the target apps for authorization. This is what the original ‘true’ meaning of SSO is to me, and as I use the term ‘Single Sign On’ throughout the rest of this blog, it is this that I am referring to and not the traditional implementations that have left us lacking.
How It Works: (True) SSO and Federation
SSO not only provides your users with a single set of credentials which they can use across all SSO enabled applications, it also allows them to login just once for the whole set of applications. After they have logged in once they are no longer prompted to login, even if accessing a different application. Since the user is already authenticated by the time they reach your application, all your application has to do is apply its specific authorization rules based on the user’s credentials (e.g., username, groups, roles, etc.) provided as part of the SSO process.
Federation takes SSO to the next level and provides for the ability of users outside of your security domain, whether they are from a trusted partner or authenticated by a trusted 3rd party, to access your applications with their existing security credentials. With this, you are able to federate your SSO solution outside your organization, and allow trusted 3rd parties to login once and use your applications.
Last but not least, the final major benefit of SSO and Federation is provisioning. You no longer have to manually provision new users into your system, even if they are partners from outside the organization. The first time the user tries to access your application you use the data provided as part of the SSO process to automatically perform any required provisioning in your system and perform any necessary authorization, likely based on the users groups or roles.
Single Sign On & Federation Implementation Options
There are a number of SSO options out there including SAML 2.0, OpenID, OAuth, and others. We selected SAML 2.0 in this exercise as it is widely supported by vendors, and is one of the best for Active Directory environments—which is widely implemented in enterprises. So lets dig deeper into SAML 2.0 and how you can enable it in your applications.
SAML 2.0 Overview
SAML, Security Assertion Markup Language is an OASIS standard for exchanging Authentication (AuthN) and Authorization (AuthZ) user data between security domains. The idea being that a user authenticates with their Identity Provider in their domain (e.g., Active Directory) once, and SAML 2 authenticates their credentials across one or more Service Providers (e.g., Applications, Web Sites or Services), without having to login again and again. SAML 2 handles the trust between the Service Providers (SP) and Identity Providers (IdP), using Certificates, and passes information about the users from the Identity Provider to the Service Providers as part of the SSO process.
In addition, SAML 2 can pass detailed information about the users as part of the SSO process, which can enable automatic provisioning of new users in your applications. Basically, if this is the first time a user accesses your application, and they have the proper authorization (e.g., roles) you can automatically provision a new account for them.
The Identity Provider (IdP) – AD FS
There are multiple vendors of IdPs, including Active Directory Federation Services (AD FS) and the Shibboleth IdP. For this exercise, I used AD FS.
AD FS is a component of Active Directory developed by Microsoft that can be used to provide users with Single Sign On access to systems and applications located across organizational and security boundaries. It uses a claims based access control authorization model to maintain application security and implement federated identity. AD FS supports SAML 2.0 Single Sign On and Federation.
The beauty of the identity provider is that you can use whatever authentication mechanisms it supports and you chose. So this could be a forms based authentication, windows credentials, 2-way SSL authentication, etc. Your application doesn’t have to know or care how the authentication is done, and you can provide the ideal authentication mechanism for your users and organization.
The Service Provider (SP)
The service provider(s) are your applications, specifically the component implementing the SAML 2 authentication. SPs could be web sites, SOAP web service, RESTful services, or any HTTP based application.
In this exercise I am using Spring and vFabric to implement the SAML 2 Service Provider. I have explored two options. The first option is implementing a type of ‘perimeter authentication’ at the web server, using SAML 2, in a standard n-tier architecture. The second option is to perform the SAML 2 authentication implementation directly in the (web) application. In either case, the application will still need to perform some level of authorization, but not authentication, since the user has already been authenticated.
The First Implementation Option—Perimeter Authentication
Perimeter Authentication is the process of authenticating a user at the point of contact with the application. The point of contact is usually at the web server, which can be located inside or outside the perimeter of the firewall. This solution focuses on the web tier. In the diagram to the right, we have a pair of vFabric Web Servers (vWS), VMware’s distribution of Apache HTTPD, that serves as the SP and implements the SAML 2 SSO. The vWS servers also terminate the SSL and reverse proxy the HTTP requests (over AJP, HTTP, or HTTPS) to the web/application servers in the service tier.
The web/application servers and the applications therein perform only the needed user authorization based on the information passed from vWS in the headers or, for AJP, in the environment variables.
AD FS is used as the IdP and the AD FS server(s) may be inside or outside the same domain, tier, and or organization as the other components. The vWS SPs have a trust relationship with AD FS established by an offline, out of band, exchange of Meta-Data and Certificates.
In this exercise we used the mod_jk module, and the AJP protocol, inside of vWS as the revers proxy to the web or application server (i.e. tc Server) for load balancing and redundancy. Alternatively mod_proxy or a web/application Server specific reverse proxy, like Web Logic’s mod_wl, could have been used.
Using Shibboleth For SAML 2 Authentication
Shibboleth is an open source project that provides SAML 2 software for multiple aspects of the SAML 2 architecture including the IdP, the SP, the discovery service (not covered here), and low level SAML 2 APIs. Here, we are interested in the Service Provider component that provides a module for Apache HTTPD and therefore vWS.
This solution will work with any standard web or application servers including VMware’s tc Server, Apache Tomcat and JEE servers like Web Logic or Web Sphere. Since the authentication has already been done the application, we are now focused on performing the authorization of the user based on the security information passed in the HTTP headers or environment variables (if using AJP). This authorization implementation details will be specific to the environment and tools you are using but one common approach would be to leverage Spring and Spring security here.
The Second Implementation Option—Spring Security SAML 2 Module
This solution uses Spring, Spring Security and the Spring Security SAML 2 module, right inside your web applications, running in your Web or Application Server, for example vFabric tc Server. In this solution Spring Security as the SP performing the SAML 2 SSO. Your Web/Application Server could still be behind a reverse proxy/HTTP server like vFabric Web Server and/or a hardware load balancer but it is not required.
With this solution is if you are already are using Spring Security, or don’t have/need the separate web tier, all you have to do is include the Spring Security SAML 2 module in your project and implement the necessary configuration to link it up to your IdP, e.g. AD FS. All of the configuration performed will be standard Spring and Spring security configuration. The Spring Security SPs have a trust relationship with AD FS established by an offline, out of band, exchange of Meta-Data and Certificates.
This post has shown two different ways of using SAML 2 to enable true Single Sign On and Federation in your applications. If you’re already leveraging a distinct web tier with Apache HTTPD or vFabric Web Server you can perform the SAML 2 SSO authentication at that level using the Shibboleth module. If you don’t have or need the separate web tier, or are already using Spring Security in your application, you can easily enable SAML 2 SSO using the Spring Security SAML 2 module.
Either way you will enable your applications to take advantage of true Single Sign On and Federation and free your end users from having to manage separate credentials and log into each and every application separately. If you are starting to provide your applications as a service (SaaS) this can further benefit your users by allowing the to login to your application using their existing credentials and information.
Active Directory Federation Services:
- ADFS (Server 2012): http://technet.microsoft.com/library/hh831502
- ADFS integration with Shibboleth: http://technet.microsoft.com/en-us/library/gg317734(v=ws.10).aspx
- Service Provider: http://shibboleth.net/products/service-provider.html
- Documentation: https://wiki.shibboleth.net/confluence/display/SHIB2/Installation
vFabric Web Server:
- Product Page: http://www.vmware.com/products/application-platform/vfabric-web-server
- Documentation: http://pubs.vmware.com/vfabric52/index.jsp?topic=/com.vmware.vfabric.web-server.5.2/index.html
- Download: https://my.vmware.com/web/vmware/details?downloadGroup=VFWSVR_520&productId=272&rPId=3069
vFabric tc Server:
- Product Page: http://www.vmware.com/products/application-platform/vfabric-tcserver/overview.html
- Documentation: http://pubs.vmware.com/vfabric52/topic/com.vmware.vfabric.tc-server.2.8/index.html
- Download: https://my.vmware.com/web/vmware/info/slug/application_platform/vmware_vfabric_tc_server/2_8
- Spring Security: http://static.springsource.org/spring-security/site/
- SAML 2.0 Module: http://static.springsource.org/spring-security/site/extensions/saml/index.html
|About the Author: Derek Beauregard is a technologist at heart with over 10 years experience in the industry. He is currently working as a Sales Engineer in the vFabric division of VMware. Prior to this role he was a consultant in the vFabric PSO organization designing and implementing vFabric based solutions for VMware’s customers across multiple verticals. His work has concentrated lately on Application Modernization, Platform as a Service (PaaS), and Big/Fast/Flexible data. Derek is based out of Denver, CO.|