Claims list included in the ClaimsPrincipal usually originate from the security token received by the application as part of user authentication (SAML, OpenIDConnect id token) or access authorization (OAuth2 bearer access token). However, sometimes there is a need to modify that list with claims derived from other sources:
- Attributes retrieved from custom databases
- Attributes not initially included in the security token but which can be retrieved from the Security Token Service (e.g. Azure AD via Graph API).
Usually such token augmentation is done as soon as the initial security token is validated, e.g. http://www.cloudidentity.com/blog/2015/08/26/augmenting-the-set-of-incoming-claims-with-the-openid-connect-and-oauth2-middleware-in-katana-3-x/.
In order to accomplish #2 above the application will need an access token to Azure AD (assuming that is the STS used by the application). In that case the earliest event when this can be accomplished in a regular web application using OpenIDConnect authentication is when the authorization code returned together with the id token is converted into an AAD access token, i.e. in the AuthorizationCodeReceived delegate.
Occasionally, however an application may need to modify the claims list much later, in the regular application code rather than Startup.auth.cs. What is important though is that not only the memory list is modified but that the list is then serialized to the authentication cookie for future use if the application is using cookies. Theoretically, that should be possible by adding a new ClaimsIdentity to the ClaimsPrincipal. However, OWIN in ASP.NET 4 will not serialize the new identity. An alternative method is to modify the existing ClaimsIdentity as follows:
var id = (ClaimsIdentity)(ClaimsPrincipal.Current.Identity);
id.AddClaim(new Claim(“Extra”, “Extra claim”));
Request.GetOwinContext().Authentication.SignIn(id);
The new ‘Extra’ claim will now be associated with the current ClaimsPrincipal in all subsequent requests for this user.