We have a class called ConfigureBackOfficeOktaAuth within which we wire up OpenIdConnectAuthenticationNotifications and in AuthorizationCodeReceived we add some claims to the backoffice identity see :
var tokenClient = new TokenClient(Issuer + "/v1/token", clientId, clientSecret: clientSecret);
var tokenResponse = await tokenClient.RequestAuthorizationCodeAsync(n.Code, GetRedirectUri(n.Request.Uri));
var id = n.AuthenticationTicket.Identity;
id.AddClaim(new Claim("access_token", tokenResponse.AccessToken));
id.AddClaim(new Claim("refresh_token", tokenResponse.RefreshToken));
n.AuthenticationTicket = new AuthenticationTicket(id, n.AuthenticationTicket.Properties);
All works and we would expect the claims to be available later. Stepping through the code we check and we definately have the claims set, however later on in a umbraco backoffice webapi controller we do not see the claims it looks they have been lost.
When setting up your oauth owin client, we expose 'auto link options' and if you create some auto link options you can assign a callback: OnExternalLogin which accepts both the BackOfficeIdentityUser (which is the object that will be used to create the ClaimsIdentity stored in the cookie) and the ExternalLoginInfo which contains the information about the external identity sent back by your OAuth client.
In this callback, you could then add claims to the BackOfficeIdentityUser.Claims collection based on the claims in your external identity
In theory this should persist all of the Claims in this collection to the cookie which you could then resolve from the current request/thread principle/user object since that will be a ClaimsIdentity. Also, if you are auto-linking, then you might also need to do this logic in the OnAutoLinking callback for when a user is first created.
There is actually a TODO in the BackOfficeController:
// TODO: It might be worth keeping some of the claims associated with the ExternalLoginInfo, in which case we...
Ideally we'd make this process easier but I haven't looked into all of this for some time.
If this doesn't work, it is far more tricky and I'm unsure it would be possible without modifying the core or replacing a lot of things like the current BackOfficeUserManager, etc...
Also note that I 'think' you will still need to do the code you posted above because that auth ticket you are modifying is the external auth ticket for the external auth cookie during the redirect.
You also don't need to get the Identity from the OwinContext, the ClaimsIdentity is attached to all requests/threads as the Principle.Identity which is always a ClaimsIdentity. For example: HttpContext.Request.User or Thread.CurrentThread.User, in WebApi i think the User/Principle is attached to the webapi Request, and in owin it's attached to the OwinContext.Request.User ... you don't need to extract it from the actual auth ticket (i.e. cookie)
var accessToken = loginInfo.ExternalIdentity.Claims.FirstOrDefault(x => x.Type == "access_token");
var AccessTokenClaim = new IdentityUserClaim<int>
{
UserId = autoLinkUser.Id,
ClaimType = "access_token",
ClaimValue = accessToken.Value
};
autoLinkUser.Claims.Add(AccessTokenClaim);
autoLinkUser.Name = loginInfo.ExternalIdentity.Name;
Which, with a breakpoint after, seems to be adding the claim correctly. The problem is on a webapi controller, we've tried all the suggested ways to get the identities, and none of those identities contain the claim we are expecting.
We are thinking, as a workaround, to create a new table that contains access and refresh tokens, and a link to the user (either using the autolinkuser ID or the email and looking it up later).
Issue when adding custom claim to backoffice identity
So I have a 8.1.1 site.
We have a class called ConfigureBackOfficeOktaAuth within which we wire up OpenIdConnectAuthenticationNotifications and in AuthorizationCodeReceived we add some claims to the backoffice identity see :
All works and we would expect the claims to be available later. Stepping through the code we check and we definately have the claims set, however later on in a umbraco backoffice webapi controller we do not see the claims it looks they have been lost.
We expect this line:
The Identity to contain the 2 claims we added. However this is not the case.
Anyone any ideas?
Hi Ismail,
I 'think' you can do this:
OnExternalLoginwhich accepts both theBackOfficeIdentityUser(which is the object that will be used to create the ClaimsIdentity stored in the cookie) and theExternalLoginInfowhich contains the information about the external identity sent back by your OAuth client.BackOfficeIdentityUser.Claimscollection based on the claims in your external identityIn theory this should persist all of the Claims in this collection to the cookie which you could then resolve from the current request/thread principle/user object since that will be a ClaimsIdentity. Also, if you are auto-linking, then you might also need to do this logic in the
OnAutoLinkingcallback for when a user is first created.There is actually a TODO in the BackOfficeController:
Ideally we'd make this process easier but I haven't looked into all of this for some time.
If this doesn't work, it is far more tricky and I'm unsure it would be possible without modifying the core or replacing a lot of things like the current BackOfficeUserManager, etc...
Also note that I 'think' you will still need to do the code you posted above because that auth ticket you are modifying is the external auth ticket for the external auth cookie during the redirect.
You also don't need to get the
Identityfrom the OwinContext, the ClaimsIdentity is attached to all requests/threads as the Principle.Identity which is always a ClaimsIdentity. For example: HttpContext.Request.User or Thread.CurrentThread.User, in WebApi i think the User/Principle is attached to the webapi Request, and in owin it's attached to the OwinContext.Request.User ... you don't need to extract it from the actual auth ticket (i.e. cookie)Hi Shannon
We are trying that, but on the
OnExternalLogin, when we try to add a custom claim, it's complaining.Because
BackOfficeIdentityUserdoesn't want a normal Claim, it wants anIdentityUserClaimand we don't seem to be able to generate a custom one.Any advice?
Update:
So, we've tried this in the
OnAutoLinking:Which, with a breakpoint after, seems to be adding the claim correctly. The problem is on a webapi controller, we've tried all the suggested ways to get the identities, and none of those identities contain the claim we are expecting.
We are thinking, as a workaround, to create a new table that contains access and refresh tokens, and a link to the user (either using the autolinkuser ID or the email and looking it up later).
Any suggestions?
is working on a reply...