Glassfish 3.1 default principal to role mapping
Asked Answered
A

1

19

I am working with glassfish and jaas module.

I configured my web.xml in this way.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>ALL Page for admin</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>user</role-name>
    </auth-constraint>
</security-constraint>
<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>file</realm-name>
</login-config>
<security-role>
    <description>Administrator</description>
    <role-name>user</role-name>
</security-role>

It means all user that want to access my web application need be of the group user.

Then on the glassfish console I need to tick the options in: Configuration -> server-config -> security -> Default Principal To Role Mapping

My question is why I need to tick this Default Principal to Role Mapping ? And how I can change my web.xml to avoid to tick it ?

Thanks a lot

Loic

Aromatize answered 18/7, 2011 at 2:28 Comment(0)
S
38

When you specify the roles and roles in web.xml you are using declarative security, which essentially relies on the use of JAAS to enforce authentication and authorization requirements specified declaratively.

The roles specified in the deployment descriptors are merely representations of the roles that are used in the application. These roles need not be the same as the ones present in the user-identity database (or authentication realm) used at runtime, and usually these might be different, for development of the application may have been undertaken without any regard to the actual users and groups present in the user-identity database.

Typically a mapping is performed between the declarative roles specified in web.xml and the principals or groups present in the user-identity database using the container specific deployment descriptors. In Glassfish 3,1, this happens to be the glassfish-web.xml file. Each such mapping would map a declarative role in the application, to either a principal or a group in a JAAS realm, in the following manner in either glassfish-web.xml (for WAR file deployments) or glassfish-application.xml (for EAR file deployments), or glassfish-ejb-jar.xml (for EJB JAR file deployments):

glassfish-web.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app error-url="">
...
    <security-role-mapping>
        <role-name>user</role-name>
        <principal-name>Root</principal-name> <!-- Map a principal to the role 'user' -->
        <group-name>Administrators</group-name> <!-- Map a group to the role 'user' -->
    </security-role-mapping>
...
</glassfish-web-app>

glassfish-application.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-application PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Java EE Application 6.0//EN" "http://glassfish.org/dtds/glassfish-application_6_0-1.dtd">
<glassfish-application>
...
    <security-role-mapping>
        <role-name>user</role-name>
        <principal-name>Root</principal-name> <!-- Map a principal to the role 'user' -->
        <group-name>Administrators</group-name> <!-- Map a group to the role 'user' -->
    </security-role-mapping>
...
</glassfish-application>

glassfish-ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-ejb-jar PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 EJB 3.1//EN" "http://glassfish.org/dtds/glassfish-ejb-jar_3_1-1.dtd">
<glassfish-ejb-jar>
...
    <security-role-mapping>
        <role-name>user</role-name>
        <principal-name>Root</principal-name> <!-- Map a principal to the role 'user' -->
        <group-name>Administrators</group-name> <!-- Map a group to the role 'user' -->
    </security-role-mapping>
...
</glassfish-ejb-jar>

The above descriptors map a role user to a Principal with individual identity of name Root and to a user group with name Administrators in the realm. You can omit either of these mappings, and retain only a role to principal mapping, or a role to group mapping. You may also have multiple principals mapped to the same role, or multiple groups mapped to the same role, or even multiple principals and groups mapped to the same role.

It is important to understand the concept of principals and groups in JAAS realms - a principal represents the identity of a Subject (the user logging into the application) in the system, and it could be an individual identity (a single user) or a group identity (a user group). By mapping the declarative roles to the actual principals or groups, one would be able to enforce rules specified in the web.xml against any user-identity database (i.e. any realm), and be able to do so dynamically without any changes in the codebase; after all, such a change would require re-mapping the declarative roles to the new set of principals and groups, in a possibly different realm. You can find a basic tutorial on how Java EE security and JAAS work together in the chapter on security in the Java EE 6 tutorial.

Glassfish allows for a simplified mapping scheme, where it is not necessary to perform the mapping for all declarative roles in the container-specific deployment descriptor (in this case glassfish-web.xml), as long as the names of the declarative roles happen to be similar to the names of the principals or groups. This is the default principal to role mapping scheme. It appears that in your case, the principals/groups in your realm are the same as the declarative roles specified in web.xml, and hence you would avoid mapping the roles to principals and groups explicitly. In simpler words, if the role user is the same as a principal user or a usergroup user in your JAAS realm (and similarly for other identities), then you can use the default role to principal mapping scheme of Glassfish, without mapping this for every role in your web.xml file.

If you wish to avoid ticking the deployment option of default principal to role mapping, then you must provide the role to principal/group mapping yourself in the container specific deployment descriptors, as you would normally do for other application servers.

You could read more about this topic in one of the posts on blogs.oracle.com that describes this feature of Glassfish.

Souse answered 18/7, 2011 at 3:30 Comment(10)
Thanks for your answer. Actually what I want to do is to have one group called user. And every users are part of this group. It means everybody which has an account from my application (it is a war) can connect using a password and a user. Then after I manage by myself who can access what in the application.Aromatize
If I use the code you give me for the glassfish-web.xml. I get the following error when trying to conenct to my application. Access to the specified resource (Access to the requested resource has been denied) has been forbidden. It does not even give me the login screenAromatize
Sorry. Ok I get it now. I just need to add the mapping from my users and it works :) THanks a lot you rockAromatize
Going by your second comment, I would infer that you do not have a group with name user in the realm; if so you need to create such a group that would contain all users. Also, you may drop the role to principal mapping in glassfish-web.xml and only use role to group mapping.Souse
A last comments. Can I map all my users from the realm to the role user ? with smth like that ? <security-role-mapping> <role-name>user</role-name> <principal-name>*</principal-name> <group-name>user</group-name> </security-role-mapping>Aromatize
As far as I know, that is not possible, with the only workaround being adding all your users to a single group that you may then use. It might be possible with a custom JAAS login module, that understands * as a usergroup identity that all valid principals would be a part of, but most JAAS modules might not recognize it.Souse
Thanks for the extra info link. was very helpful. Especially the diagram showing how the application maps into roles, and then the roles map out to principles and groups.Screwed
>" roles in web.xml you are using declarative security, which essentially relies on the use of JAAS" - This is not correct in general. GF uses an identity store that has the JAAS LoginModule interface, but everything is totally GF specific there. Other servers don't have to use anything from JAAS at all. In general, with roles in web.xml you're relying on the use of Servlet security, which may use whatever proprietary artefacts for the identity store. See arjan-tijms.omnifaces.org/2015/10/…Lanciform
>"the use of JAAS to enforce authentication and authorization requirements specified declaratively." - IFF a server uses JAAS at all in a proprietary way, it's always only for the LoginModule interface, and JAAS is reduced to a simple role supplier and therefor only does authentication. If JACC is used (all EE servers should, but only GF really does), then some JAAS-like types are used, but most of them like java.security.Permission are actually pre-JAAS (from the original java security model)Lanciform
To sum up previous comments; JAAS is not the universal Java EE security framework that you seem to think it is ;) See raymondkng.sys-con.com/node/171477 and java.sys-con.com/node/1002315Lanciform

© 2022 - 2024 — McMap. All rights reserved.