In the security document for Flow it says:
You might imagine that a voter has to return an abstain vote, if it is not able to give a proper grant or deny vote.
But why is a voter not able to give a proper grand/deny??
Would be nice to know exactly why a voter has to abstain.
Because for the active roles neither grant or deny are configured for the privilege. In that case the voter abstains.
So all roles must say something about all privilage targets?
Yes, unless you want them to abstain. It's part of the concept. Abstain is a "soft" deny. If you really DENY it is denied for all times if you have that role. Abstain can be overruled by GRANT from another role
Related
Given :
a oauth client using Authorization code flow used by a website to fetch resources from an API located behind a Reverse Proxy,
some users with differents roles (admin & customer) defined in the roles part of the SCIM 2.0 User schema in Curity
a custom claim 'roles' based on the 'roles[]' field retrieve from the account-manager-claims-provider
two scopes (product_read & product_write)
How can we attached the right scope based on a given role for an unique client in Curity to get :
the product_read scope for all users with 'customer' role
the product_write scope for all users with 'admin' role
Curity docs or videos talk about custom mapper for claims, but it seems there is no example of procedure to dynamically verify which scopes must be attached to a token based on the role of an authenticated user.
I'm looking for an answer dedicated to Curity.io solution and the recommanded best practices to adapte scopes based on a given user role in a web app using RBAC, to secure the calls to the APIs during the user journey.
This type of scenario is usually managed as follows:
Scopes are application level privileges set at design time, and are requested before the user is known
Claims are identifiers with user specific values set at runtime, once the user has been identified
MULTIPLE ROLES APP DESIGN
Personally I would look to model the authorization around the mainstream use case:
Customers can buy things and look at products, and this constitutes the majority of app usage
There is an internal admin operation to update products, which is an exception
This might lead to the following API authorization code:
updateProduct(input: Product) {
if (!this.hasScope('product') || !this.hasRole('admin')) {
throw new ForbiddenError();
}
this.repository.updateProduct(input);
}
I think my personal preference for your use case would be to use the below values:
Scope: product_read
Claim: (role=customer)
You may prefer to call this scope product or product_write. It is true to say that the app has scope to a product but that exact permissions are not known until the user's claims are identified.
APP PER ROLE DESIGN
At one previous company we used to design separate apps for each persona, since the security and UX effort sometimes varied between the two cases:
The main internet app for customers, with scope=product_read
An internal UI for administrators, with scope=product_write
If this made sense for you at some future point, I think my suggested scope would translate nicely.
I was reading the Pro Spring Security book few days ago, and something was not clear to me about the access granting of UnanimousBased AccessDecisionManager. The author says:
UnanimousBased
As you probably guessed, this access decision manager will grant access to the resource only if all the
configured voters vote in favor of allowing access to the resource. If any voter votes to deny the access, the
AccessDeniedException will be thrown. The “all abstain” case is handled the same way as with the other
implementations of AccessDecisionManager.
What will happen if all of the configured voters vote to allow access, except one who votes to abstain? Will the AccessDeniedException be thrown?
Thanks in advance.
You have written answer in your question only i.e If any voter(Even if one of them) votes to deny the access, the AccessDeniedException will be thrown.
I am trying to use the Desire2Learn REST API to return semesters, but I'm getting a 403 Not Authorized error.
The request I am making is:
GET /d2l/api/lp/1.1/outypes/semester
I am making this call while authenticated to the system as a student user.
This is a test environment, so I have full control of the student user's permission, but I haven't found which permission setting controls access to the semester org unit. Is it possible for someone with lower level permissions to make this call?
What permission would this user need to be able to make this call?
Thanks!
Student-type user roles are not typically given permission to make calls like this one.
The particular permission at play here is likely Org Unit Type Editor > Can Create and Edit Org Unit Types at the root organization level (you'll notice that the same behaviour is at play around the API call to retrieve the entire catalog of known org-unit types); however, you almost certainly do not want to grant this role permission to a student role: the role permissions for this tool bind together the ability to create and edit org unit types with the ability to see their definitions.
I want to use Facebook as an authentication source for my application (a website) users. I do not want my application to have anything but basic and email permissions. Thus, my application must not be able to publish to a user's wall for example. In other words, I want to restrict the allowable set of values for the scope parameter and I want this restriction to occur on the application's configuration pages (on the Facebook site itself).
Normally this would be easy, just specify 'email' for the scope parameter of the OAuth URL/call.
However in this case there is another factor and this is: a hacker may gain access to the app and change the OAuth call to specify more permissions. Then an unsuspecting user will typically (or at least possibly) grant those permissions and the hacker will be able to grab the OAuth token and perform actions on behalf of that user.
I'm not interested in discussing the whys of this issue, just in finding of there is a way to specify that my application can only use a specific set of values for the scope parameter. Ideally this specification of the scope restriction be done in the application configuration page on Facebook itself.
However, I am interested in alternate solutions that involve using SAML, OpenID or some other authentication only mechanism (even if I cannot get the users email address). I'm not interested in using RPX.
Please note: this is a complex question not a simple one. I have searched far and wide for an answer and have just found what amounts to the opposite of this question.
I'm pretty sure it's not possible to restrict the scope at application configuration level.
I'd say the tidiest workaround would be to query the permissions of a user on signup, check that they match the allowed permissions, and subscribe to the (permissions realtime updates)[http://developers.facebook.com/docs/reference/api/realtime/]. Your app will be notified of any changes in permissions granted to users.
This should allow you to block any server side API calls through application logic, or (ban)[https://developers.facebook.com/docs/reference/api/application/#banned] a user which escalates permissions.
Let's say I have users and articles.
Anonymous can list and read articles.
Only registered and logged user can create articles.
User can edit only own articles.
And, of course, admin can do anything.
I've looked at spring security, but didn't found a way to do that. My app don't need roles, and ACL will be too "heavy" for that.
Maybe I should implement my own security?
You're right, ACL would be too much for the task.
You can use Spring Security's authorize tag in JSP, which provides access to the logged in user via the principal object. Example to limit access to editing an article to the user with a given username:
<sec:authorize access="hasRole('SOME_PRIVILEGE_OR_ROLE') and ${someArticle.username} == principal.username">
...
</sec:authorize>
Note that SOME_PRIVILEGE_OR_ROLE could be some role like 'LOGGED_IN_USER', but could also rather specify a certain privilege, e.g. 'READ_ARTICLE' or 'UPDATE_ARTICLE'. Spring Security is flexible here. Whatever you choose, it needs to be in the GrantedAuthorities collection of your user object.
Note also that you can implement your own user object, adding further info to what the UserDetails interface provides, e.g. comparing the user's id rather than the username.
Finally, note that you need a recent version of Spring Security (>=3.1) for the Spring EL to work as in the example.