I am adding users to my ca-server's config file. I want to know what are the differences between roles, affiliations and attributes?
In tutorials I can see that roles is assigned to one of these: "client,user,peer,validator,auditor,ca". I want to know can be use some other role? If a user is assigned "client" role then can he have a validating role running with that identity. What's the difference between "client" and "user"? What's the difference between "peer" and "validator"? And also what is auditor specifically.
I think affiliations are used to categorize identities. Is that right?
Identity type can be any arbitrary string as far as Fabric CA is concerned.
I think of affiliations as hierarchical tags. Each identity can be tagged (affiliated) to (with) one affiliation in the hierarchy. When an identity is associated with an affiliation, it is affiliated with that and all the child affiliations.
1) Affiliations are currently used during registration and revocation. You can read more about registration/revocation at https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html
Attributes are key-value pairs that can be associated with an identity. hf.Registrar.Roles, hf.Registrar.DelegateRoles, hf.Revoker, and hf.IntermediateCA are currently in use with in Fabric CA server. These are used to make access control decisions. Currently attributes are not used in any other Fabric components, afaik.
For example, if an identity with “hf.Registrar.Roles” attribute set to “peer,app,user” and affiliated to org1.dept1, can register identities of type peer, app, and user, (but not orderer) that are affiliated with org1.dept1 (but not identities affiliated with org1 or org1.dept2)
I hope this is helps
Related
I am trying to use the AWS SSO SCIM API in order to retrieve the AWS SSO groups for a particular user.
Looking at the documentation https://docs.aws.amazon.com/singlesignon/latest/developerguide/listgroups.html
It mentions the following
To see group info for a certain member, call ListGroup with a member filter
If you're using the member filter, you have to use the id filter (refer to supported filter combinations).
It appears that the id filter, is the group ID, because of this note: Note that the use of id as an individual filter, while valid, should be avoided as there is already a getGroup endpoint available.
Also, at https://docs.aws.amazon.com/singlesignon/latest/developerguide/limitations.html next to the members attribute it mentions that it is supported, but cannot be read in a response.
I have been playing with the API but could not get any group info for a user regardless of the combination of the parameters.
Based on the above, I conclude that the API does not support retrieving group data for a user. Would you agree?
I don't have access to an AWS SSO SCIM endpoint, but from looking at the documentation I suspect one of the two approaches may be possible:
GET /users/id and look at the value for "groups" - this one seems questionable as the limitations page says they support the user resource's "groups" attribute, but there's also a note about not supporting multi-valued user attributes. You may need to explicitly add the ?attributes=groups parameter to your GET to ask for that attribute to be returned, if it is in fact supported.
GET /groups?filter=members[value eq "userId"] or some variation of that depending on what syntax they allow. This isn't listed as supported, but if it works, I expect that you would get a list of groups in response that did not contain the "members" attribute - but that each group returned would match the query.
There's some amount of uncertainty with both of these, but with the information available those seem like the two most likely paths to successfully accomplish what you are aiming for. If neither of those work, it may not be possible - but a support case with AWS would probably be helpful to confirm there.
As #ZollnerdMSFT recommended, I raised an AWS support request. AWS support responded that the AWS SSO SCIM API does not support retrieving the groups associated with a user. They have submitted this as a feature request internally, however, cannot provide an estimate as to when it will be implemented.
I have an AWS Amplify application that has a structure with multi-organizations:
Organization A -> Content of Organization A
Organization B -> Content of Organization B
Let's say we have the user Alice, Alice belongs to both organizations, however, she has different roles in each one, on organization A Alice is an administrator and has more privileges (i.e: can delete content or modify other's content), while on Organization B she is a regular user.
For this reason I cannot simply set regular groups on Amplify (Cognito), because some users, like Alice, can belong to different groups on different organizations.
One solution that I thought was having a group for each combination of organization and role.
i.e: OrganizationA__ADMIN, OrganizationB__USER, etc
So I could restrict the access on the schema using a group auth directive on the Content model:
{allow: group, groupsField: "group", operations: [update]},
The content would have a group field with a value: OrganizationA__ADMIN
Then I could add the user to the group using the Admin Queries API
However, it doesn't seem to be possible to add a user to a group dynamically, I'd have to manually create each group every time a new organization is created, which pretty much kills my idea.
Any other idea on how I can achieve the result I'm aiming for?
I know that I can add the restriction on code, but this is less safe, and I'd rather to have this constraint on the database layer.
Look into generating additional claims in you pre-token-generation handler
Basically you can create an attribute that includes organization role mapping
e.g.
{
// ...
"custom:orgmapping": "OrgA:User,OrgB:Admin"
}
then transform them in your pre-token-generation handler into "pseudo" groups that don't actually exist in the pool.
I'm attempting to use the LDAPAuthenticator class found here to configure JupyterHub on EMR.
I'm querying ActiveDirectory through LDAP to get the authorized users, which are members of a specific AD group.
Problem I'm running into is that with this specific implementation, it expects the user objects to have a few specific user attributes that the objects don't have as of now and I'm not allowed to change them.
The ideal workflow would be, LDAPSEARCH queries ActiveDirectory for a specific AD group, and on return it creates users for the members of that AD group, it should create linux users and directories for the users.
I'd like to know if anyone else has run into this sort of issue and overcome, thanks!
If you get stuck in the same place, I ended up using this:
https://github.com/hansohn/jupyterhub-ldap-authenticator
and it work as expected.
I'm developing a huge application in django and I need a permission system and I assume that the native user/group permission within django is not sufficient. Here my needs:
The application will be available through multiple departments. In each department there will be nearly the same actions. But maybe an user will be allowed to add a new team member in department A and in department B he is only allowed to view the team list and in the other departments he has no access at all.
I though using a RBAC system would be most appropriate. Roles must also be inheritable, stored in a model an managable through an interface. Any good ideas or suggestions? Regards
What you are looking for is called abac aka Attribute-Based Access Control. It's an evolution of RBAC as an access control model. In RBAC, you define access control in terms of roles, groups, and potentially permissions. You then have to write code within your application to make sense of the roles and groups. This is called identity-centric access control.
In ABAC, there are 2 new elements:
attributes which are a generalization of groups and roles. Attributes are a key-value pair that can describe anyone and anything. For instance, department, member, and action are all attributes.
policies tie attributes together to determine whether access should be granted or denied. Policies are a human-friendly way of expressing authorization. Rather than write custom code in your app, you write a policy that can be centrally managed and reused across apps, databases and APIs.
There are a couple of ABAC languages such as xacml and alfa. Using ALFA, I could write the following policy:
A user will be allowed to add a new team member in department A
In department B he is only allowed to view the team list
In the other departments he has no access at all.
Roles must also be inheritable, stored in a model an managable through an interface.
policyset appAccess{
apply firstApplicable
policy members{
target clause object = "member"
apply firstApplicable
/**
* A user can add a member to a department if they are a manager and if they are assigned to that department.
*/
rule addMember{
target clause role == "manager" and action == "add"
permit
condition user.department == target.department
}
}
}
One of the key benefits of ABAC is that you can develop as many policies as you like, audit them, share them, and not have to touch your application code at all because you end up externalizing authorization.
There are several engines / projects that implement ABAC such as:
AuthZForce (a Java library for XACML authorization)
Axiomatics Policy Server (commercial product - disclaimer: I work there)
AT&T XACML
There are two components to this question:
First, role management. Roles can be achieved through group membership, i.e. departmentA_addMember & departmentB_listMembers. These Groups would have corresponding permissions attached, e.g. "Member | Add" and "Member | View". A department in this context may have more resources included, that require separate permissions. Django allows to extend Objects with custom Permissions.
Second, inheritance. Do I understand you want to have individual Groups being member of other groups? Then this is something Django would require you to implement yourself.
However, should you be looking for a really more complex authentication solution, it may be worthwhile to integrate with 3rd party services through, e.g. django-allauth. There are sure more/other solutions, just to throw in one name.
I am using IS WSO2 for authorization with XACML. I am am able to achieve authorization for static resource. But I am not sure with the design when it comes to granularization.
Example : if I have method like getCarDetails(Object User) where I should get only those cars which are assigned to this particular user, then how to deal this with XACMl?
Wso2 provides support for PIP where we can use custom classes which can fetch data from database. But I am not sure if we should either make copy of original database at PDP side or give the original database to PIP to get updated with live data.
Because Cars would be dynamic for the application eg. currently 10 cars assigned to user Alice. suddenly supervisor add 20 more car in his list which will be in application level database. Then how these other 20 cars will be automatically assigned in policy at PDP level until it also have this latest information.
I may making some mistake in understanding. But I am not sure how to deal with this as in whole application we can have lots of this kind of complex scenario where some times we will get data for one user from more than 4 or 5 tables then how to handle that scenario?
Your question is a great and the answer will highlight the key benefits of XACML and externalized authorization as a whole.
In XACML, you define generic, global rules, about what is allowed and what isn't using what I would call high-level attributes e.g. attributes of the vehicle (in your case) or the user (role, department, ...)
For instance a simple rule could be (using the ALFA syntax):
policy viewCars{
target clause actionId=="view" and resourceType=="car"
apply firstApplicable
rule allowSameRegion{
permit
condition user.region==car.region
}
}
Both the user's region and the car's region are maintained inside the application's database. The values are read using a PIP or Policy Information Point (details here).
In your example, you talk about direct assignment, i.e. a user has been directly assigned to a vehicle. In that case, the rule would become:
policy viewCars{
target clause actionId=="view" and resourceType=="car"
apply firstApplicable
rule allowAssignedVehicle{
permit
condition user.employeeId==car.assignedUser
}
}
This means that the assigned user information must be kept somewhere, in the application database, a CSV file, a web service, or another source of information. It means that from a management perspective, an administrator would add / remove vehicles from a user's assigned list (or perhaps the other way around: add / remove assigned users from a vehicle's assigned user list).
The XACML rule itself will not change. If the supervisor adds 20 more cars to the employee's list (maintained in the application-level database), then the PDP will be able to use that information via the PIP and access will be granted or denied accordingly.
The key benefit of XACML is that you could add a second rule that would state a supervisor can see the cars he/she is assigned to (the normal rule) as well as the cars assigned to his/her subordinates (a new proxy-delegate rule).
This diagram, taken from the Axiomatics blog, summarizes the XACML flow:
HTH, let me know if you have further questions. You can download ALFA here and you can watch tutorials here.