Role based authorization using Keycloak and .NET core - oauth

Having a few minor issues with role based authorization with dotnet core 2.2.3 and Keycloak 4.5.0.
In Keycloak, I've defined a role of 'tester' and a client role 'developer' with appropriate role mappings for an 'admin' user. After authenticating to Keycloak; if I look at the JWT in jwt.io, I can see the following:
{
"realm_access": {
"roles": [
"tester"
]
},
"resource_access": {
"template": {
"roles": [
"developer"
]
},
...
},
...
}
In .NET core, I've tried a bunch of things such as adding [Authorize(Roles = "tester")] or [Authorize(Roles = "developer")] to my controller method as well as using a policy based authorization where I check context.User.IsInRole("tester") inside my AuthorizationHandler<TRequirement> implementation.
If I set some breakpoints in the auth handler. When it gets hit, I can see the 'tester' and 'developer' roles listed as items under the context.user.Claims IEnumerable as follows.
{realm_access: {"roles":["tester"]}}
{resource_access: {"template":{"roles":["developer"]}}}
So I should be able to successfully do the authorization in the auth handler by verifying the values for realm_access and resource_access in the context.user.Claims collection, but this would require me to deserialize the claim values, which just seem to be JSON strings.
I'm thinking there has to be better way, or I'm not doing something quite right.

"AspNetCore.Authorization" expects roles in a claim (field) named "roles". And this claim must be an array of string (multivalued). You need to make some configuration on Keycloak side.
The 1st alternative:
You can change the existing role path.
Go to your Keycloak Admin Console > Client Scopes > roles > Mappers > client roles
Change "Token Claim Name" as "roles"
Multivalued: True
Add to access token: True
The 2nd alternative:
If you don't want to touch the existing path, you can create a new Mapper to show the same roles at the root as well.
Go to your Keycloak Admin Console > Client Scopes > roles > Mappers > create
Name: "root client roles" (or whatever you want)
Mapper Type: "User Client Role"
Multivalued: True
Token Claim Name: "roles"
Add to access token: True

The 4th alternative: read roles from JWT on ticket received event. Here is the the snipet:
options.Events.OnTicketReceived = ctx =>
{
List<AuthenticationToken> tokens = ctx.Properties!.GetTokens().ToList();
ClaimsIdentity claimsIdentity = (ClaimsIdentity) ctx.Principal!.Identity!;
foreach (AuthenticationToken t in tokens)
{
claimsIdentity.AddClaim(new Claim(t.Name, t.Value));
}
var access_token = claimsIdentity.FindFirst((claim) => claim.Type == "access_token")?.Value;
var handler = new JwtSecurityTokenHandler();
var jwtSecurityToken = handler.ReadJwtToken(access_token);
JObject obj = JObject.Parse(jwtSecurityToken.Claims.First(c => c.Type == "resource_access").Value);
var roleAccess = obj.GetValue("your_client_id")!.ToObject<JObject>()!.GetValue("roles");
foreach (JToken role in roleAccess!)
{
claimsIdentity.AddClaim(new Claim(ClaimTypes.Role, role.ToString()));
}
return Task.CompletedTask;
};

Related

.NET IdentityServer4 OpenIdConnect with Discord

I'm trying to cut my teeth with IdentityServer and have been following the guides on readthedocs closely. I'm at the point of adding external identity providers and have added all the ones I want to support to the IdentityServer project.
I specifically want to include "guilds" from Discord then do role based authorization in my web app based on the roles a user has on a specific Guild. Discord lists the various Scopes that are allowed:
So I've included the AspNet.Security.OAuth.Discord package and added an IdentityResource for guilds:
public static class AuthConfig
{
public static IEnumerable<IdentityResource> IdentityResources =>
new List<IdentityResource>
{
new IdentityResources.OpenId(),
new IdentityResources.Address(),
new IdentityResources.Email(),
new IdentityResources.Profile(),
new IdentityResource()
{
Name = "guilds",
DisplayName = "Discord Guilds",
Description = "All of the Discord Guilds the user belongs to",
Required = true,
Emphasize = true,
UserClaims = new[] { "name" } // <<< Not sure how I find the claims on the discord api doco
}
};
.
.
.
}
This then allows me to add scopes to my discord options in the startup of my IdentityServer project:
public void ConfigureServices(IServiceCollection services)
{
// uncomment, if you want to add an MVC-based UI
services.AddControllersWithViews();
services.AddAuthentication()
.AddDiscord("Discord", options =>
{
options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
options.ClientId = "<my client id>";
options.ClientSecret = "<my client secret>";
options.Scope.Add("guilds");
})
When I login the uri has the guild scope added and I get the warning on the acknowlegement dialog:
But when I view the content of my claims I don't see anything.
If I add a standard oidc one of email that does display though.
If I follow through to the definition of IdentityResources.Email then I see these claims defined on the ScopeToClaimsMapping property in IdentityServer4.Constants
but I'm not sure how to determine what these claims should be for the Discord guilds scope...and is this even the issue anyway.
Can anyone point me in the right direction?
Claims and Scopes are different but related things.
An scope is a claim, it talks about the scope of your access.
When you request the "guild" scope, it means your token will be able to access the information under that scope. But that doesn't necessarily mean that information is going to be presented in a claim on the token or user_info response.
Instead, what you need to do to get the "guilds" information is to consume their API, using the token.
Discord Developer Portal - Guilds
Get Current User Guilds
GET /users/#me/guilds
Returns a list of partial guild objects the current user is a member of.
Requires the guilds OAuth2 scope.

Initiate and store multiple OAuth2 external authentication challenges in a ASP.NET Core MVC application?

I can authenticate against two separate OAuth authentication schemes but it seems only one can be active at a time. I'd like to compare data from two separate SaaS applications and therefore I need two separate Bearer tokens. How can I initiate multiple OAuth challenges when the user loads the application and then store the Bearer Tokens for each? (e.g. in the Context.User cookie?)
My Startup.cs is as follows:
public void ConfigureServices(IServiceCollection services)
{
services.AddRouting();
services.AddAuthentication(options =>
{
options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddCookie(options =>
{
options.LoginPath = "/signin";
options.LogoutPath = "/signout";
})
.AddScheme1 (options =>
{
options.ClientId = Configuration["Scheme1:ClientId"];
options.ClientSecret = Configuration["Scheme1:ClientSecret"];
options.Scope.Add("scope1");
options.SaveTokens = true;
})
.AddScheme2(options =>
{
options.ClientId = Configuration["Scheme2:ClientId"];
options.ClientSecret = Configuration["Scheme2:ClientSecret"];
options.Scope.Add("scope1");
options.SaveTokens = true;
});...
}
The AuthenticationController calls the Challenge overloaded method from the Microsoft.AspNetCore.Mvc.Core assembly that takes a single provider/scheme (passing multiple schemes in the overloaded method seems to be ignored).
[HttpGet("~/signin")]
public async Task<IActionResult> SignIn() => View("SignIn", await HttpContext.GetExternalProvidersAsync());
[HttpPost("~/signin")]
public async Task<IActionResult> SignIn([FromForm] string provider)
{
...
return Challenge(new AuthenticationProperties { RedirectUri = "/" }, provider);
}
Presumably, you'd prompt the user to sign-into one external application, redirect back to the home page, and then prompt them to sign-into the second one, and then allow them to start using the application proper.
If this is possible - e.g. using a "multiple" Auth cookie - how then would I fetch the correct Bearer token and User values for the given scheme? Currently you just seem to fetch the token with a generic "access_token" name and unique user values:
string accessToken = await HttpContext.GetTokenAsync("access_token");
string userID = User.FindFirstValue(ClaimTypes.NameIdentifier);
There does seem to be some information here regarding using a SignInManager but I'm unable to determine if this is applicable to this problem.
I would aim to start with a standard architecture where the user authenticates with the one and only app, and gets only one set of tokens, issued by your own Authorization Server.
SaaS DATA - OPTION 1
Does the user need to get involved in these connections or can you use a back end to back end flow here?
Your C# code could connect to the SaaS provider with the client credentials grant, using the client ID and secret that you reference above. Provider tokens would then be cached in memory, then used by the back end code to return provider data to the UI. This is a simple option to code.
SaaS DATA - OPTION 2
If the user needs to get involved, because the data is owned by them, you might offer UI options like this. After each click the user is redirected again, to get a token for that provider.
View provider 1 data
View provider 2 data
Aim to emulate the embedded token pattern, where the provider tokens are available as a secondary credential. How you represent this could vary, eg you might prefer to store provider tokens in an encrypted cookie.
CODING AND SIMPLICITY
I would not mix up provider tokens with the primary OAuth mechanism of signing into the app and getting tokens via the .NET security framework, which typically implements OpenID Connect. Instead I would aim to code the SaaS connections on demand.
I think you will find it easier to code the SaaS connections with a library approach, such as Identity Model. This will also help you to deal with SaaS provider differences more easily.
I assume you use OIDC schemes.
First, you need to add two cookie schemes, one for each OIDC authentication scheme as their sign in scheme and set their callback path to different values to stop them competing:
services.AddAuthentication()
.AddCookie("Cookie1")
.AddCookie("Cookie2")
.AddOpenIdConnect("OidcScheme1", opt =>
{
opt.SignInScheme = "Cookie1";
opt.CallbackPath = "/signin-oidc-scheme1";
opt.SaveTokens = true;
})
.AddOpenIdConnect("OidcScheme2", opt =>
{
opt.SignInScheme = "Cookie2";
opt.CallbackPath = "/signin-oidc-scheme2";
opt.SaveTokens = true;
});
This will instruct the OIDC handler to authenticate the user from corresponding cookie.
Second, you need a controller action to challenge the user against each OIDC scheme:
[HttpGet]
[Route("login")]
[AllowAnonymous]
public IActionResult Login([FromQuery]string scheme,
[FromQuery]string? returnUrl)
{
return Challenge(new AuthenticationProperties
{
RedirectUri = returnUrl ?? "/"
}, scheme);
}
From your web app, you need to send the user to the Login endpoint twice with different scheme values:
GET /login?scheme=OidcScheme1
GET /login?scheme=OidcScheme2
Or chain them together using the returnUrl:
GET /login?scheme=OidcScheme1&returnUrl=%2Flogin%3Fscheme%3DOidcScheme2
Once signed in, there should be two cookies in the browser window, for example:
To authenticate the user and restore both identities from two cookies, you can use authorization policy:
[HttpGet]
[Authorize(AuthenticationSchemes = "OidcScheme1,OidcScheme2")]
public async Task<IActionResult> SomeOperation()
{
// Two identities, one from each cookie
var userIdentities = User.Identities;
...
}
To get access token from each authentication scheme, use the method you discovered (GetTokenAsync) and specify authentication scheme:
var token1 = await HttpContext.GetTokenAsync("OidcScheme1", "access_token");
var token2 = await HttpContext.GetTokenAsync("OidcScheme2", "access_token");
It is possible that the access token is not returned from the token endpoint depends on the response_type you used. If this is the case, try set the OpenIdConnectionOptions.ResponseType to OpenIdConnectResponseType.Code and make sure the scope is correct.
I encountered a similar problem where we had microservices that are/were shared across multiple products with each product having a separate IDP tenant (essentially a different token issuer). Perhaps a similar approach might work for your scenario...
The following link helped me with a solution - see here.
Basically I defined a smart authentication scheme
var builder = services.AddAuthentication(o =>
{
o.DefaultAuthenticateScheme = "smart";
//...
});
Then in the smart policy scheme definition, I decode the JWT coming in to work out the issuer from the iss claim in the JWT, so that I can forward to the correct location for JWT bearer authentication.
builder.AddPolicyScheme("smart", "smart", options =>
{
options.ForwardDefaultSelector = context =>
{
var jwtEncodedString = context.Request.Headers["Authorization"].FirstOrDefault()?.Substring(7);
if (string.IsNullOrEmpty(jwtEncodedString))
return settings.Tenants.First().Key; // There's no authorization header, so just return any.
var token = new JwtSecurityToken(jwtEncodedString: jwtEncodedString);
var issuer = token.Claims.First(c => c.Type == "iss").Value?.TrimEnd('/');
var tenant = settings.Tenants
.Where(pair => pair.Value.Issuer.TrimEnd('/') == issuer)
.Select(pair => pair.Key).FirstOrDefault();
if (tenant == null)
throw new AuthorizationException($"Failed to locate authorization tenant with issuer '{issuer}'.");
return tenant;
};
});
Note: settings.Tenants is just an array of whitelisted tenants (from appsettings) that I configure as follows:
foreach (var tenant in settings.Tenants)
builder.AddJwtBearer(tenant.Key, options => Configure(options, tenant.Value, defaultJwtBearerEvents));

How client application uses the scopes and resources extracted from access token to restrict the access of API - identityserver4

I can see many links describing how to use identityserver4.
Host application:
Configuring clients with [clientId, secret, APIScopes, APIResources, IdentityResources]
Passing clients details to identityserver4
Client Application:
Passing client id to the endpoint to get access token and refresh token that contains scopes and resources of the defined clients. using that scope and resources we can restrict the access of the API's.
But I am still wondering how the client application will use the API scopes to restrict the access of the Application is there any sample how to utilize the scopes to restrict the application access?
And also approach for maintaining roles in identitserver4
I don't find any links describing how to use the client part after getting access token, please share me any reference that can help me?
In a API (AddJwtBearer), you do two things, authentication and authorization.
In the authorization stage, you check the claims (the scopes is part of the claims) found in the access token.
Can do the authorization check using the role or policy based approach.
A sample policy can look like this:
public void ConfigureServices(IServiceCollection services)
{
services.AddAuthorization(options =>
{
options.AddPolicy("ViewReports", policy =>
policy.RequireAuthenticatedUser()
.RequireRole("Finance")
.RequireRole("Management")
);
});
then you can decorate your controllers with this attribute:
[Authorize("ViewReports")]
public class SecretController : Controller
{
}
From a consumer (API) point of view, the scopes are just like all the other claims. they are not treated differently.
When using identityserver4, client needs to configure the ClientId and the authority address, this server need to configure the allowed scope corresponding to clientid.
services.AddAuthentication(config=>
{
config.DefaultScheme = "cookie";
config.DefaultChallengeScheme = "oidc";
})
.AddCookie("cookie")
.AddOpenIdConnect("oidc", config=>
{
config.Authority = "url";
config.ClientId = "client_id";
config.ClientSecret = "client_secret";
config.SaveTokens = true;
config.ResponseType = "code";
});
The Identityserver will authorize some functions according to the ClientId.
new Client
{
ClientId="client_id",
ClientSecrets=
{
new Secret("client_secret".ToSha256())
},
AllowedGrantTypes=GrantTypes.Code,
RedirectUris={ "https://localhost:[port]/signin-oidc"},
AllowedScopes={ "apione", "apitwo",
IdentityServerConstants.StandardScopes.OpenId,
IdentityServerConstants.StandardScopes.Profile,
//...
},
RequireConsent=false
}
In apione, you still need to configure the audience.
services.AddAuthentication("jwtauth")
.AddJwtBearer("jwtauth",config=>
{
config.Authority = "identityserver url";
config.Audience = "apione";
config.RequireHttpsMetadata = false;
IdentityModelEventSource.ShowPII = true;
});
Every user has their own role, so you can add the claims after the user logs in on the server. In addition, the project api can configure the AddAuthorization as Tore Nestenius says.

Create different JWT authoriser in Auth0 and attach permissions based on the permitted roles

There are three kinds of users in my Auth0 tenant:
Regular user (no role)
Moderator user (assigned "Mod" role)
Admin user (assigned "Admin" role)
I created an API in Auth0 and attached to the endpoints via JWT authoriser in the new AWS API Gateway HTTP API.
There is business logic that some endpoints allows only allows regular user and admin, and some allow Mod and Admin. E.g.:
Endpoint 1: Allow regular user and Admin
Endpoint 2: Allow Mod and Admin
Endpoint 3: Allows Mod only
Currently, the authoriser allows any user in the user's database in Auth0, and I check the user's identity within the application via several Auth0's management API:
/userInfo to make sure the token matches with the :user_id.
/oauth/token to get Auth0 management API access token.
/api/v2/users/:user_id to get the user profile.
/api/v2/users/:user_id/roles to get the role.
I believe there should have a better way to handle the identity check. Is it possible to create multiple authoriser with a different role/permission scope (e.g. allow regular user and admin) and attach to the related endpoint accordingly?
I realised there is a claims object in event.requestContext.authorizer.claims from Lambda according to the AWS API Gateway Doc.
Therefore, the extra /userInfo call is unnecessary.
I added 2 Auth0 rules to merge the user role to user.app_metadata and the claims object.
Code sample for #2:
function assignRoleToAppMetadata (user, context, callback) {
const ManagementClient = require('auth0#2.19.0').ManagementClient
const management = new ManagementClient({
domain: '{YOUR_ACCOUNT}.auth0.com',
clientId: '{YOUR_NON_INTERACTIVE_CLIENT_ID}',
clientSecret: '{YOUR_NON_INTERACTIVE_CLIENT_SECRET}'
})
const params = { id: user.user_id }
management.getUserRoles(params)
.then(roles => {
user.app_metadata = user.app_metadata || {}
user.app_metadata.roles = roles
return auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
})
.then(() => callback(null, user, context))
.catch(err => {
console.error(err.message)
callback(null, user, context)
})
}
In addition, the following rule attached the role info to /userInfo:
function(user, context, callback) {
const namespace = 'https://{YOUR_ACCOUNT}.auth0.com/'
context.idToken[namespace + 'roles'] = user.app_metadata.roles
callback(null, user, context)
}

MVC: Using User.IsInRole("") after signin into AAD

So the users authenticate using AAD, but I need to get the role they have been allocated in the Database.
I have tried adding this to my openIdConnectAuthenticationOptions in my Startup.Auth as suggested in some posts:
TokenValidationParameters = new TokenValidationParameters()
{
ValidateIssuer = false, // Simplification (see note below)
//RoleClaimType = System.Security.Claims.ClaimTypes.Role
RoleClaimType = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
}
But no role is displayed when I check the claims while debugging. I assume this is because there is no login happening as it would when using SignInManager, so I tried doing an actual sign in after AAD authenticated successfully, as I have the user Id from the DB:
var user = db.Users.Where(x => x.Id == loggedInUserId).FirstOrDefault();
var userForIdentity = UserManager.FindById(user.Id);
if (user != null)
{
await SignInManager.SignInAsync(user, true, true);
}
I thought that if I do the above after the AAD signin, that the role would be added to allow me to make use of User.IsInRole("Administrator") for example, but it doesnt seem to add it.
I have seen some posts that say that we can edit the manifest in Azure AD on the app that was registered, but I dont have access to the clients AAD.
My question is, is there a way to make use of User.IsInRole("") based on what is in the DB after AAD sign in ?
Thanks for any help.

Resources