How Does SSO work with SAML

Most organizations are looking to put an end to user complaints about having to remember multiple passwords and avoid the challenges the IT team faces when trying to manage multiple user repositories. That explains their need and reasons for employing a strong SSO solution.

Security Assertion Markup Language (SAML) has been fulfilling this requirement quite effectively and securely for many years now. Every major service provider such as SharePoint, Google Apps, and Blackboard are equipping authentication alternatives with a SAML implementation. The biggest benefit to using SAML is the widely adopted usage scenarios but one of the most effective mechanisms of SAML is how each individual configuration can specify a different set of user attributes.

For a more detailed overview, check out our SAML for SSO ebook.

What is SAML?

Originally developed by the OASIS Security Services Technical Committee, Security Assertion Markup Language (SAML) is leading the way in providing seamless, web browser SSO as an open, widely implemented, industry-standard protocol. SAML is an XML-based authentication protocol that passes assertions between SAML-enabled applications.

Once the end-user requests access to a resource, an online identity provider creates a SAML token containing the end user’s identity assertions. Once the resource server validates the SAML request, the end-user is granted access without any further password prompts.

Why use SAML for SSO?

SAML is heavily leveraged today for numerous reasons:

• It works for cloud-based services that are typically hosted offsite as well as “on-premise” services.  
• It is typically wrapped in the HTTP/HTTPS protocols which ensure it can be used by any client device regardless of operating system (e.g. Windows, Mac, and Linux) or architecture (PC, iPad, smartphones).
• The use of HTTP/HTTPS also allows for easier network administration since these ports are more frequently open in server or client firewalls.  
• Manual user authentication for multiple services can be redirected and always be performed against a single Identity Provider (IdP). This “choke point” allows for network and access policies to be controlled at a single point, making them much easier to implement and enforce.
• Users can be authenticated against virtually any user repository using any required method(s) without impacting the downstream servers, which always receive a SAML assertion.

What are the benefits of SAML?

Beyond being one of the most widely used types of SSO protocols, making it easy to integrate all applications that support it, SAML offers the following benefits:

• Eliminate the need to develop and maintain your own portal   
• Reduce the number of passwords users are required to remember and manage   
• Implement and enforce configurable password policies   
• Remove the need to manage external user credentials   
• Optionally increase security using any combination of transparent barriers   
• Add stronger authentication using Multi-factor Authentication or Adaptive Authentication for select users or groups of users (e.g. Administrators)
• Reduce password-related IT support calls related to password and access issues

There are plenty of misconceptions regarding SAML based SSO. Many may argue that implementing SAML SSO takes too long or that SAML SSO is too expensive. However, while enabling SAML SSO is definitely an investment, organizations can reduce costs and optimize time. Forrester Research estimates that the average cost of a single password reset through the help desk costs an organization around $70, and Gartner estimates that 20% to 50% of all helpdesk calls are for password resets. With this in mind, implementing SAML Single Sign-On speaks for itself.

Controlling System and Network Segment Access

Within the various features provided by an SSO IdP is Access Control. Typically handled by integrating with the directory of your choice, an IdP can use Access Control Lists and other defining characteristics in order to limit access to resources down to the individual Organizational Unit. The best of these IdP’s will have a full range of customization to make this even more detailed!

Enforcing Least Privilege

The Principle of Least Privilege (POLP) is almost self-explanatory. The POLP necessitates that users, processes and even programs are only granted the most minimal access rights needed for proper functionality. For users, this is an extension of access control, and works toward further improving system stability and security.

Minimizing Exposed System Targets

This is the big benefit to Single Sign-On: aggregating individual login points to a single, secure point of access. This area is where most users are given pause. Consequently, users fear that minimizing login routes will actually weaken the security of their environment. Yet, a properly configured SSO solution actually makes it easier and more acceptable (for end-users) to max out the security of the login without sacrificing usability. Implementing SSO via a dedicated IdP closes all access points except for one – significantly reducing the attack surface.

How does SAML SSO work?

The following steps show how a SAML IdP, such as PortalGuard works, using two different SSO methods: SP-Initiated (Service Provider) and IdP-initiated (Identity Provider).

SP-Initiated SSO

SP-Initiated SSO occurs when a user attempts to login directly to the desired service, without first authenticating to the local Identity Provider. If the user has not yet authenticated, they are required to login using local credentials, which suffice to grant access to the requested service. The steps for achieving this are outlined below.

IdP-Initiated SSO  

IdP Initiated SSO typically occurs when a user accesses a locally managed jump page. By authenticating directly to the IdP first, the user can choose from a host of services to access without the need to input any additional credentials. The technical process for achieving IdP-initiated SSO is outlined in the steps below.  

STEP 6: The user clicks a displayed application. Note: the applications available to the user are configurable by the administrator.  

STEP 7: The click is serviced by the PortalGuard IdP, which generates a SAML response and sends it back to the end-user wrapped in an HTML form.  

STEP 8: JavaScript in the response automatically submits the form to the target server’s Assertion Consumer Service (ACS).  

STEP 9: The target server parses and validates the SAML response. It uses the embedded identity claims to determine the user’s identity and grant the user access to the application. 

SAML Single Logout

For more information on how SAML Single logout works read our blog SAML Single Logout – What You Need to Know.

When do you need SAML SSO?

Many factors will come into play when analyzing what really determines the need for any single sign-on solution, including SAML. Part of understanding what is driving that need is coming to terms with what a single sign-on solution can provide for your particular environment. To understand when you need SAML SSO, you must look for the problem areas inherent in your environment. Some of these problems may include: 

• Multiple password prompts are impeding access. 
  • Loss in productivity for the end-user as time is wasted on logging in and/or re-logging in due to sessions timing out.
  • Applications used infrequently – such as open enrollment apps – are highly prone to forgotten passwords. 
• End-user password fatigue – most individuals average upwards of 100 passwords that need to be managed. 
  • End-user convenience – juggling multiple passwords can be extremely frustrating. 
  • Reduces password security – the same passwords are used for multiple applications
• IT Support or the Help Desk handles forgotten password calls for multiple applications. 
  • Loss in productivity for the IT support employees 
  • Expensive – password-related calls cost the enterprise an average of $70.00 per call.
  • IT support hours and staffing issues, especially for global companies. 

SAML SSO Alternatives

Although many web-based applications are already SAML-ready, there are a few number that cannot support it. In this case, alternatives such as form-based single sign-on can achieve seamless integration across your organization. Additionally, mechanisms such as Kerberos can be used to enable SSO for non-SAML applications.

See PortalGuard’s Single Sign-On in Action

Enjoy this brief demo of PortalGuard’s Single Sign-On capabilities then sign up for our free trial to try it out for yourself.