From Znode Knowledge Base
Jump to: navigation, search


Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities: a Service Provider and an Identity Provider. The Service Provider agrees to trust the Identity Provider to authenticate users. In return, the Identity provider generates an authentication assertion, which indicates that a user has been authenticated.


Without much ado, the benefits of SAML authentication include:

  • Standardization: SAML is a standard format that allows seamless interoperability between systems, independent of implementation. It takes away the common problems associated with the vendor and platform-specific architecture and implementation.
  • Improved User Experience: Users can access multiple service providers by signing in just once without additional authentication; this allows for a faster and better experience at each service provider. This eliminates password issues such as reset and recovery.
  • Increased Security: Security is a key aspect of software development and when it comes to enterprise applications it is extremely important. SAML provides a single point of authentication which happens at a secure identity provider. Then, SAML transfers the identity to service providers. This form of authentication ensures that credentials don't leave the firewall boundary.
  • Loose Coupling of Directories: SAML doesn't require user information to be maintained and synchronized between directories.
  • Reduced Costs for Service Providers: With SAML, you don't have to maintain account information across multiple services. The identity provider bears this burden.

How To Work With SAML

SAML is a separate application and for a client application to communicate with former we need to add a reference to Znode.Webstore.Custom in the latter. In addition, we need to add the following settings in the Web.config file of client application: SAML setting section : Put this line in ConfigSection of Web.Config file

solid black circle

Code to add in Web.Config file:

<section name="SAMLSettingSection" type="Znode.Libraries.SAML.SAMLSettingSection" allowDefinition="Everywhere"/>

Put this code in Web.Config file

solid black circle

Code to add in Web.Config file:

solid black circle

Above code will help client application to communicate with SAML application.
Client and SAML application to be started simultaneously. Ensure to keep the SAML application running so that client application can communicate with it.

When user clicks login button on client application, it will move to SAML provider to check the user is authorised or not. If user is not valid then it will create SAML request, serialize the request, redirect to SAML to authenticate the request, check request is valid or not and shows the login form for SAML Identity Provider.

After putting valid username and password to the login form it will move to SAML for response. It will check the username and password, the signing certificate and the signing response. To check the signing response, it will move to SAML assertion where it will create assertion request and assertion condition, add another authenticated statement and attribute as item and put this assertion in response and serialize it to XML and sign using the supplied certificate. Use this certificate to append computed signature to an XML serialized response, with this response it will passes the response of SAML server to the OAuth server and store the user state and redirect to the client application


While implementing SAML concept generally we separate each server following separation clear out the concepts

  • Resource Server: The resources reside here that the client wishes to access.
  • Client: How the user is interacting with the resource server. E.g. web app through the browser.
  • Authorization Server: The server that owns user identities and credentials.
  • SAML Identity provider: Communicate with Client and resource server (Read user credential and send to the Authorization server to verify)


solid black circle

The Client gets an SAML bearer assertion from the SAML Identity Provider; it requests an access token from the Authorization Server using the SAML bearer assertion as proof of identity. The Authorization Server verifies this and passes back an OAuth token which is used by the client to access the Resource Server The solution consists of the following projects:

  • Znode.Engine.WebStore – the application used by the resource owner to access his resources.
  • Resource server – the server holding the resources.
  • SAMLIdentityProvider – implementation of a SAML server; authenticates the user and issues a SAML token containing assertions about the user.
  • SAMLLibrary – classes and utilities for SAML.
  • AuthorisationServer – implementation of an OAuth server; authorises the client app to access the resources.
  • You need to build the entire solution in order to run the demo.


To access his resource the user goes through 6 screens. First the main Webstore (Client app) login page provides the interface for accessing the resource.

Home Page

solid black circle

Login Page

solid black circle

The user clicks ‘Login’, but since he has not been authenticated yet he is redirected to the SAML server to provide credentials. For this project we have hardcoded “” and “admin12345” as login details.

solid black circle

The credentials are validated, the user is authenticated using the federated identity (agreed between the SAML server and OAuth server) and is redirected back to the Webstore Home page.

solid black circle

The Webstore (Client app) in turn redirects to the OAuth Authorization server in order for the user to grant permissions to the Webstore (Client app) to access resources on his behalf.

solid black circle

Note: In addition, we can add grant permission process as per requirement. After the user grants permission he is redirected back to the Webstore (Client app) Home page where he can now access the resource. Webstore/ Client with Login User

solid black circle


The sequence of interactions between the different components is shown in the following diagram

solid black circle

The alternating colors indicate the set of actions that occur between the different screens the user (resource owner) sees as described in User Interactions section above.

Please refer Code for actual logic implementation and separation of each server layer.