Previously user’s access to cloud applications was very difficult because log on was independent of company systems, this is a real problem when a user leaves the business or changes role. This is compounded further when a user uses more than one Cloud solution. This arrangement is also complicated for users and a potential security risk because the log on external an internal log in arrangements are independent. It is also challenging for the Cloud provider because they are responsible for the user's access security. Modern tools such as Microsoft ADFS provides SAML 2 based centralised control of this process.

Under SAML 2 the user receives a token authorising their access from the identity provider (IDP) before connecting to the cloud resource, this contains user identification but not a password and user attributes. It can contain the group information meaningful to the target application to control access rights for example. It also contains the lifetime which dictates how long the token can be used before refresh is required e.g. 1 hr

If the user obtains the token before connecting to the Cloud Resource this is referred to as IDP initiated access. The user is effectively directly asking he company system to connect out to the Cloud Resource.

However, if the user accesses the cloud resource directly the Cloud Resource service recognises the organisation associated to the request (called realm discovery) and basically redirects the user to their home company IDP to authenticate to sign them in and provides a SAML token. Very often this is defined by the URL e.g. but there are lots of ways of doing this. This type of connection is referred to as Service Provider (SP) initiated.

As mentioned earlier the token has a lifetime which requires the user to be re-verified. This is useful if someone leaves the business or their access rights change. This is pretty much seamless to the users, in a browser they may be a quick flicking of the web browser URL as the application redirects.

Available access methods are dependent on the Service Provider but include:

  • Passive Profiles - the most commonly used profile and is a simple passing of information back and forth between the two systems
  • Active Profiles – particularly pertinent to mobile and the exchange is via an App (rich client) where an explicit call is being made. In this space there are other alternatives including oAuth.

For this to work the service provider must be set up to work with SAML. In addition, the trust relationship needs to be set up first for all for this to work.

Receipt of a token to things need to be confirmed, did the token come from the correct source and was it tampered with. The IDP has an X509 certificate and private key. The certificate is installed on the Service Provider site. This might be a manual install of the cert or via programmatic means. SAML tokens issued by the IDP are signed with the certificate. The receiving site confirms that the certificate is from the issuer and has not been tampered with. This leverages conventional methods of certificate based authentication.