PROBLEM: The suggested method by Lee Brandt see: https://developer.okta.com/blog/2018/04/18/authorization-in-your-aspnet-mvc-4-application was not working due to notifications not being invoked. After a number of days researching and attempting various options, I came up with following solution.
CodePudding user response:
SOLUTION
Setup OKTA using procedure in Lee's article.
In Startup.cd, instead of using 'UseOpenIdConnectAuthentication' use:
app.UseCookieAuthentication(...);
app.Use(async (context, next) =>
{
var claims = new List<Claim>();
if (context.Authentication.User.Identity.IsAuthenticated)
{
foreach (var group in ((ClaimsIdentity)context.Authentication.User.Identity).Claims.Where(x => x.Type == "Groups"))
{
claims.Add(new Claim(ClaimTypes.Role, group.Value));
}
}
var identity = new ClaimsIdentity(context.Authentication.User.Identity);
identity.AddClaims(claims);
var identities = new List<ClaimsIdentity>
{
identity
};
context.Authentication.User.AddIdentities(identities);
await next.Invoke();
});
app.UseOktaMvc(...**
The OKTA Groups claims are added as Role claims allowing the controller authorize attributes to be utilized.
Any suggestions or problems?
CodePudding user response:
BEHAVIOUR
It may be OK, though the standard behavior is all built around creating or restoring a useful ClaimsPrincipal. The Microsoft code does this:
When there is no auth cookie, do the OIDC redirect to sign the user in, to eventually get tokens
Create a ClaimsPrincipal from the ID token, then serialize tokens to an encrypted HTTP only cookie
On all subsequent requests, the stack just deserializes the ClaimsPrincipal from the ID token in the cookie
Occasionally a token refresh may occur, which also rewrites the cookie, to store new tokens
CLAIMS PRINCIPAL CUSTOMIZATION
AddOpenIDConnect
has an options object with a property called TokenValidationParameters
. This has a RoleClaimType
which could be set to Groups
in your case.
It is recommended to customize claims programmatically when tokens are first received, so your custom code is fine - though it should only run when there is no auth cookie yet.
There has always been an action such as OnTokenValidated for customizing the ClaimsPrincipal. I first used this in around 2014 with the .Net framework and it has not really changed since. It occurs after the ID token is validated and before the ClaimsPrincipal is finalized. Ideally put your code here.