i am reading the identityserver4 guildence, here is the example code
UserClaims =
{
new UserClaim(JwtClaimTypes.Name),
new UserClaim(JwtClaimTypes.Email)
},
// this API defines two scopes
Scopes =
{
new Scope()
{
Name = "api2.full_access",
DisplayName = "Full access to API 2",
},
new Scope
{
Name = "api2.read_only",
DisplayName = "Read only access to API 2"
}
}
my questions is
seems the scope is used to control which client can access the api resources, and user claims controler the user permission on apis. let's take a look at "api2.read_only", does this mean client with this scope can only have the read access to the apis? but what if the user has for example: write access for a speicific api? i get confuse about the these two.
thanks in advance for your help.
Scopes defines whether you have access to the API or not. Where as Claims are more granular. Within the API, what resource you can access? for example, you can access identity resource like name.
Scopes are special claims which define what resources a client can have access to.
User claims are just assertions about a user. You would normally give a user a "role" or "permission" claim (or something like that). By using the user claims you can do some claims authorization if doing authorization based on scopes does not satisfy your requirements.
Related
I first set my application base on Auth0, with roles and permissions setup. Result user are linked with x roles, and Auth0 inject to the token claim an array of linked permissions. Now my app need to become also compatible to use KeyCloak.
How to inject into the token the permissions array, like with Auth0?
To match same beaver of Auth0, on keycloak all the auth0-roles are set as group. And all auth0-permission as roles.
Now to allow to inject into the token the related roles of groups linked with a user, I created a Script Mapper in the client like this:
var ArrayList = Java.type("java.util.ArrayList");
var permissions = new ArrayList();
user.getGroups().forEach(function(groupModel) {
groupModel.getRoleMappings().forEach(function(roleModel) {
var roleName = roleModel.getName();
if(!permissions.contains(roleName)) {
permissions.add(roleName);
}
});
});
token.setOtherClaims("permissions", permissions);
Take me time to find the best way to make it working. But if you know a better solution. Thank you for sharing ;-)
One thing related to OAuth 2.0 and JWTs that's still a bit confusing is when to use scopes vs. roles.
I think some of the confusion is coming from how role-based authorization works in ASP.NET Core (which is the primary language/framework at my workplace). For example; if I have roles in my JWT as follows
{
"aud": "test",
"iss": "http://localhost:8080/auth/realms/test/",
"iat": 1585192274,
"nbf": 1585192274,
"exp": 1585196174,
"sub": "12345",
"roles": ["Admin", "SuperUser"]
}
I can protect routes quite easily without having to do much e.g:
[ApiController]
[Route("api/v{version:apiVersion}/template/test")]
public class TestController : Controller
{
[HttpGet]
[Authorize(Roles = "Admin")]
public IActionResult Get()
{
return Ok("test");
}
}
I could implement something very similar to the above using scopes with dotnet authorization policies, but I'd just like to know if there's some guidance about if/when to use scope or roles, or is it simply a matter of preference...
I can't find much reference to the roles claim in any of the OAuth/JWT-related RFCs, whereas scopes are mentioned throughout.
The most significant difference between scopes and roles/groups is who determines what the client is allowed to do.
Resource scopes are granted by the resource owner (the user) to an application through the consent screen. For example, the client application can post to my timeline or see my friends list.
User roles and groups are assigned by an administrator of the Azure AD directory. For example, the user can submit expense reports or the user can approve expense reports.
Scopes are typically used when an external application wants to gain access to the user's data via an exposed API. They determine what the client application can do.
Role- or group based access is typically used within an application to determine what a user can do.
I need to store a unique identifier for a user in an SQL database. My application uses OpenID Connect via OWIN to authenticate users against Azure AD and is based on the MVC 5 Framework. I can access the ObjectId of the user via the http://schemas.microsoft.com/identity/claims/objectidentifier claim. The only way I know how to obtain the claims is with a delegate added to the "Notifications" property of "OpenIdConnectAuthenticationOptions". As this is part of the application startup the delegate has no way of passing this information on to a session.
I have seen answers to questions with similar goals that recommend using the Graph API to match the User.Identity.Name with the ObjectId. I would rather avoid doing this as my application is resource hungry enough as it is.
Here is what I have so far. I just need to get the claim into a Session, or access the claims from a Session. (This doesn't always work, for example if the user is already logged in, but it's the best I have so far)
Notifications = new OpenIdConnectAuthenticationNotifications
{
AuthorizationCodeReceived = (context) =>
{
IEnumerable<Claim> claims = context.AuthenticationTicket.Identity.Claims;
Claim objectId = claims.First(claim => claim.Type == "http://schemas.microsoft.com/identity/claims/objectidentifier");
// ???
return Task.FromResult(0);
}
},
I think I've answered my own question. This works nicely.
ClaimsIdentity identity = User.Identity as ClaimsIdentity;
Guid objectId = new Guid(identity.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value);
Guid tenantId = new Guid(identity.FindFirst("http://schemas.microsoft.com/identity/claims/tenantid").Value);
I am completely new to the use of claims in ASP.NETIdentity and want to get an idea of best practices in the use of Roles and/or Claims.
After all this reading, I still have questions like...
Q: Do we no longer use Roles?
Q: If so, why are Roles still offered?
Q: Should we only use Claims?
Q: Should we use Roles & Claims together?
My initial thought is that we "should" use them together. I see Claims as sub-categories to the Roles they support.
FOR EXAMPLE:
Role: Accounting
Claims: CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger
Q: Are they intended to be mutually exclusive?
Q: Or is it better to go Claims ONLY and "fully-qualify" you claims?
Q: So what are the best practices here?
EXAMPLE: Using Roles & Claims Together
Of course, you would have to write your own Attribute logic for this...
[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
// Do stuff here
return View();
}
EXAMPLE: Fully-Qualifying Your Claims
[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
// Do stuff here
return View();
}
A role is a symbolic category that collects together users who share the same levels of security privileges. Role-based authorization requires first identifying the user, then ascertaining the roles to which the user is assigned, and finally comparing those roles to the roles that are authorized to access a resource.
In contrast, a claim is not group based, rather it is identity based.
from Microsoft documentation:
When an identity is created it may be assigned one or more claims issued by a trusted party. A claim is a name value pair that represents what the subject is, not what the subject can do.
A security check can later determine the right to access a resource based on the value of one or more claims.
You can use both in concert, or use one type in some situations and the other in other situations. It mostly depends on the inter-operation with other systems and your management strategy. For example, it might be easier for a manager to manage a list of users assigned to a role than it is to manage who has a specific Claim assigned. Claims can be very useful in a RESTful scenario where you can assign a claim to a client, and the client can then present the claim for authorization rather than passing the Username and Password for every request.
As #Claies perfectly explained, claims could be a more descriptive and is a deep kind of role. I think about them as your role's ids. I have a gym Id, so I belong to the members role. I am also in the kickboxing lessons, so I have a kickboxing Id claim for them. My application would need the declaration of a new role to fit my membership rights. Instead, I have ids for each group class that I belong to, instead of lots of new membership types. That is why claims fit better for me.
There is a a great explanation video of Barry Dorrans, talking about the advantage of using claims over roles. He also states that roles, are still in .NET for backward compatibility. The video is very informative about the way claims, roles, policies, authorization and authentication works.
Or check a related session shared by Lafi
Having used various authentication and authorisation techniques over decades, my current MVC application uses the following methodology.
Claims are used for all authorisation. Users are assigned one role (multiple roles are possible but I do not need this) - more below.
As is common practice, A ClaimsAuthorize attribute class is used. Since most controller actions are CRUD, I have a routine in the code-first database generation that iterates all controller actions and creates claim types for each controller action attribute of Read/Edit/Create/Delete. E.g. from,
[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]
For use at in an MVC View, a base controller class presents view bag items
protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
// get user claims
var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;
if (user != null)
{
// Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();
// set Viewbag with default authorisations on this controller
ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
}
base.OnActionExecuting(filterContext);
}
For website menus and other non-controller actions, I have other claims. E.g. whether a user can view a particular monetary field.
bool UserHasSpecificClaim(string claimType, string claimValue)
{
// get user claims
var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;
if (user != null)
{
// Get the specific claim if any
return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
}
return false;
}
public bool UserHasTradePricesReadClaim
{
get
{
return UserHasSpecificClaim("TradePrices", "Read");
}
}
So where do Roles fit in?
I have a table that links a Role to a (default) set of claims. When setting user authorisation, the default is to give the user the claims of their role. Each user can have more or less claims than the default. To make editing simple, the claims list is show by controller and actions (in a row), with other claims then listed. Buttons are used with a bit of Javascript to select a set of actions to minimise the "clicking" required to select claims. On Save, the users claims are deleted and all of the selected claims are added. The web application loads claims only once, so any changes must prompt a reload within this static data.
Managers can therefore select which claims are in each role and which claims a user has after setting them to a role and those default claims. The system has only a small number of users so managing this data is straightforward
To understand the difference between Roles and Claims you must face the limitation of roles and feel how claims come over these issues, so let me give you 2 scenarios to recognize the power of claims where role can't resolve these issues :
1- Your site has two modules (pages, service ..etc) the first module for children (under 18 years old) the other for adults (over 18 years old)
your user identity has a birthday claim
You need to create a policy on this claim so the authorization for each module will be given on this value and if the age of the user is over 18 years then he can go to the adult module and not before this age.
Role is Boolean data type you can have or not have the role, it doesn't have multi values.
2- Your site has role user and you want to prevent access of users to make some maintenance without changing the code.
In claims, you can create an UnderConstrain policy that if true the user can't view the page give property authorize for role user.
At the time of writing this answer we were at '.NET 5.0' with '.NET 6.0' just around the corner. And this is my understanding of what I've seen:
Q: Do we no longer use Roles?
Yep, you're not supposed to use Roles any longer (at least not the way you did it in the previous frameworks.
Q: If so, why are Roles still offered?
To make upgrading projects easier/faster?
Q: Should we only use Claims?
yes. But be sure to check out the video posted here in the answer by #Jonathan Ramos.
Q: Should we use Roles & Claims together?
No, but you can put a role into a claim ofcourse, but be sure to upgrade your project to use Claims only.
And you should not have to write you're own attributes, you should use policy for that, as it's the way of the newer framework. If you need you're own attributes you're "doing it wrong", just create your own Requirement(handler) that's what the whole 'new' policy is all about.
In the current framework the attribute ClaimAuthorize is not even available anymore.
In my application I have a top level entity called Organization. The relationship between User and Organization is many-to-many.
Because of this I could have the following scenario:
UserA has role ROLE_ADMIN for OrganizationA
UserA has role ROLE_USER for OrganizationB
I need to ensure that when UserA accesses resources for OrganizationB he is not doing it as an ADMIN. So I need an additional check that the user has the correct roles at the organization level. Is there anything built into Spring Security that allows for this? If not, does anyone know what the best way would be to about solving this?
UPDATE: A bit more information...
A User logs in and chooses which org they want to work with. That is stored in the session. Beyond that, URLs are locked down with the Secured annotation. What that means is that if UserA were to log in and select OrgA, they should be able to access /admin/user/create however, if they log in and choose OrgB they should not have access to that URL.
The long way is to add additional checks in every method where this matters. So call some service method that says "ok, you're an admin for OrgA but not for OrgB and you're logged in using OrgB, so deny this request".
I'm hoping for a more grails / spring-security way of handling this.
You can probably do this by using a custom AccessDecisionVoter. The vote method will supply you with the "configuration attributes" for the resource (method or URL), which will typically be the required roles, and you can obtain the current user's roles/authorities either directly from the Authentication object, or by reading the current org and selecting the appropriate roles for the user.
I'm assuming that you have some way of differentiating the user's roles, based on the org they've selected.
Essentially, you'd be writing an extended version of the standard RoleVoter, which takes the organization into account.
I think I'm little late here but this is what worked for me:
When an organization is selected, you can set a new Authentication object with new roles in your session(The previous Authentication object gets invalidated). Something like this:
#RequestMapping(value = "/org-a")
String orgA(HttpServletRequest request) {
request.getSession().setAttribute("org", "org-a")
Organization org = new Organization("org-a")
reloadRolesForAuthenticatedUser(org)
....
}
private void reloadRolesForAuthenticatedUser(Organization org) {
Authentication auth = SecurityContextHolder.getContext().getAuthentication()
List<String> newRoles = getRoles(auth.getPrincipal().getUsername(), org)
List<GrantedAuthority> authorities = getAuthorities(newRoles)
Authentication newAuth = new UsernamePasswordAuthenticationToken(auth.getPrincipal(),auth.getCredentials(),authorities)
SecurityContextHolder.getContext().setAuthentication(newAuth)
}
private List<GrantedAuthority> getAuthorities(List<String> roles) {
List<GrantedAuthority> auths = new ArrayList<GrantedAuthority>()
if (!roles.isEmpty()) {
for (String r : roles) {
auths.add(new SimpleGrantedAuthority(r))
}
}
return auths
}