Using claims-based identity to achieve multi-factor authentication

Claims-based identity in real life

The claims-based identity model is a secure way to authenticate users for access but understanding how the trust relationship works is key. Instead of jumping into claims, security tokens and Identity Providers let’s talk about a real-life scenario that many people have experienced: showing ID to get into a club.

Think about the last time you went to a club. The bouncer verified your age by looking at your driver’s license. He relied on the third-party authority that backed up your word that you were above the legal drinking age. He trusted the assertion because he trusted that the DMV had verified the claim about your age by looking at your birth certificate, your passport, phone bill or proof of residency. One issuer (DMV) trusts another issuer of identity claims (the registrar of births) and that’s how they establish a chain of trust. Therefore, when you made the identity claim (“I’m above twenty-one”) you were trusted indirectly by the bouncer, based on your relationship with the registrar of births and the trusted relationship between the registrar and DMV.

Claims-based identity model explained

This simple scenario illustrates the components of the claims-based identity model. There are specific Identity Providers that the bouncer trusts. In this case, it is DMV that has verified your identity and issued a driver’s license. The driver’s license issued is considered an acceptable security token. The security token itself contains one or more claims – statements about a subject such as name, birth date, height, weight, photograph and so on. These are called claims because are supposedly true statements about the subject but can only be trusted if the Identity Provider that issues the security token is trusted.

In the real world, you aren’t asked to provide your birth certificate, passport, phone bill or proof of residency every time you need to prove your identity. Most of the time you just need to present your driver’s license. Similarly, claims-based identity simplifies the authentication process so you can use the trust of one Identity Provider to sign in to multiple applications. A sign in service creates the token which is then used to authenticate against multiple applications, or web sites. Because certain facts (claims) are packaged with the token, the user does not have to tell each individual application those facts repeatedly, such as completing similar forms.

Apply the same logic to self-service password reset

Self-service password reset solution such as Specops uReset is built on the claims-based identity model. Specops uReset allows users to reset their passwords using digital identity services they have pre-selected or have been registered by the admin. During a password reset, the user collects security tokens from various identity services that he or she is required to authenticate with such as Salesforce, Facebook and Google. Token signatures are verified to ensure that they were originated by trusted issuers and user identifiers within the tokens are validated via Active Directory. As such, if the token signature is valid, the user is authenticated against Active Directory. If a user fulfills their uReset Policy, they are authorized to perform a password change or password reset.