Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
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 :
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.
We expect this line:
The Identity to contain the 2 claims we added. However this is not the case.
Anyone any ideas?
I 'think' you can do this:
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)
We are trying that, but on the OnExternalLogin, when we try to add a custom claim, it's complaining.
autoLinkUser.Claims.Add(new Claim("access_token", "token_goes_here"));
Because BackOfficeIdentityUser doesn't want a normal Claim, it wants an IdentityUserClaim and we don't seem to be able to generate a custom one.
So, we've tried this in the OnAutoLinking:
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.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).
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted