Claims-Based Identity
Fleeting- External reference: https://en.m.wikipedia.org/wiki/Claims-based_identity
Claims-based identity abstracts the individual elements of identity and access control into two parts: a notion of claims, and the concept of an issuer or an authority
The subject making the claim or claims is the provider. Claims are packaged into one or more tokens that are then issued by an issuer (provider), commonly known as a security token service (STS).
Here, the tokens might be access token as well as ID Token.
Attaching the concept of claims to the concept of identity appears to be combining authentication (determination of identity) with authorization (what the identified subject may and may not do). However a closer examination reveals that this is not the case. Claims are not what the subject can and cannot do. They are what the subject is or is not. It is up to the application receiving the incoming claim to map the is/is not claims to the may/may not rules of the application. In traditional systems there is often confusion about the differences and similarities between what a user is/is not and what the user may/may not do. Claims-based identity makes that distinction clear.
Once the distinction between what the user is/is not and what the user may/may not do is clarified, it is possible that the authentication of what the user is/is not (the claims) can be handled by a third party. This third party is called the security token service
analogy of a night club with a doorman. [..] he requests […] a driver’s license […] (the token) that has been issued by a trusted third party (the security token service) such as the state vehicle license department. […] It only has to trust the issuing authority[…]. With these two steps completed the nightclub has successfully authenticated […] with regard to the claim […] doorman might ask for another token […] which might make another claim […] translating the authenticated […] claim to a permission.
facts, or claims, are transported in an “envelope” called a secure token
Unfortunately, this appears not to have anything to do with security token in blockchain lingo.
Claims-based identity can greatly simplify the authentication process because the user doesn’t have to sign in multiple times to multiple applications.
A single sign in creates the token which is then used to authenticate against multiple applications, or web sites. In addition, because certain facts (claims) are packaged with the token, the user does not have to tell each individual application those facts repeatedly, for instance by answering similar questions or completing similar forms
Claim-based identities in multitenant apps
- External reference: https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/claims
Claim-based identities in multitenant apps - Azure Architecture Center
With claims, a user’s identity is no longer a monolithic entity.
— https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/claims
IDP stores all of this information. But when you authenticate the user, you’ll typically get a subset of these as claims. In this model, the user’s identity is simply a bundle of claims
— https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/claims
When you make authorization decisions about a user, you will look for particular sets of claims.
— https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/claims
question “Can user X perform action Y” ultimately becomes “Does user X have claim Z”.
— https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/claims
claim
A claim is a statement that one subject, such as a person or organization, makes about itself or another subject