Switch from custom ABAC to XACML - oauth-2.0

I'm going to secure my Spring Cloud Application with OAuth2 and XACML (using AuthZForce).
I've implemented a simple ABAC solution, that can handle the following use-case, but I want to switch to XACML. Is it possible?
old domain
I have (in database):
policies (e.g. subject.id==resource.ownerId), that are checked by the enfocement-point to make a decision
permissions (e.g. DELETE_USER), that have some defined policies
roles (e.g. EMPLOYEE), that hold some permissions
features (e.g. PREMIUM), that hold some default and by company usable roles and permissions
companies, that have some features
users, that are assigned to company
use-case
Now a user from a company can create a new role ROLE_X. He can assign some permissions to this role.
UPDATE
Because this question originally contains two different questions, I decided to outsource the second question (AuthZForce for Spring Cloud)

Where you store policies is largely irrelevant. It will depend on the engine you use e.g. AuthZForce (I've pinged the author so he can chip in), SunXACML, WSO2, or Axiomatics.
Disclaimer: I work for Axiomatics. We do use a database to store XACML policies but that does not change the authorization requirements or modelling.
I have a couple comments on your original post.
subject.id==resource.ownerId is what we typically call a condition in XACML. You compare 2 attributes together to implement a relationship.
You mention permissions e.g. DELETE_USER. In XACML you typically split those up into atomic attributes e.g. an action on the one hand and an object or resource on the other (USER). While RBAC is role- and permission-based, ABAC is attribute-based. Ideally those attributes denote a single aspect (being a user, trying to delete...)
ROLE still exists in ABAC. It will be the basis for your policies.
features and companies are attributes you would use.
With that in mind, you can write policies such as the following (using ALFA notation):
namespace axiomatics{
namespace user{
attribute role{
category = subjectCat
id = "axiomatics.user.role"
type = string
}
attribute company{
category = subjectCat
id = "axiomatics.user.company"
type = string
}
attribute userId{
category = subjectCat
id = "axiomatics.user.userId"
type = string
}
}
namespace action{
attribute actionId{
category = actionCat
id = "axiomatics.action.actionId"
type = string
}
}
namespace resource{
attribute company{
category = resourceCat
id = "axiomatics.resource.company"
type = string
}
attribute owner{
category = resourceCat
id = "axiomatics.resource.owner"
type = string
}
}
policyset springapp{
apply firstApplicable
policy employees{
target clause user.role == "employee"
apply firstApplicable
/**
* Employees can create roles in their own company
*/
rule createRole{
target clause action.actionId=="create"
condition user.company==resource.company
permit
}
/**
* Employees can delete roles they own
*/
rule allowDelete{
target clause action.actionId == "delete"
condition user.userId == resource.owner
permit
}
}
}
}

Related

Domain modeling using GORM in grails, how to represent an association

I am learning grails and I came up with a use case. In my use case, a product has many users and each user can have many roles.
Here is my product class:
class Product {
String name
String description
String vision
Date startDate
Date endDate
static hasMany = [users : User, contributors : User, watchers : User, approvers : User]
static belongsTo = User
static constraints = {
}
}
Here is my User class:
class User {
static constraints = {
}
String fullName
String email
static hasMany = [roles : Roles, products : Product]
}
Here is the Roles Enum:
public enum Roles {
PRODUCTOWNER ('ProductOwner'),
APPROVER ('Approver'),
CONTRIBUTOR ('Contributor'),
WATCHER ('Watcher')
}
My question is specifically about the association between Product and User. I want to represent the fact that a product can have many users in different roles. Also, each user can be part of multiple products with a different role in each product. Is this the right way to represent this relationship? Also, I should be able to remove and add users to products and vice versa. What this also means is that, users can keep moving between roles and can move in and out of products. In this scenario, I probably don't want cascades to happen. How do I prevent automatic cascades from happening to CRUD operations for this relationship?
Thanks.
I think rather than having roles and products in User.groovy, it will be better if you create a separate domain like UserProductRole. As you said user will have different role in different products then creating a separate domain makes more sense in business usecase and also doing queries
class UserProductRole{
Role role
static belongsTo = [user:User,product:Product]
static constraints = {
user (unique:['product','role']
}
}
You can create composite key but I generally dont perfer it because it makes querying bit difficult.
And now you need to change hasMany in User and Product like following
[userProducts:UserProductRole] rather then having users or products

Best Practices for Roles vs. Claims in ASP.NET Identity

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.

Access Groups Associated with Project Role Using Atlassian API

I am currently developing a plugin that allows project administrators to manage users in groups. I have been combing through the api reference documentation and I cannot seem to find any calls that I can make that will allow me to see the groups associated with a particular project.
I have looked through the API's at every location that is relevant to what I am searching for to no avail.
I currently have a database query that provides me what I am looking for.
SELECT ROLETYPEPARAMETER AS "Groups"
FROM projectrole PROJECT_ROLE,
projectroleactor PROJECT_ROLE_ACTOR
JOIN project PROJECT
ON PROJECT.id = PROJECT_ROLE_ACTOR.PID
JOIN cwd_group
ON group_name = roletypeparameter
WHERE PROJECT_ROLE_ACTOR.projectroleid = PROJECT_ROLE.id
AND PKEY = <projectkey>;
I would prefer to manipulate this data through the API if at all possible.
All the other pieces are available for me to complete the plugin to add, remove users from groups.
I know the information that I am looking for is available. If you navigate to the roles page you have both the users in roles, and also the groups in roles. I'm sure i'm overlooking something minor with the API to give me the groups associated with the project.
After implementing my database route, I came back to a non-database approach. This is the implementation that solves the problem.
The way the groups are implemented is as a role actor as a set underneath the project roles. One more level down you have your group names as a descriptor to the role actor.
//Create TreeMap to Store the Role-Group association. Note a role can have more than one group
TreeMap<String,Collection<String>> projectGroups = new TreeMap<String,Collection<String>>();
//Get all the project roles
Collection<ProjectRole> projectRoles = projectRoleManager.getProjectRoles();
//Iterate through each role and get the groups associated with the role
for (ProjectRole projectRole : projectRoles)
{
//Get the role actors for the project role
ProjectRoleActors roleActors = projectRoleManager.getProjectRoleActors(projectRole, project);
//Create an iterator to grab all of the groups for this project role
Iterator <RoleActor> roleActorIterator = roleActors.getRoleActors().iterator();
//Create a collection of strings to store all of the group's roles to put in the map
Collection <String> groupRoles = new ArrayList<String>();
//Iterate the role actors to get the groups
while (roleActorIterator.hasNext())
{
//Add the group by string name into collection
groupRoles.add(roleActorIterator.next().getDescriptor());
}//END While
//Add that role, and the associated groups to that role into our map.
projectGroups.put(projectRole.getName(), groupRoles);
}//END For
The output of this will look similarly to this
{Administrators=[jira-administrators], Developers=[jira-developers, jira-users], Users=[jira-users]}

Spring Security in Grails providing authorization

A suggestion here would be deeply appreciated.
We use Spring Security domain object security to lock down access to specific objects in our Grails application. We have extended permissions as well. We use normal #PreAuthorize annotation to control access to the domain objects depending up the privileges assigned to a specific user.
In this architecture, I want for one user to be able to invite a second user to join a group. To do this, the second user receives an invitation from the first user to join a group with specific privileges. The second user can choose to accept or reject the invitation.
Given that the domain object belongs to the first user, not the second user, how could I grant access to the second user to the domain object with the privileges offered?
I have tried to hack a solution using #PreAuthorize("permitAll") on a service method just to see if that would work. While not ask secure as granting an object the privilege to set privileges to a domain object, it at least would get me going. But no joy, I continue to get "accessDenied for class" errors, presumably because the current user is the second user, not the domain object owner.
Do I need to work through the SpEL suggestion here? I barely understand how the bean resolver works unfortunately.
Edit: Even when I verify the invitation is valid at invocation Spring ACL throws an exception when the first ACE for the new user is attempted to be inserted. The exception occurs in void setPermissions(ObjectIdentity oid, recipient, Collection permissions) at the insertAce call:
void setPermissions(ObjectIdentity oid, recipient, Collection permissions) {
Sid sid = createSid(recipient)
MutableAcl acl
try {
acl = aclService.readAclById(oid)
}
catch (NotFoundException e) {
acl = aclService.createAcl(oid)
}
int deleted = 0
acl.entries.eachWithIndex { AccessControlEntry ace, int i ->
if (ace.sid == sid) {
acl.deleteAce(i-deleted)
deleted++
}
}
permissions.each {
acl.insertAce(acl.entries.size(), it, sid, true)
}
aclService.updateAcl acl
}
I assume that the access is denied because the current user (who did not exist when the invitation was issued) does not have the rights to set permissions on an object owned by another user.
You can use your Role class not only for generic roles (Admin,User, etc.), but for application specific ones as well. Simply allow the user to create a Role for a resource and then allow their invitees to be granted that role. Spring Security comes with a handy ifAnyGranted() method, which accepts a comma-delimited String of role names. At a resource entry-point simply ensure that a particular role is granted:
class Conversation{
Role role
}
class ConversationController{
def enterConversation(){
// obtain conversation instance
if(!SpringSecurityUtils.ifAnyGranted(conversationInstance.role.authority){response.sendError(401)}
}
}
The answer turned out to be using RunAs. For Grails, I did this as follows:
Create a Role specific for allowing invited users to act as an administrator in order to access a protected object. In Bootstrap, ensure this role is loaded into the SecRole domain:
def invitedRole = SecRole.findByAuthority('ROLE_RUN_AS_INVITED_USER')
if (!invitedRole) {
invitedRole = new SecRole()
invitedRole.authority = "ROLE_RUN_AS_INVITED_USER"
invitedRole.save(failOnError:true, flush:true)
}
Ensure in config.groovy that the role can change the target object:grails.plugins.springsecurity.acl.authority.changeAclDetails = 'ROLE_RUN_AS_INVITED_USER'
Enable RunAs in config.groovy
grails.plugins.springsecurity.useRunAs = true
grails.plugins.springsecurity.runAs.key = [key]
annotate the service method
#PreAuthorize([check that this is indeed an invited user])
#Secured(['ROLE_USER', 'RUN_AS_INVITED_USER'])
and it all works. The trick was to make the ROLE_RUN_AS_INVITED_USER able to change acl's.
Reference:
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/runas.html
http://grails-plugins.github.io/grails-spring-security-acl/docs/manual/guide/2.%20Usage.html#2.5%20Run-As%20Authentication%20Replacement

Spring Security (Acegi) and user Groups (vs. Roles)

We're developing an app (using Grails Spring Security (formerly Acegi)) in which we'll have thousands of users that span 10-15 discreet user types. In the current system, each user type equates to a "group", and the specific roles and permissions are tied to the group. The user gets all their "roles" from the group.
For example, we might have two user groups:
CLOWN: roles = ride_clown_car, toot_horn, receive_applause
ACROBAT: roles = do_flip, walk_tightrope, receive_applause
We have three users, one assigned to the CLOWN group, one assigned to the ACROBAT group, and one assigned to both (has union of CLOWN and ACROBAT roles).
If we change permissions, we do so at the group level. For example, if we add a swing_on_trapeze permission to the ACROBAT group, all acrobats will automatically inherit it.
In Grails terms, the permissions on the controllers would still be at the role level. So an action with #Secured (['toot_horn']) would allow users in the CLOWN group but not in the ACROBAT group. #Secured (['receive_applause']) would allow both CLOWNS and ACROBATS.
How would I do this in Spring Security given the two-tiered nature of the model (user, role)? Do I need to implement my own custom authentication to collect roles based via groups?
Thanks!
You should be using the new Spring Security Core plugin since the Acegi plugin isn't being developed and is basically deprecated.
But either way, both plugins just expect that there's something like a getAuthorities() method in your user class that returns role instances. In a scenario like this where the user has many groups, just collect all of the groups' roles:
class User {
...
def getAllRoles() {
Set allRoles = []
groups.each { allRoles.addAll it.roles }
allRoles
}
}
This assumes that you have a many-to-many between User and Group:
static hasMany = [groups: Group]
and Group has a many-to-many with Role:
static hasMany = [roles: Role]
To use this set the 'relationalAuthorities' property to 'allRoles' in SecurityConfig.groovy so it uses that instead of the many-to-many between user and role:
relationalAuthorities='allRoles'
There's no configuration required for the Spring Security core plugin since it depends on an application-defined getAuthorities method already, so just use something like this in your User class:
Set<Role> getAuthorities() {
Set allRoles = []
groups.each { allRoles.addAll it.roles }
allRoles
}

Resources