Understanding claims - based authentication is a book unto itself. For this reason, this section will
give just a quick primer on claims - based authentication and what it means to you as a developer.
Claims - based authentication is based on identity and trust. Some systems may identify you as being
20 years old, and some may identify you as being 30 years old. With claims - based authentication,
you decide which claim you want to trust, the 20 - year - old or the 30 - year - old claim. Claims - based
authentication, in a way, is more complex that using Windows - based authentication from an IT
standpoint but provides better functionality from an identity protection and platform standpoint.
What Is the Value of Claims?
To understand the value of claims, you need to forget for a moment all the other authentication
methods that you are used to. If you box yourself into thinking about or comparing claims to those
other methods, it will be hard to break out of the constraints of those authentication methods. For
example, if you use Windows integrated authentication, you probably think of identity in terms of
Windows user accounts and groups. For ASP.NET, membership and roles provider are your context,
and for forms - based authentication, usernames, passwords, and roles are your context. If you
abstract out from these authentication methods to the high - level concepts, you have a claim of some
type of information, and you have an issuer or authority that verifi es that claim. Because you have
a trust relationship with the issuer, you trust the claim that comes from that issuer. Trust is explicit,
which is different from the other authentication methods you may be used to.
The value of claims is fl exibility. Because claims are extensible and standards - based, you can create
different attributes on your identity, pass that around to different applications, create roles and even
use standards - based tokens, such as Security Assertion Markup Language (SAML) tokens, to identify
and make a claim against access to a resource or application. The other value of claims is that you
can use almost any authentication method you want on the backend, but in your application, you do
not have to recode if you want to switch from NTLM to Kerberos or to forms - based authentication.
This gives you ultimate fl exibility in the security and authorization part of your application.
When to Use Claims
Not every application needs claims. For example, if you can get by with Windows authentication,
and you are reasonably confi dent that your identity needs won ’ t change, stick with Windows
authentication. Claims - based authentication is a good choice when you need fl exibility and
functionality and are willing to pay the price for those capabilities. If you are working in a hybrid
identity and authentication environment, look at claims as a solution, so that you can practice
writing all your applications as claims - aware applications, whether they are internal, external,
or somewhere in - between. Having the fl exibility of claims will make your application lifecycle
management easier.
Claims - Based Authentication Simplifi es Your Authentication Code
Almost every application has code that supports identity and authentication. It may not be explicit
sometimes, but it is in the layers that make up your application, even if you did not write it yourself.
If you are used to writing using Windows authentication, you probably haven ’ t had to worry about
authentication code as much as a web developer who uses forms - based authentication and must write
the code to check the username and password and perform password resets and account lockouts
has. Windows authentication developers have the power of the domain and domain controllers to
help them with all the services surrounding identity and user management.
Even with Windows authentication, while authentication may be provided for you, there are
limitations. Once you go beyond the domain limit to try to authenticate against other domains that
you may not trust, the developer becomes responsible for making sure that the complexities of trusts
and relationships are set up by IT. In addition, if you want more information than username and
password for your application, then you must move away from your authentication code to write to
directory services. This means that you will be maintaining two code paths, one for authentication
and one to get additional identity attributes.
Claims can solve these issues because they can be more than just usernames and passwords, and can
contain things like groups, manager, email, and other user profi le attributes that you may need for
your application. Again, you factor out the authentication provider in claims from your claims - aware
application, so you do not care how the authentication was performed on the backend.
How Does Claims - Based Authentication Work?
This is the simplifi ed version of how claims work. The easiest way to think about how claims work
is to take a real - world example. Let ’ s imagine that you need to board an airplane. First, you need to
check in. That could be at the ticket counter or that could be online. Both require you to authenticate
yourself but in different ways. The ticket counter requires you to show some form of ID and that ID
comes from a trusted source. Online, you ’ re forced to log in and that login must be trusted in order
for you to print your boarding pass.
Your boarding pass contains a lot of extra information rather than just your name. It contains your
destination, the gate you ’ re leaving from, your fl ight number, and also your seat information. When
you reach the gate, the gate agent checks your boarding pass. This agent doesn ’ t really care whether
your claim came from the ticketing agent or from your printer at home. The boarding pass is a
trusted claim and you ’ re allowed to get on your fl ight. If we translate this to software, that boarding
pass is a signed security token from a trusted issuer. Your application would validate it and allow the
user or application presenting that token to have access to the resource that was requested.
give just a quick primer on claims - based authentication and what it means to you as a developer.
Claims - based authentication is based on identity and trust. Some systems may identify you as being
20 years old, and some may identify you as being 30 years old. With claims - based authentication,
you decide which claim you want to trust, the 20 - year - old or the 30 - year - old claim. Claims - based
authentication, in a way, is more complex that using Windows - based authentication from an IT
standpoint but provides better functionality from an identity protection and platform standpoint.
What Is the Value of Claims?
To understand the value of claims, you need to forget for a moment all the other authentication
methods that you are used to. If you box yourself into thinking about or comparing claims to those
other methods, it will be hard to break out of the constraints of those authentication methods. For
example, if you use Windows integrated authentication, you probably think of identity in terms of
Windows user accounts and groups. For ASP.NET, membership and roles provider are your context,
and for forms - based authentication, usernames, passwords, and roles are your context. If you
abstract out from these authentication methods to the high - level concepts, you have a claim of some
type of information, and you have an issuer or authority that verifi es that claim. Because you have
a trust relationship with the issuer, you trust the claim that comes from that issuer. Trust is explicit,
which is different from the other authentication methods you may be used to.
The value of claims is fl exibility. Because claims are extensible and standards - based, you can create
different attributes on your identity, pass that around to different applications, create roles and even
use standards - based tokens, such as Security Assertion Markup Language (SAML) tokens, to identify
and make a claim against access to a resource or application. The other value of claims is that you
can use almost any authentication method you want on the backend, but in your application, you do
not have to recode if you want to switch from NTLM to Kerberos or to forms - based authentication.
This gives you ultimate fl exibility in the security and authorization part of your application.
When to Use Claims
Not every application needs claims. For example, if you can get by with Windows authentication,
and you are reasonably confi dent that your identity needs won ’ t change, stick with Windows
authentication. Claims - based authentication is a good choice when you need fl exibility and
functionality and are willing to pay the price for those capabilities. If you are working in a hybrid
identity and authentication environment, look at claims as a solution, so that you can practice
writing all your applications as claims - aware applications, whether they are internal, external,
or somewhere in - between. Having the fl exibility of claims will make your application lifecycle
management easier.
Claims - Based Authentication Simplifi es Your Authentication Code
Almost every application has code that supports identity and authentication. It may not be explicit
sometimes, but it is in the layers that make up your application, even if you did not write it yourself.
If you are used to writing using Windows authentication, you probably haven ’ t had to worry about
authentication code as much as a web developer who uses forms - based authentication and must write
the code to check the username and password and perform password resets and account lockouts
has. Windows authentication developers have the power of the domain and domain controllers to
help them with all the services surrounding identity and user management.
Even with Windows authentication, while authentication may be provided for you, there are
limitations. Once you go beyond the domain limit to try to authenticate against other domains that
you may not trust, the developer becomes responsible for making sure that the complexities of trusts
and relationships are set up by IT. In addition, if you want more information than username and
password for your application, then you must move away from your authentication code to write to
directory services. This means that you will be maintaining two code paths, one for authentication
and one to get additional identity attributes.
Claims can solve these issues because they can be more than just usernames and passwords, and can
contain things like groups, manager, email, and other user profi le attributes that you may need for
your application. Again, you factor out the authentication provider in claims from your claims - aware
application, so you do not care how the authentication was performed on the backend.
How Does Claims - Based Authentication Work?
This is the simplifi ed version of how claims work. The easiest way to think about how claims work
is to take a real - world example. Let ’ s imagine that you need to board an airplane. First, you need to
check in. That could be at the ticket counter or that could be online. Both require you to authenticate
yourself but in different ways. The ticket counter requires you to show some form of ID and that ID
comes from a trusted source. Online, you ’ re forced to log in and that login must be trusted in order
for you to print your boarding pass.
Your boarding pass contains a lot of extra information rather than just your name. It contains your
destination, the gate you ’ re leaving from, your fl ight number, and also your seat information. When
you reach the gate, the gate agent checks your boarding pass. This agent doesn ’ t really care whether
your claim came from the ticketing agent or from your printer at home. The boarding pass is a
trusted claim and you ’ re allowed to get on your fl ight. If we translate this to software, that boarding
pass is a signed security token from a trusted issuer. Your application would validate it and allow the
user or application presenting that token to have access to the resource that was requested.
No comments:
Post a Comment
Thank you for Commenting Will reply soon ......