Single Sign-On (SSO)

Single-Sign-On

Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content.

In InApp, we had developed SAML-based Single Sign-On (SSO) service in a different project that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications that we had developed. Using the SAML model, our implemented project acts as the service provider and provides services.

SSO

InApp project team implemented SSO login for their MyApp Web & Mobile application project. Here SSO work flow describes based on the MyApp web application & Mobile project.

Understanding SAML-based SSO

The following process explains how a user logs into a hosted web application through a partner operated, SAML-based SSO service.

SAML transaction work flow

Here is the detailed step which is mentioned in the image.

The user attempts to reach a hosted application, for example, MyApp.

MyApp generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner’s SSO service. The RelayState parameter containing the encoded URL of the MyApp application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection.

MyApp sends a redirect to the user’s browser. The redirect URL includes the encoded SAML authentication request that should be submitted to the partner’s SSO service.

The partner decodes the SAML request and extracts the URL for both MyApp’s ACS (Assertion Consumer Service) and the user’s destination URL (RelayState parameter). The partner then authenticates the user. Partners could authenticate users by either asking for valid login credentials or by checking for valid session cookies.

The partner generates a SAML response that contains the authenticated user’s username. In accordance with the SAML 2.0 specification, this response is digitally signed with the partner’s public and private DSA/RSA keys. For this implementation developer should integrate the SSO Certificate (.crt) validation while developing. The expiry period of the certificate will be different for each provider.

The partner encodes the SAML response and the RelayState parameter and returns that information to the user’s browser. The partner provides a mechanism so that the browser can forward that information to MyApp’s ACS. For example, the partner could embed the SAML response and destination URL in a form and provide a button that the user can click to submit the form to MyApp. MyApp’s ACS verifies the SAML response using the partner’s public key. If the response is successfully verified, ACS redirects the user to the destination URL. The user has been redirected to the destination URL and is logged in to MyApp.



4 Comments

Leave a Reply

8 + four =