Single Sign On Using SAML

Overview

Security Assertion Markup Language, or SAML, is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. This is the standard that is used by BillingPlatform to provide Single Sign-On (SSO) services to its customers.

Terminologies

  1. Binding - Transport protocol or method that is used to to transfer messages between parties/systems. Examples are SOAP Binding, PAOS Binding, HTTP POST Binding and HTTP Redirect Binding.
  2. Profile - Sequence of messages that are exchanged to perform logical actions. Profile defines not only the types of message being exchanged, but it also provides the list of possible bindings in each exchange.

For example: Web Browser Single Sign On Profile

  • Logical operation: sign on,
  • Defines messages: AuthnRequest, Response
  • Defines transport and agent: HTTP with browser agent
  • Defines bindings: AuthnRequest may be passed with HTTP Redirect or HTTP POST. Response must be passed with HTTP POST, etc.
  1. Service Provider - Web application that does not perform authentication by itself. Instead, it delegates authentication to another web application and just receives the status along with the user identifier.
  2. Identity Provider - Web application that is trusted by other applications and responds to authentication requests from other applications.

High-level Process Flow

This represents the high-level flow for SAML in a web browser profile. These SAML messages are transferred as HTTP parameters SAMLRequest and then SAMLResponse. These are encoded using base64.

  1. User opens a secured page such as admin.jsp in the Service Provider application.
  2. Service Provider accepts the request and determine that Single Sign On is enabled and configured.
  3. Service Provider sends redirect to the configured Identity Provider endpoint and provides SAML message in the form of SAMLRequest parameter.
  4. Identity Provider receives SAML message and checks if the Service Provider exists and is configured as trusted.
  5. If message validity cannot be determined or any other error is encountered, Identity Provider shows error page and breaks message exchange.
  6. If the message from the Service Provider passes all checks, the login procedure is started.
  7. If User is already logged onto the Identity Provider, the latter sends the SAMLResponse just the same.
  8. If User does not have an active/established session, Identity Provider shows login page to authenticate User.
  9. Regardless if User authentication is successful or fails with the Identity Provider, the latter sends SAMLResponse with the status.
  10. Service Provider receives SAML message and performs validity checks and if everything is good, User is allowed to use the system's services.

 In order for the feature to work, configuration must be done on both the Service Provider and Identity Provider systems. For more information on the configuration, refer to How to configure SSO using SAML.

Related Topics

Have more questions? Submit a request

Comments

Powered by Zendesk