Introduction: This is an interesting topic in
identity model used by applications and services. A user presents an identity
to an application as a set of claims. Some examples of a claim include a
username, an email address or even a fingerprint. The application itself does
not resolve the identity and instead delegates it to an external identity
system which can be specified via configuration to the application. The
delegation works to provide the user information to the application and to
ensure that the application receives that from a trusted source. This article
explains this concept.
Description: Using this technique, an
application is no longer responsible for the following: 1) authenticating users
2) storing user accounts and passwords, 3) calling membership providers like
enterprise directories to lookup user information 4) integrating with identity
systems from other organizations and 5) providing implementations for several
protocols to be compliant with industry standards and business practice. All
the identity related decisions are based on claims supplied by the user. An identity is a set of attributes that
describe a principal. A claim is a piece of identity information. The more slices
of information an application receives, the more complete the pie representing
the individual. Instead of the
application looking up the identity, it merely serializes them to the external
system. A security token is a serialized set of claims that is digitally signed
by the issuing authority. It gives the assurance that the user dd not make up
the claim. An application might receive the claim via the security header of
the SOAP envelope of the service. A browser-based web application arrives
through an HTTP POST from the user’s browser which may later be cached in a
cookie if a session is enabled. The manner might vary depending on the clients
and the medium but the claim can be generalized with a token. Open standards including some well-known
frameworks are great at creating and reading security tokens. A security token
service is the plumbing that builds, signs and issues security tokens. It might
implement several protocols for creating and reading security tokens but that
is hidden from the application.
The issuing authority for a security token does not have to
be of the same type as the consumer. Domain controllers issue Kerberos tickets
and X.509 certificate authorities issue chained certificates. A token that
contains claims is issued by a web application or web service that is dedicated
to this purpose. This plays a significant role in the identity solution.
The relying parties are the claim-aware applications and the
claims-based applications. These can also be web applications and services, but
they are usually different from the issuing authorities. When it gets a token,
the relying parties extract claims from the tokens to perform specific identity
related tasks
Interoperability between issuing authorities and relying
parties is maintained by a set of industry standards. A policy for the
interchange is retrieved with the help of a metadata exchange and the policy
itself is structured. Sample standards include Security Assertion Markup
Language which is an industry recognized XML vocabulary to represent claims.
A claim to token conversion service is common to an identity
foundation. It extracts the user principal name as a claim from heterogeneous
devices, applications and services and generates an impersonation token
granting user level access to those entities.
Conclusion: Claims based model enables a flexible approach
to an identity model.
Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWsUjNXSm1Aoi94OKA
No comments:
Post a Comment