This is part four of a blog series on NIST 800-63c guidelines on Digital Identity. This blog focuses on part “c” of the standard – NIST 800-63c – and focuses on Federations and Assertions.
It’s taken longer than I would’ve liked, but I finally completed part four of my series on NIST-800-63-3 guidelines on Digital Identity. Part one provides an introduction and overview of the overall guidelines, part two goes in-depth into the Enrollment and Identity Proofing, while part three talks about Authentication and Lifecycle Management guidelines.
This blog focuses on part “c” of the standard – NIST 800-63c – and focuses on Federations and Assertions. As a leader in the Identity as a Service (IDaaS) market, supporting this standard effectively happens to be one of Idaptive’s strengths. This standard, and the document detailing it (like the other documents), is incredibly comprehensive and complete in its coverage of federation standards. While this blog isn’t a summary of the entire document, it focuses on a few parts of it that may be relevant to an interested newbie.
So, what really is “Federation”?
The NIST document defines federation as “a process that allows for the conveyance of authentication and subscriber attribute information across networked systems.” In simple terms, federation means the process of sending information from one system to another system (the second system trusting the first system) that “confirms” a user has been authenticated, along with other information (attributes) related to the authenticated user. The system that authenticates the user is called the Identity Provider, or IdP, and the system that trusts the IdP is called the Relying Party, or RP. The information conveyed from the IdP to the RP is often in the form of a concept called “assertion”. Information contained in the assertion is then used by the RP to determine and enforce access privileges. The authentication that happens between the user and the IdP relies on the 800-63b standard.
In a federation scenario, the IdP and the RPs that consume the IdP services are referred to as members of a federation.
Assertions? ELI5 what that means…
Think of an assertion as a ‘FedEx package’ sent from the IdP to the RP (electronically, of course) that contains a variety of information about the authenticated user, along with other information that the RP can use. The primary purpose of an assertion is to authenticate the user to the RP, but the information in the assertion can be used by the RP for a variety of uses such as allowing the user to see the admin pages of the website, or personalization of the website for the user.
Federated Assurance Levels or FALs
As with the other guidelines, this document too does a great job of explaining the three levels of assurance related to Federation. Below is a table summarizing the three levels:
Level 1 simply maps to the OpenID Connect Basic Client Profile or the Security Assertion Markup Language (SAML) Web SSO Artifact Binding profile. FAL 2 requires that the assertion (OIDC token or SAML assertion) is encrypted by a public key representing the RP. And level 3 requires that the user authenticating against the IdP does so with a cryptographic authenticator. Idaptive supports all three levels of FAL in its product with its support for the OIDC and SAML standards, ability to encrypt SAML assertions, and ability to enforce multi-factor authentication using cryptographic methods for the end user during the process of authenticating to the Idaptive IdP.
Federation Proxies – now this gets interesting!
An interesting concept explained in this blog is the idea of Federation Proxies. I’ve heard people refer to this concept in many ways – IdP Chaining, IdP Delegation, etc. Essentially, this concept refers to a scenario where communication between the IdP and the RP is intermediated via a third party that prevents direct communication between the two parties. A common way of achieving this is with a third party that acts as a federation proxy or a broker. Below is a diagram that illustrates that concept:
Idaptive can be leveraged in this model, where it acts as a proxy between an IdP and a RP. In this model, the end user will still authenticate against the IdP, but her assertion will be proxied through Idaptive to the RP which will single sign the user in. Interestingly, many of our customers are starting to use this model as a way of incrementally migrating away from legacy IdPs to Idaptive. This model ensures minimal disruption to the end user since they continue authenticating to their old IdP and login portal, while ensuring that modern federation systems like Idaptive are deployed to work with their applications (RPs). Idaptive does this really well – we have the ability to dynamically chain to other IdPs based on user attributes such as username suffixes.
So, where does SAML fit in?
Now SAML, as a standard, is comprehensive enough for multiple individuals to do their PhDs in, but I’ll use this forum to very briefly introduce this concept in simple terms.
SAML, which stands for Specific Assertion Markup Language and OIDC, which stands for OpenID Connect, are two of the most common federation standards in the market. SAML is an XML framework for creating and exchanging authentication and attribute information between trusted entities over the internet. The SAML standard defines:
- Assertions XML Schema: the structure of the assertion
- SAML Protocols: the interaction sequences that are used to request assertions and artifacts
- SAML Bindings: the underlying communication protocols and can be used to transport SAML assertions.
The three components above together define a SAML profile – an example of which is “Web Browser SSO” or “Service Provider (RP) Initiated SSO”. A typical SAML assertion, sent from an IdP to a RP, is encoded in XML schema and can carry three types of statements:
- Authentication Statement: includes information about who has issued the assertion, the user for which the assertion was issued, its validity period and other authentication information.
- Attribute Statement: includes additional information related to the user, examples of which could be “roles” or “departments”.
- Authorization Statement: includes information on what resources the user has the rights or privileges to access, such as files, devices, web pages within a website, etc.
Looking for Federation technologies?
At Idaptive, support for federation scenarios leveraging open standards is one of the cornerstones of our cloud service since its inception. Idaptive has invested heavily in ensuring that scenarios such as IdP initiated or SP initiated SSO, or IdP Proxying or Chaining, or support for standards like SAML, OIDC, OAuth 2.0, etc., whether for workforce, partner or customer users. Additionally, we have over 2000 apps in our app catalog, many of which are SAML, OIDC and OAuth 2.0 based applications. And for applications that we do not have built-in out-of-the-box templates, you can always use our application integration wizards that will guide you through the process of customizing and enabling a new application for SSO. If you’re interested in learning more, please do not hesitate to try our service for free here or reach out to us directly.
