InfoSec Pros and Wannabes - Help with Claims-Based Auth

RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
I'm working on writing up an explanation of claims-based authentication as I prepare for my MCSD SharePoint/MCSD Web Applications certs and I was hoping that I could get a critique on my notes (to be a blog post) regarding definitions. Honestly, these are mostly for my own benefit. But if I am going to publish them I'd like to hear what other think. Currently I just have the following definitions. There will be a few more definitions, then a high level process-flow of claims authentication in SharePoint and then a bibliography. But any comments on what I have up to this point would be welcome. And just to be clear, I don't mean wannabe in a negative way. I too am a wannabe in the information security world.


The Vocabulary of Authentication and Authorization

Principal – an entity capable of acting within a system such as an individual user, a server, a computer system, a process or a thread or any group of these things. A principal must be authenticated even if the authentication is considered “anonymous”. In Microsoft parlance, you will generally encounter the term security principal.

Authenticate – to establish as genuine. In a technical sense, it is to establish the identity of a principal as genuine. A system authenticates an identity by exchanging some secret (password, certificate, key, or token) which establishes the principal’s identity. Cases where both sides exchange secrets to authenticate each other is known as mutual authentication.

Resource – something capable of being acted upon in a system such as a file system, a file, computer, a web service, etc. A resource may also be a principal. A web service that provides details about a user, for example, may be expected to prove its identity, before it is trusted to provide details regarding the user. In this way the web service is a both a resource and a principal. In some cases, synonyms for resource may be object or target.

Authorize – to give official power to perform an action within a system. Before a principal is allowed to perform an action within a system the principal must be authenticated and then the system will be able to verify if the principal is authorized to perform the action in question.

Role – a title or function that defines a level of authority. In some cases this may be synonymous with a group. For example, a user who is a member of the HR group (their job function is human resources) will be authorized to perform tasks in a system related to that job function. See also Role-based access control, mandatory access control, and discretionary access control.

Ticket – A number that cannot be easily forged that is used for either authentication or authorization. Tickets may be opaque or transparent.

Kerberos - a computer network authentication protocol which works on the basis of 'tickets' to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed it primarily at a client–server model and it provides mutual authentication - both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication. URL="http://en.wikipedia.org/wiki/Kerberos_(protocol)"]from Wikipedia[/URL

Token – Not to be confused with a ticket, a token is a data structure that is cryptographically signed and is used to authenticate and authorize a principal. As a data structure it can have any number of claims, i.e. attributes, that describe a user. The system that uses this token does not care what or how many claims there are as long as they are in an agreed upon format and cryptographically signed.

IdP – Identity Provider, Identity Assertion Provider. In claims-based authentication, this is a system responsible for creating, maintaining, and providing identity information for a principal.

Relying Party – A relying party is the system that receives and uses the token for authentication and authorization. A relying party may also be an STS. SharePoint, for example, may receive a token and after verifying its signature transform the token by adding additional claims and then digitally signing the resulting token with its own private key.

STS – A Security Token Service is a web service that issues signed tokens
Sign In or Register to comment.