I need in my application to get all permissions associated with a specific role with seam ?
I tried with permissionManager.listPermissions but this method gives permissions associated with a specific target and not a specific recipient (role in my case).
Thanks for your help.
this is not possible by default in Seam. However, you can extend your permission store to do this. If you are using the JpaPermissionStore (which in most of the cases is true), you can check this link
Related
Is there any way to associate custom attributes with a Role in wso2? similar to the way we assign claims for profile.
I understand, we can associate Permissions to the user.
AFAIK, Roles cannot have claims in WSO2 environments. I doubt this is a common requirement. Anything that you are trying to achieve in particular?
Currently, it is not possible to maintain custom attributes with roles. Permissions are always associated to the roles and roles are associated to the user.
Thanks
Isura
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.
Let say you have a User resource. It has many fields. However, not all fields should be allowed to updated by a regular user, but admins should be allowed. Are there any common solutions to this?
E.g. enabled should only be allowed to be updated by using a PUT request if the authorized user is an admin. How should I do this?
Have you heard of spring-security authorization? They have a way of hiding the fields based on the user roles. If your app is large, it makes sense to integrate this.
Lookup for methodlevel security
Domain object security (ACL)
Good article about entity filtering here
http://blog.dejavu.sk/2014/02/04/filtering-jax-rs-entities-with-standard-security-annotations/
I have configured a LDAP realm in Glassfish, and authentication works just fine.
Now I am wondering how could I match the Principal.getName() return to a certain attribute of my LDAP user object. I thought it would use something such as "givenName" by default, but it returns the username used for authentication.
I don't mind making an extra trip to the LDAP server to obtain the additional information, but instead of keeping the LDAP connection attributes in my application, I'd like to inject the security realm (if such a thing is possible) and use its own connection.
So, in short, the questions are:
1) Can I map additional attributes to the Principal returned by the realm?
2) If number one is not possible, then how could I reuse the realm's information in order to connect to the LDAP server and obtain the data I need?
Thanks in advance for any help or suggestions.
The JAAS Subject often contains many principals, each one representing a different attribute.
For Java EE one, and only one, of these Principals is selected for the one that is returned when you call HttpServletRequest#getUserPrincipal and similar methods. The other Principals are for the Java EE API just lost.
You can determine which of those Principals to select by writing a JASPIC authentication module if the login happens via HTTP or SOAP.
You can preserve the entire Subject by putting it into the HTTP session from within the JASPIC authentication module. Other code can pick it up from there.
Edited: I was under the impression that the following used to work, at least with GlassFish 4.0. Unfortunately, that doesn't (any longer) seem to be the case. A workaround can be found in the comments of this issue.
Not really a solution per se; just a little detail I kept overlooking for a while, and which was quite a relief for me to have now become aware of. So --skipping the boring specifics-- I realized that a CallerPrincipalCallback(Subject s, Principal p) constructor is additionally available, which, when supplied with my custom Principal, causes the server to actually retain it, instead of wrapping it in or transforming it into an internal GlassFish implementation instance, as I previously thought it would. From "userspace" I was then able to access my "enriched" (more Subject- than Principal-like, to be honest) version the usual way (e.g. ExternalContext#getUserPrincipal, etc.), cast it and enjoy the convenience of not having to care about deriving custom Principals from generic ones in each application from now on :) .
Well, I could not extend the Principal attribute mapping without using a custom LoginModule; so, instead I opted to the solution described here: http://docs.oracle.com/cd/E19798-01/821-1751/abllk/index.html
What I do is, upon authentication, use the injected LDAP context to go back to the LDAP server and obtain the attributes I want. The downsides are obvious: two trips to the server instead of a single one, and the extra code to probe attributes and tie them to the Principal (or another POJO) in some way.
My specific problem is that when I attempt to bind with the following full dn, all is well
new LDAPConnection().bind(LDAPConnection.LDAP_V3,
"uid=me#wherever.com,ou=Lev1,ou=Lev2,o=Company", "secret".getBytes());
however, when I attempt to bind with an incomplete dn, I am getting an Invalid Credentials exception.
new LDAPConnection().bind(LDAPConnection.LDAP_V3,
"uid=me#wherever.com,ou=Lev1,o=Company", "secret".getBytes());
Is their some form of wildcarding that is possible, such as "uid=me#wherever.com,ou=Lev1,ou=*,o=Company"?
No. It sounds like you might be confusing bind() with search(). bind() is authentication against the directory, like logging in. Binding with a wildcarded dn would be like having a login with a wildcarded username. Doesn't really make sense.
To do a wildcard like this you have to do a search first and select which one you want to perform the bind. This may mean you need to bind with an id which can perform the search. ;)
No, the use of wildcards is not possible in the way you describe. However, SASL provides a mechanism to accomplish the desired behavior. Your directory server administrator may be able to configure the directory server to map identities to an authorization ID wherein the client need not know the distinguished name of the identity with which to authenticate the LDAP connection. Professional-quality directory server software will provide a variety of identity mapping capabilities.