When discussing Claims-Based Identity, a claim is a statement that one subject (a person, organization, or thing) can make about itself, or about another entity. In an AD FS deployment, for example, claims can be made about the name, age, role, or other attributes of a user (the subject), by an AD FS server acting as a Claims Provider. A Relying Party can then rely on the values of those claims when submitted by the user attempting to access a claims-aware application.

AD FS works with claims in the following ways:

·       An AD FS server configured as a Claims Provider will issue claims about users that it authenticates, by constructing claims based on data it retrieves from one or more attribute stores, and packaging those claims in the form of a signed SAML token.

·       An AD FS server configured as a Relying Party will consume claims that it receives from a user; these claims will have been signed by a Claims Provider that the Relying Party trusts.

AD FS also supports the notion of claims transformation, which allows different organizations to translate claims from one federation server to another. For example, a claim from a Claims Provider asserting Is a full-time employee might be transformed by the Relying Party into a claim of OK to purchase. Similarly, the claim Born on March 22, 1957 could be transformed into the claim Legally able to purchase alcohol, which, if the RP is a wine seller, supplies sufficient information to complete a transaction without actually revealing the user’s age. Strictly speaking, all Relying Party federation servers act as a claims transformer because they receive an incoming token from a Claims Provider, and then issue a new token that has been signed by the RP’s token-signing certificate. (Though it is entirely possible that an RP federation server will simply pass through certain incoming claims values unaltered, the claim has still been transformed into one that has been issued and signed by the RP federation server.)

Each AD FS claim has a claim type, such as Email Address, UPN, or Given Name. Users can be issued claims corresponding to any defined claim type, and each claim will have a corresponding claim value. So a user might be issued a claim with a type of Email Address and a value of adamcar@adatum.com, or a claim with a type of Car Color and a value of RED.

AD FS 2.0 ships with a number of built-in claim types, or you can create new ones to fit your needs. In previous versions of AD FS, you were able to configure claims that fit one of three possible types:

·       Identity claim – This was a required claim on each AD FS server, and was required to be mapped to a user’s email address, Universal Principal Name (UPN), or common name (CN). (Though common name was not often used in practical terms.)

·       Group claim – A group claim mapped to membership in an Active Directory or AD LDS security group.

·       Custom claim – A custom claim could be mapped to any AD or AD LDS attribute configured on the user account.

Where AD FS 2.0 is concerned, this distinction between Identity claim, Group claim and Custom claim no longer exists: in effect, all claim types are custom claims, regardless of their content or purpose. Each AD FS 2.0 claim type is configured with a Uniform Resource Identifier (URI) that uniquely identifies the claim type on the AD FS server, and when advertising the existence of that claim in the AD FS server metadata. For example, if you wish to transmit a claim of type Car Color to a remote partner, both you and your partner would need to configure a new claim type so that this claim can flow between the two organizations. In particular, the claim type URI needs to match across federation servers, so that the claim type can be seen as the same: that is, https://tempuri.org/carcolor and https://tempuri.org/color would not be seen as the same claim type, even if they were both configured with a display name of Car Color.

• Authentication/Token cookie (_WebSsoAuth) – This cookie represents the login to a federation resource. This is a session cookie that expires when the user closes the browser session.
• Home realm discovery (LSRealm) – This is a file-based cookie (the expiry field is set to 30 days by default). Otherwise known as a persistent cookie, this is issued by the relying party’s Federation Server once the user has been successfully authenticated by their claims provider, with a CP-signed token returned to the RP. The purpose of the cookie is to avoid the need for clients to have to go through the whole home realm discovery process every time they try to access a resource.
• Logout cookie (_LSCleanup) – The _LSCleanup cookie assists in the logout process by keeping track of which federation severs and applications the user has visited. The process sets all the _WebSsoAuth cookies to null. The logout cookie is a session cookie.
• MSISLoopDetection – Used to detect a client that continually requests a token due to a configuration error on the web server, STS, or client computer.