I'm trying to figure out what I need to specify in UML for a role-based access control system.
Basically I have a Database and only specific people are supposed to access specific functions or informations from that database. My academic helper told me to use a role-based access control system and scribbled some stuff onto a paper.
On the left you can see the 3 roles, and connected to it the database, both in the model part of the Model-View-Control.
My question basically: Which functions/variables do I need in the class Role and the role classes so the access control system works and why?
Generally this is supposed to be written in Java.
EDIT: Each Role has its own login credentials, so they will be identified upon login. With this login they are supposed to get one of those roles, but I don’t know how to give them that role.
I was looking for some diagram I found via google a long time ago, long before this question.
RBAC is a standardized model, it doesn't really contain multiple representations. You can extend it with additional security models, and it's multilevel, so higher levels are optional.
Flat RBAC, the first level, requires the following
users acquire permissions through roles
many to many user role assignment
many to many permission role assignment
user-role assignment review (user - role mapping can be changed, not hardcoded)
users can use permissions of multiple roles simultaneously
I have never seen a full implementation of RBAC in the wild. In a previous job we ultimately had to add point 2 to the application to enable administrators to go into a "support" mode, to view an accounts profile as they would.
This diagram gives a largely complete level 4 representation.
Here is the source of this diagram, it has a lot more information than what I'm saying.
I think the biggest variance you'll have (besides naming) is what object has "check access" and the general naming of these objects and methods.
For further reading on the subject, I would suggest these
Role-Based Access Control, Second Edition
ANSI blog
ANSI specification
NIST 4 levels of RBAC implementation
NIST adding attributes to role-based access control
Wikipedia RBAC, also contains UML
There are other documents including some criticisms, I usually find that simply using RBAC is not sufficient, as there are often more complex requirements than just "manager can do X", for example.
Well, still there are many, many ways to model this. And basically it's not an UML but a design issue. Anyway, here's a possibility:
A user has a single Role which is permanently assigned during a login. Of course a user with admin privilege could alter this role to something else. The Role holds a list of assigned Applications where the association class RoleApplication can hold attributes about what the role can do with the application.
Now how you control that an admin can change rights and all these pretty things that come along with a security system are definitely too broad to go here.
Related
I do not understand Java annotations with retention policy as RUNTIME that well. What I'm trying to do is create an annotation named #Authorize and use it on methods which needs user authorization in order to perform some action( the user is already authenticated at this point).
eg. I have an order service with a getOrder() method. I want only the user who created this order to access it.
`
public void getOrder(User user) {
//current code does something like this
if(order.getCreatedBy().equals(user)) {
//then proceed.
}
}
`
I do not want to mix this logic with business logic. Instead, I'm looking to have something like this-
`
#Authorize
public void getOrder(User user) {
//business logic
}
`
There are several methods but not all of them would need such authorization. Could someone please explain me how can I fit the pieces together here?
What I don't understand at this point is that how AnnotationProcessor would help me here since it does its magic at compile time. As far as I understand, it will help me generate some code at compile time but I have no clue how to use that generated code. I went through numerous examples on AnnotationProcessors but I'm still missing something.
These links helped me a bit to understand annotation processing so far-
http://hannesdorfmann.com/annotation-processing/annotationprocessing101
https://equaleyes.com/blog/2017/09/04/annotation-processing/
Even if I go with reflections, where should I place the reflection logic? and is it counter productive of what I'm trying to achieve?
At this point, I'm open to other solutions as well which do not involve annotations but will help me separating out business logic with such resource specific authorization.
To implement authorization controls on methods in Java, I highly recommend Spring Security with an eXtensible Access Control Markup Language (XACML) implementation that has a Spring Security API.
Spring Security
Spring Security provides two main means to protect access to methods:
Preauthorization: this allows for certain conditions/constraints to
be checked before the execution of the method is allowed. Failure to
verify these conditions will result in the failure to call the
method.
Postauthorization: this allows for certain conditions/constraints to
be checked after the method returns. This is used less often that
preauthorization check, but can be used to provide extra security
around complex interconnected business tier methods, especially
around constraints related to the object returned by the method.
Say for example, that one of the access control rule is that the user has have the ROLE_ADMIN authority before being able to invoke a method getEvents(). The way to do that within the Spring Security framework would be to use the PreAuthorize annotation as below:
public interface Sample { ...
#PostAuthorize("hasRole('ROLE_ADMIN')")
Event getEvent(); }
In essence Spring Security uses a runtime Aspect Oriented Programming (AOP) pointcut to execute before an advice on the method and throw an o.s.s.access.AccessDeniedException if the security constraints specified are not met.
More can be found about Spring Security's Method Level Security in section 27.3 of this documentation.
eXtensible Access Control Markup Language (XACML) - a policy language for ABAC
Spring Security does a great job of implementing access control with its expression based access control, but attribute based access control (ABAC) allows more fine grained control of access and is recommended by the National Institute of Standards and Technology.
To address the limitations of Role Based Access Control (RBAC), NIST came up with a new model called ABAC (Attribute Based Access Control). In ABAC, you can now use more metadata / parameters. You can for instance consider:
a user's identity, role, job title, location, department, date of
birth...
a resource's type, location, owner, value, department...
contextual information e.g. time of day the action the user is
attempting on the resource
All these are called attributes. Attributes are the foundation of ABAC, hence the name. You can assemble these attributes into policies. Policies are a bit like the secret sauce of ABAC. Policies can grant and deny access. For instance:
An employee can view a record if the employee and the record are in the same region
Deny access to reading records between 5pm and 8am.
Policies can be used to express advanced scenarios e.g.
segregation of duty
time-based constraints (see above)
relationship-based access control (see above)
delegation rules delegate Bob access to Alice's document.
There are 2 main syntaxes available to write policies:
the Abbreviated Language for Authorization (ALFA), which is based on XACML
the eXtensible Access Control Markup Language (XACML)
ABAC also comes with an architecture to define how the policies will get evaluated and enforced.
The architecture contains the following components:
the Policy Enforcement Point (PEP): this is the component that
secures the API / application you want to protect. The PEP intercepts
the flow, analyzes it, and send an authorization request to the PDP
(see below). It then receives a decision (Permit/Deny) which it
enforces.
the Policy Decision Point (PDP) receives an authorization request
(e.g. can Alice view record #123?) and evaluates it against the set
of policies it has been configured with. It eventually reaches a
decision which it sends back to the PEP. During the evaluation
process, the PDP may need additional metadata e.g. a user's job
title. To that effect, it can turn to policy information points (PIP)
the Policy Information Point (PIP) is the interface between the PDP
and underlying data sources e.g. an LDAP, a database, a REST service
which contain metadata about users, resources, or other. You can use
PIPs to retrieve information the PDP may need at runtime e.g. a risk
score, a record’s location, or other.
Implementations of XACML
Full disclosure - I am on the XACML Technical Committee and work for Axiomatics, a provider of dynamic authorization that implements XACML.
Axiomatics provides a Spring Security SDK for their Axiomatics Policy Server and it provides four expressions that can be used to query the PDP as a part of protecting a method invocation
xacmlDecisionPreAuthz, called with #PreAuthorize
xacmlDecisionPostAuthz, called with #PostAuthorize
xacmlDecisionPreFilter, called with #PostFilter
xacmlDecisionPostFilter, called with #PreFilter
The exact signatures for these methods are as follows:
xacmlDecisionPreAuthz(Collection<String> attributeCats,
Collection<String> attributeTypes, Collection<String> attributeIds,
ArrayList<Object> attributeValues)
xacmlDecisionPostAuthz(Collection<String> attributeCats,
Collection<String> attributeTypes, Collection<String> attributeIds,
ArrayList<Object> attributeValues)
xacmlDecisionPreFilter(Collection<String> attributeCats, Collection<String>
attributeTypes, Collection<String> attributeIds, ArrayList<Object>
attributeValues)
xacmlDecisionPostFilter (Collection<String>
attributeCats, Collection<String> attributeTypes, Collection<String>
attributeIds, ArrayList<Object> attributeValues)
For an entire list of XACML implementations, you can check this list on Wikipedia.
The problems I am facing is related to authorization,
I am granting application's role to the users in this way:
BasicModel.grantRole(relationshipManager, identity.getAccount(), role);
but when I use
hasRole(this.relationshipManager, this.identity.getAccount(), role);
seems to return always true, even if I grant another role, eg. I granted ROLEA role and when I ask for ROLEB it returns true. The grantRole methods that I found in the PL quickstarts are not recognized by the compiler but the hasRole it does.
the authorization annotations seems that are not working, allow users that are not loggedin to invoke the method, and of course allow users with any role to invoke the method
#LoggedIn
#RolesAllowed({"borrower"})
Otherwise seems that PL is working well, with autenthication, and the identityManager. My enviornonment is WildFly 8.2 , and PK 2.7.Final, JPA. These are the classes that I am mapping from the basic model :
<class>org.picketlink.idm.jpa.model.sample.simple.AttributedTypeEntity</class>
<class>org.picketlink.idm.jpa.model.sample.simple.RoleTypeEntity</class>
<class>org.picketlink.idm.jpa.model.sample.simple.IdentityTypeEntity</class>
<class>org.picketlink.idm.jpa.model.sample.simple.RelationshipTypeEntity</class<
<class>org.picketlink.idm.jpa.model.sample.simple.RelationshipIdentityTypeEntity</class>
<class>org.picketlink.idm.jpa.model.sample.simple.PartitionTypeEntity</class>
<class>org.picketlink.idm.jpa.model.sample.simple.AttributeTypeEntity</class>
This may not be the final answer, just won't fit into a comment.
One radical way is to debug the whole thing manually. A slightly less mind-blowing approach, though, would be to look at the database contents. You didn't mention your db type, but there are plenty of tools for examining db contents around. Use one of them:
Go to user_type_entity table (maybe without unserscores) and note the user id.
Go to role_type_entity table and check your role names being there, only one line each. Note the ids of the roles.
Go to relationship_identity_type_entity table and look at the role/assignee pairs with the same owner_id (owner_id likely points to some Grant type in relationship_type_entity table, but we do not need to exmine that now).
So, the key question: do you have the undesired roles assigned to your users there? If so, your function does exactly what it is supposed to do, and you need to look at your code more closely to see if you granted the thing accidentally somewhere.
If your user is not listed as an assignee of the role and yet the hasRole returns true ... well, then you may have a problem with Picketlink itself, and debugging of the function may be required.
I checked the database registers and found that i was assigning all the roles to the users. I also used the HttpSecutiryConfiguration for the authorization problems.
I'm trying to understand what these terms mean. And I came with few examples like:
Aggregation : Facebook has a user
Composition : Each user in facebook has a session.
Association : People uses a browser
But I'm getting confused with has a and uses a examples of mine. Why can't it be User uses a facebook account or Facebook uses a session to authenticate user?
Is that wrong in terms of OOP? Where I'm missing the concept?
The uses a relationship means two things
->both can exist independently
->Data flows from the whole classifier(people) to the part classifier(browser)
The has a relationship means two things
->the lifetime of the part classifier(session) is dependent on the lifetime of the whole classifier(facebook)
->data usually flows in only one direction (that is, from the whole classifier(facebook) to the part classifier(session)).
This article from the Code Project makes a neat explanation of the Subject.
First of all there's no stone-written way to model a domain, there are several ways that are correct modeling approach to a particular problem. For example, your initial example uses a Facebook class and in your follow-up you're now using a Facebook Account type: using one or another (or maybe both) has impact un your model but doesn't invalidate it.
Saying that, according to the Code Project site an association relationship implies:
Owner: No owner
Life time: Have their own lifetime
Child object: Child objects all are independent.
With that in mind, I don't think there's an association relationship between User and Facebook Account since they're highly dependant from each other (assuming User refers to a Facebook user), so a composition might be a better relationship.
I'm not sure what are you refering with your Session class. If it's the period of time while the user is connected there is no sense in saying Facebook uses session for authentication and maybe the asociation relationship between User and Session can be an agregation, since a User can have several Sessions in a day an it's the owner of all of them.
Check this wikipedia entry that precisely discusses aggregation VS composition
So, in Java terms, a Facebook User has a name (composition) and a Facebook User has a list of friends (Aggregation)
As the title says, i have a need to create a dynamic menu stored as a tree in the database and there are plans to put an interface on it.Now i need to decide how to implement the Access Control Layer based on what is on the market suitable for this requirement.
I heavily use Spring IoC, spring mvc etc....with hibernate for my project. I've used apache shiro before and it's not bad.just that the community is still young so it takes time for a question regarding shiro to have contributions and there is not extensive documentation.
I was still planing on using shiro anyway because i've an experience which i don't have with spring security.Now the first question should have been Is is a good idea to tie ACL to menu system|navigation system .I would be please if anyone could share his experience regarding that.
So on top of my head i have this model in mind users, roles, rights, users_rights ,roles_users, roles_rights
users //contains creds and user detail
roles //contains roles
rights // contains rights (including menu entries matching rights, if i have to tie them)
roles_users //many-to-many roles-users with extra columns mapped as entity
roles_rights // many-to-many roles-rights with extra columns mapped as entity
users_rights //many-to-many users-rights mapped as entity with extra columns. special rights for user and overwrite the overall rights given by roles. can deny rights given by a role or add rights not inside any roles
so in the rights table i could have like:
id
name // in the form of admin:users:list
description
menu_name // unique name what shows on page
menu_url
the only question is that how do i handle submenu? self many-to-many rights-rights?
at the end it all becomes so complex.So i would like have other perspective, insights ,suggestions. thanks
I hope I understood what you want.
I think that using a self foreign key is valid.
However, I would suggest that you compute the "ACL value" of a sub menu upon its creation, or upon update of one of the parents,
So you won't spent time calculating it while during ACL check for the sub menu.
I'm sorry if I didn't use the terms correctly,
What in general I mean is that if you have some value at a tree, and this value might be dependent on the value of the parent node in the tree,
you should consider to calculate the value for the child node/leaf during insertion , update, or any change at one of the ancestors.
I am working on a large Java EE web-app with CRM functionalit and we are looking for a security approach/library/solution/anything. Basic role-based security won't work since access control must be based on both role and hierarchy, but must be optionally customisable per document. Because there will be confidential and proprietary information stored, it is a requirement that the security works properly.
Example: To use department store, shelf stalkers stockers can create reports that other stockers can read only if they are in the same department. Now their department manager can read/write/update/delete all reports written by stockers and write reports that all others department managers can read but not see reports of store managers, etc, whom the district managers can r/w/u/d etc. Now, the complications: people at higher levels can make things visible to people at lower levels, either to individuals (department writes document to several specific stockers) users or everyone below them (store manager writes a memo to the entire store) or any permutation you can imagine. Also, individuals can create reports that their peers cannot see or they can choose grant access to store stockers in other districts etc.
We are considering an ACL with one permission per entity, but are worried about the large number of records that would create. Even if only a report was readable to everyone else in a department of 30 and every person above them [in the chain of command], creating a single report would require ~40 records! With 1 report per week per user that is 2000 permissions per user per year. 1,500 users means over 3,000,000 permissions per year.
It seems like a rule-engine based approach would be nice, but I have not seen any blogs or articles mentioning that approach so we're hesitant to that approach.
We are also considering some ACL/rule home-brew hybrid where you could grant permission to a department id with a discriminator of "manager" or "stockers" etc to subselect, but are worried that checking for all possible permissions (you could be granted permission specifically by another user, you have permission as a memeber of your department, you could have permission as a member of a store, or of district) sounds like an error-prone tedious nightmare.
What is the best approach for our application?
You could look at using Spring Security and ACL's - the nice thing about Springs ACL implementation is it is implemented with AoP it should be easier to integrate.
It sounds like your security requirements are quite complicated - off the top of my head I dont know how you'd implement this.. but you can reduce the number of records required by creating ACL's against your object hierarchy and having objects 'inherit' permissions from parent objects. You grant a user read permissions to the parent Department of a Report - so they would inherit read access to the child reports of that department. Alternatively a Manager might have read and update permissions on the Department. The key to all this is how your java object model has been structured.
I have had a similar situation in a system where there were thousands of articles in an object hierarchy of Business Unit -- Publication -- Issue -- Article. You can have hierarchys of ACL's - so in my system - users that had C/R/W permissions to a particular business unit, inherited permissions on all child objects in the hierarchy.
In my opinion Customization + Complexity = JBoss Drools, I don't have much experience using this technology but I believe it would be worth a look in your case, check out the latest drools samples at: http://blog.athico.com/2011/04/try-drools-example-in-less-than-minute.html