|
Well, not exactly to a 5-year-old, but please avoid buzzword and enterprisespeak if possible. Claims-based authentication seems to be all the rage now, but I could not find a simple and down-to-earth explanation of what it actually is, how is it different from what we have now (I assume "what we have now" to be role-based authentication), what are the benefits of using it, etc. |
|||||
|
|
@Marnix has a pretty good answer, but to step away from the technical aspect of it: Claims Based Authentication is about defining who you trust to give you accurate information about identity, and only ever using that information provided. My (the) go-to example is at a bar. Imagine for a moment that you want to get a beer at the bar. In theory the bartender should ask you for proof of age. How do you prove it? Well, one option is to have the bartender cut you in half and count the number of rings, but there could be some problems with that. The other option is for you to write down your birthday on a piece of paper to which the bartender approves or disapproves. The third option is to go to the government, get an ID card, and then present the ID to the bartender. Some may laugh at the idea of just writing your birthday on a piece of paper, but this is what is happening when you are authenticating users within the application itself because it is up to the bartender (or your application) to trust the piece of paper. However, we trust the government's assertion that the birthday on the ID is valid, and the ID is for the person requesting the drink. For all intents and purposes, the bartender (or application) doesn't really care how the authentication occurred because of the trust. The bartender knows nothing about you except your date of birth because that's all the bartender needs to know. Now, the bartender could store information that they think is important to them, like your favorite drink, but the government doesn't care (as it isn't the authoritative source), so the bartender stores that information in his own way. The key to CBA is "who is the authoritative source of the identity?" |
|||||||||
|
|
(This is my personal take on this, others may differ. Please post other viewpoints as separate answers.) Claims-based identity/authentication/authorization is about separating the maintenance of user authorizations and user sign-in out of a (web) application, by turning authentication/authorization into a separate (web) service. So for example, when I browse to a claims-enabled web application for the first time, it will redirect my browser to a 'logon service' which it trusts. I will authenticate to that service (using Windows authentication, a smart card, or whatever), and in response it sends back a 'token', which the browser sends back to the web application. Now the web application checks that the token is digitally signed by its trusted logon service, and then looks at the 'claims' in the token. Based purely on those claims, the application decides what functionality the user is offered. The claims will almost always include the user's identity, often there are also authorization-related claims ('this user may view Sales data, but not update it'), and sometimes other information as well ('shoe size = 42'). The key point is that the application does not know nor care how the user was authenticated, nor how the authorizations are administrated: it only uses the information from the claims in the signed token to determine who the user is and/or what the user may see or do and/or any other information about the user. (Yes, I'm assuming a pretty intelligent and well-informed 5-year-old here. :-) |
|||
|
|
|
For a 5 years boy, ask him to assume he joined a new school by signing the application by his parents. After approval from school management for his application, he gets a access card which contains all the below information which we can call it CLAIMS to enter into the school.
On first day of his school while he walks into the school, he swiped his access card and the gates opened, means he has been CLAIMED AS one of the person from the school. In this way he is an AUTHENTICATED PERSON to enter into the school. After reaching to his class, he used access card to enter into each class, but at 8th Standard Class doors opened as he Claimed to be from 8th Standard. In the school, he is only AUTHORIZED to enter into his class as he is now studying 8th Standard. And if he try to enter into 6th Standard, the school teacher WON'T AUTHORIZE him. |
|||||
|
