I've got a pretty ordinary Java EE application running on JBOSS.
It uses the JBoss DatabaseLoginModule JAAS authentication.
It also has application layer users/roles in Hibernate that are exactly the same.
I've got an idea ( which I think is pretty useful for me, anyway) to have a capability bit I can set in the software license object (not using hibernate) that makes all users the read-only user. This lets me make a read only version of the product by relicensing it.
What I'd like to do is remap the user associations based on a boolean flag accessible inside the program.
So normally we get ( many-many join)
User -*UserRole*-Role -*RoleActions
where
user.roleid =>role.id
When the boolean is set ( a capability bit set in the software license )
I'd like JAAS to act like all users were roleid =1 when the license says so.
Any ideas ?
By subclassing DatabaseServerLoginModule I can perform extra checks. ( on the software licence)
Trivially I can then
If the licence is expired, give A Readonly user ( the credentials are fixed)
If the license has the read-only capability bit set, give the Read-only user ( the credentials are fixed)
Since the login has been intercepted, the Hibernate User lookup will be for the right user.
Maybe I'm missing the boat here, but why not do that programatically?
In User object, provide a transient getter like getAuthenticatedRoles() that would additionally filter what Hibernate loaded. Additonally, make the original mapped collection getter protected, and use only getAuthenticatedRoles() from other Java code.
Related
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.
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 am interested in utilising EJB 3's security annotations for our company's security model. As stated in the question title: users are a part of groups and each group has assigned a list of privileges, this allows privileges to be dynamically allocated to groups without effecting group membership.
However, as far as i can see, EJB 3.x only supports the User --> Roles|groups model (virtually the same where groups are treated as roles).
What i am aiming for is something along the lines of:...
#Stateless
public class secureEJB {
...
#HasPrivilege(Privileges.ABLE_TO_MAKE_ARBITRARY_DATABASE_CHANGES)
public void causeMayhem();
...
}
If EJB 3 does not support this model then does anyone know of a library to support this?
Please and thank you.
The EJB perspective/view/interface/specification only consists of users and roles. EJB does not define the way this data is maintained. Roles are used to enforce authorization.
So you can setup whatever model you like to maintain authentication/authorization data. For example users are group members, and permissions are attached to groups.
For example, using JBoss, it's the task of a LoginModule to return the roles of a given user. In case of the DatabaseServerLoginModule you can use a SQL statment to join together users, their groups, and the group/roles assignments. The result is always just a plain list of roles. As for WebSphere, they use the name "Custom user registry" instead of "Login module".
There are some options to build the back end:
As the user is frequently part of a data model of an application (with referential integrity being enforced by constraints) it's often integrated it into the data model of the application.
If this is not required (or even not wanted), you can integrate whatever you like. In that case look at a solution like a portal (Liferay for example), as this provides a data model, maintenenance application, password reset, Email verification, lockout handling, Single sign on (SSO) integration etc. The authorization data model is not the problem; it's rather the need for a user interface to maintain the data.
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