Identity Federation

Identity federation is the concept of linking a user’s identity across multiple systems or servers.When two servers are federated, the authentication against one can be leveraged to prove the user’s identity to the other.Some application servers in the secondary role can allow this without requiring the user to register an account.

Identity federation typically entails some level of Single Sign-On (SSO).Once authentication has been performed against a primary server, the user’s session with that server can then be used as a launch point for SSO-based access to other federated services.This can be used to realize the common business requirement of reducing access barriers without compromising the security of the systems involved.

There are multiple protocols that can be used to apply the successful authentication against one system to another, but Security Assertion Markup Language (SAML) has emerged as a clear front-runner (CAS, WS-Federation and OAuth can also be used).SAML is an XML-based language that is used to convey identity information.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 ensures it can be used by any client device regardless of operating system (e.g. Windows, Mac, Linux) or architecture (PC, iPad, smart phones).
  • 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.

Usage Scenarios

Consistent authentication interface

When the user is always forced to login to your federation-capable applications using PortalGuard, a consistent authentication interface and process can be enforced.This reduces end user training and frustration associated with managing multiple accounts through multiple websites.


Enforcing self-service enrollment

Using identity federation offers a seamless way to provide users the ability to unlock their account, enroll answers to challenge questions, reset or recover their forgotten passwords and enroll their mobile device for use in multi-factor authentication.

Multi-factor authentication

Because the end user communicates directly with the PortalGuard server, authentication decisions made by PortalGuard are strictly enforced.This ensures a high level of security and consistency.

How It Works

Identity Federation Via SAML SP-Init POST Binding

  1. The user opens their browser and accesses the target server, e.g.
  2. The target server sees the user has not yet authenticated so it generates a SAML request and returns it and the originally requested URL (the “RelayState”) as hidden input fields in a HTML form response.
  3. JavaScript in the response automatically submits the form to the PortalGuard Identity Provider (IdP).
  4. PortalGuard sees the user has not yet authenticated to it so it responds with a prompt for the user’s credentials.
  5. The user enters their username and password and submits them to PortalGuard.
  6. The PortalGuard server validates the user’s credentials against its configured user repository (e.g. Active Directory).
  7. The user repository returns a success or failure code indicating the fidelity of the credentials.
  8. PortalGuard queries its security policies and user profile store to determine what features are in effect for the user and what requirements have yet to be satisfied.
  9. PortalGuard parses the data from the PortalGuard security policy and user profile to see if any further credentials are required from the user (e.g. for KBA or 2FA).If so, additional round-trips between the user and PortalGuard occur to receive and validate this information.
  10. Once the user has fully authenticated to PortalGuard, it queries the configured identity claims store (e.g. Active Directory) for requested claim information such as username or email address.It adds these claim values to a SAML response and digitally signs the response XML to prevent tampering.The signed SAML response and original RelayState are added as hidden input fields in a HTML form response which is sent back to the user’s browser.
  11. JavaScript in the response automatically submits the form to the target server’s Assertion Consumer Service (ACS).
  12. The target server validates the SAML response and maps its identity claim(s) to the appropriate user account for its purposes.The server then generates and returns a session cookie that ties the user’s browser session to the authentication that just took place.

No passwords are included in the SAML response so the target server does not need to contact its own user repository for authentication purposes.The digitally signed SAML response from a trusted IdP sufficiently ensures the target server that the user is authentic.


The Identity Federation option has the following requirements:

  • The target server must support SP-initiated SAML SSO using the POST binding
  • The target server must be configured to not allow manual authentication.Otherwise, users could use that method and bypass the interactions with PortalGuard.
  • A trust must be configured between the PortalGuard Identity Provider and the target server/service provider.
  • The end user must have network connectivity (HTTPS) to both the PortalGuard server and the target server.
  • The PortalGuard server does not need network connectivity to the target server since the user’s browser delivers all SAML messages.