assign-groups in GlassFish Security realm

In the Java EE environment, roles are logical privileges which convey/represent permission to operate on some particular set of resources in an application. The Sun Java System Application Server environment consists of several realms, which each contain a complete database of users and groups that identify valid users of an application. When the roles are mapped to users, the users are effectively granted the permissions conveyed/represented by the privilege.

In Sun One Application Server 7.0, you can assign a role to all authenticated users in all realms at the same time, and applications can define authorization for that role. This addresses the following common scenario in the LDAP environment:

  • All authenticated users can access some subset of protected resources within the application. It doesn't matter who you are, only that your identity has been established.
  • The set of user groups is large or dynamic, but not specific to the application.

We wanted an ability to grant permission based on authentication independent of identity, in other words, we wanted a way to grant all authenticated identities to a role, or to define a role that would be understood to be mapped to all authenticated identities, and not to unauthenticated entities.

In Sun Java System Application Server 8.x and GlassFish v1, various RFEs and issues have been filed requesting support of the above scenario. Therefore, this scenario has been addressed in GlassFish v2. In GlassFish v2, the assign-groups property in CertificateRealm has been extended to FileRealm, LDAPRealm, SolarisRealm, and JDBCRealm. With this change, it is possible to configure all realms so that they assign one or more common group principals as a result of successful authentication, and such that every user is effectively made a member of the common groups. Given that this is the case, mapping one or more of the group principals to a role, either explicitly or by default, will allow the role to be used as an ANYONE role, a role that conveys/represents permission to operate on all resources which are accessible to any authenticated user. You can assign additional groups to all authenticated users in a specific realm without having to add those groups to all authenticated users in all realms. This gives us a finer control and allows us to resolve the issues with the above scenario as follows:

  • Set the assign-groups property for a given realm. All authenticated users of the given realm will assign additional groups as specified by the assign-groups property, for instance,
        assign-groups=agroup
  • Map additional groups to desired roles in Sun-specific deployment descriptors. For instance, in sun-applicaton.xml,
    <sun-application>
      <security-role-mapping>
        <role-name>javaee</role-name>
        <principal-name>javaee</principal-name>
      </security-role-mapping>
      <security-role-mapping>
        <role-name>ANYONE</role-name>
        <group-name>agroup</group-name>
      </security-role-mapping>
    </sun-application>
Comments:

Questions or comments: 1) There is a entry needed for assign-groups in order to use ANYONE role. I think this is duplicate in addition to anonymous role defined (ANYONE).
2) Why does the additional default groups needed role mapping (the last snippet sun-application.xml) mentioned ? This defeats the purpose of having the default role mapping without explict rolemmaping in the application. Thanks. -- Jagadesh

Posted by Jagadesh Munta on August 15, 2006 at 04:39 AM PDT #

Let me clarify that there is a difference between role and group. The group is associated to a realm user and role is associated to an application. A given user can be in different roles in two different applications. The ANYONE role mentioned above has never implemented. It was intended to provide a default role for all applications. In our implementation of assign-groups, it provides default groups for a given realm. And the mapping can be provided by sun\*xml or default principal to role mapping. This is more flexible than ANYONE mentioned above.

Posted by guest on February 12, 2007 at 03:37 AM PST #

can I put the role mapping in application.xml and not at all having the sun-application.xml

Posted by guest on January 20, 2010 at 12:29 PM PST #

No, the role mapping must be in sun-application.xml.

Posted by Shing Wai Chan on January 21, 2010 at 02:04 AM PST #

Post a Comment:
Comments are closed for this entry.
About

Shing Wai Chan

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today