Identity Federation 101

Have you ever wondered how an application or device knows who you are and how things like Single Sign-On (SSO) work?  Today’s IT landscape involves business applications hosted on remote servers and accessed from devices ranging from desktop workstations to portable devices to smart phones, all interconnected though web-based communications protocols.  This reality presents significant cyber security challenges, one of which is reliably identifying the users who are attempting to access protected resources, and one solution to this particular challenge is identity federation.

In this blog, I describe how identity federation operates in a typical enterprise, which addresses the user identification (or authentication) challenge. This is not to be confused with authorization, which I will explore in another blog post later this summer.

When a person begins using a device that allows access to protected resources, that person must reliably identify himself or herself to the device and to the network domain in which the protected resources operate.  Different devices use different user authentication methods.  For example, a workstation is typically attached directly to a network domain, and users “log in” with an id/password or preferably a smart card.  Portable devices, like your smart phone, often use a PIN or a fingerprint scan to determine who you are.  Authenticating to a network domain may require additional user steps because the network domain is a virtual doorway to a large number of resources so, ultimately, it must be satisfied that the user’s identity is clearly established.  Your enterprise will decide what methods establish acceptable identification of its users within its domains. (That’s more of a policy problem, and I’d like to use this blog to focus on the technical side.)

The user then initiates a browser session or other form of web client running on the device to access the enterprise’s applications.  In the past, applications often maintained user ID and password lists, and the user had to enter proper values to identify themselves.  More recently, the application attempts to interact with the user’s browser to read a smart card inserted into the access device (i.e. your workstation). These approaches can be cumbersome, and using them was difficult or impractical, particularly on portable access devices, because the necessary hardware – the card reader – is often not built into the device.

Identity federation is an alternative method for user identification.  The accessing device and the application exchange a digital security token[1].  The security token server, or STS, creates the security token based on the user’s attachment to the network domain.  The business application trusts security tokens produced by a specific STS.

Here is how identity federation works:

  1. The user initiates access to a web-based application using a browser[2] running on the user’s access device by sending a request to the web server hosting the application.
  2. The hosting web server responds to the request by returning a request of its own. It requests a security token identifying the user that issued by an STS that the application trusts. This response redirects the user’s browser to that STS.
  3. If the STS trusted by the application cannot directly affirm the identity of the user because the application operates in a different domain space, or realm, than the user, the STS redirects the user’s browser to another STS that operates in the user’s domain. This requires a home realm discovery (HRD) process to identify the STS operating in the user’s domain.  Usually HRD involves another interaction with the user’s browser to have the user specify his/her home domain.  User input can be avoided if the user has retained a temporary cookie on their access device that provides this information.
  4. The STS operating in the user’s domain then affirms (or denies) the identity of the user based on the identity that the user established when he/she initially logged into the accessing device (i.e., the workstation, smart phone, portable device). This is typically a network login to an Active Directory (AD) domain controller.  Using information from the user’s AD account, the STS produces a security token representing the user and returns it to the user’s browser.
  5. The user’s browser may not be able to submit this first security token to the web server that hosts the application being accessed because this token was issued by an STS that is not trusted by the application. In this case, the browser sends the security token to the STS that the application trusts.  That STS translates the token into one that the application will trust, and it returns the translated token to the user’s browser.
  6. Finally, the browser sends the trusted security token to the web server that hosts the application the user is attempting to access. The application’s web server validates the security token, checking digital certificates and timestamps to verify its origin and integrity and to prevent “man-in–the-middle” attacks.  If the token is valid, the identity information is passed to the application.  The application then uses the identity information for its internal authorization process.

Federated STSs operate in a network of trust.  Each STS is configured to recognize and transform tokens produced by other servers in the network and to redirect the accessing browser to the next appropriate server if it cannot authenticate the user’s identity.  Fortunately, standards for security tokens have been well established[3], allowing federated networks to be deployed using STS software from different vendors.  This allows the network of trust to be extended across network domain boundaries and to accommodate access to external applications.  It is important to keep in mind, however, that while mixed STS networks will satisfy the basic definition of a security token, one vendor’s STS product may not support features of another vendor’s STS product that extend beyond the basic definition of a token.

That is identity federation in a nutshell, but I’d love to hear your thoughts.  Did you find this overview to be valuable?  Was there a key aspect of my explanation that you want to discuss more?

Thanks for reading!

Do Good. Have Fun.  Add Value.

 

[1] A security token is simply a string of bits that can be attached to a web request.  The token contains an attribute that uniquely identifies the user, but may also contain other user-related attributes, such as a code that indicates how the user originally authenticated to the access device they are using.  The string is digitally encrypted, digitally signed, and timestamped to frustrate attempts to copy and re-use it.

[2] A browser can also be a web client or web application for the purposes of this description.

[3] These standards are defined by ISO – Industry Standards Organization.  See http://www.smartcardalliance.org/smart-cards-intro-standards/

Leave a Reply

Your email address will not be published. Required fields are marked *