Q: How does one add a claim to an HTTP request? 

A: ClaimProvisioning topic has been explained here. A claim is a combination of a claim type, right, and a value. A claim set is a set of claims issued by an issuing authority.  A claim can be a DNS, email, hash, name, RSA, sid, SPN, system, thumbprint, Uri, and X500DistinguishedName type.  An evaluation context is a context in which an authorization policy is evaluated. It contains properties and claim sets and once the evaluation is complete, it results in an authorization context once authorization policies are evaluated. An authorization policy is a set of rules for mapping a set of input claims to a set of output claims and when evaluated, the resulting authorization context has a set of claims sets and zero or more properties. An identity claim in an authorization context makes a statement about the identity of the entity. A group of authorization policies can be compared to a machine that makes keys. When the policies are evaluated a set of claims is generated, it is like the shape of the key. This key is stored in the form of an authorization context and can be used to open some locks. The granting of access is the opening of a lock Identity model does not mandate how the claims should be authored but it requires that the set of required claims must be satisfied by those in the authorization context.   

 

An HTTP request is made with the help of an authentication header. This has a bearer token when the request needs to be authenticated and authorized. The token is issued to an identity and Windows lists many forms of identity including but not restricted to UserCredential, ApplicationCertificateThumbprint, ApplicationClientId, ApplicationKey, ApplicationNameForTracing, ApplicationToken, Authority, EmbeddedManagedIdentity, ApplicationCertificateSubjectDistinguishedName, ApplicationCertificateIssuerDistinguishedName, and ApplicationCertificateSendPublicCertificate. These are all convertible to a claims principal as follows: 

var claimsPrincipal = HttpContext.Current.User as ClaimsPrincipal; 

 This claims Principal can now be converted to a ClaimsIdentity to which additional claims can be added. The following is an example to do just that. 

using System.Security.Claims; 

using System.Security.Cryptography.X509Certificates; 

using System.Security.Principal; 

                    bool found = false; 

                    var claimsPrincipal = HttpContext.Current.User as ClaimsPrincipal; 

                    foreach (var claim in claimsPrincipal.Claims) 

                    { 

                        if (claim.ToString().Contains("Administrator")) 

                        { 

                            found = true; 

                        } 

                    } 

                    if (!found) 

                    { 

                        var claimValue = string.Format("claim://{0}", "Administrator"); 

                        claimsPrincipal.AddIdentity(new ClaimsIdentity(new List<Claim>() { new Claim(ClaimTypes.Role, claimValue) })); 

                        HttpContext.Current.User = claimsPrincipal; 

                    } 

The HttpContext is resolved on the server side. 

Note that on the client side, the user is usually resolved as System.Security.Principal.WindowsIdentity.GetCurrent()

And then this can be used as a ClaimsPrincipal. 

Again, once the claimsPrincipal has been granted all the additional claims, then the token can retrieved with the new ClaimsPrincipal. 

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. 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's principal name as a claim from heterogeneous devices, applications and services and generates an impersonation token granting user level access to those entities.

Once a claim has been added to the claimsPrincipal, a token can be retrieved like the example here with suitable parameters for the AcquireTokenAsync call:

        private static string GetToken()

        {

            string clientID = "Client ID";

            string AuthEndPoint = "https://login.microsoftonline.com/{0}/oauth2/token";

            string TenantId = "Tenant ID";

            string redirectUri = "https://login.microsoftonline.com/common/oauth2/nativeclient";

            string resourceUri = "https://analysis.windows.net/powerbi/api";

            string authority = string.Format(CultureInfo.InvariantCulture, AuthEndPoint, TenantId);

            AuthenticationContext authContext = new AuthenticationContext(authority);

            string token = authContext.AcquireTokenAsync(resourceUri, clientID, new Uri(redirectUri), new PlatformParameters(PromptBehavior.Auto)).Result.AccessToken;

            return token;

        }