Purpose of roles tags in tomcat-users.xml?
Asked Answered
M

3

12

In the Tomcat 7 tomcat-users.xml file, what purpose is served by the <role /> tags?

For an XAMPP instance of Tomcat 7, I've figured out how to configure my tomcat-users.xml file to permit me to access both Tomcat Web Application Manager and Tomcat Virtual Host Manager. More specifically, the following enables the aforementioned access:

<tomcat-users>
  <user username="uname" password="pword" roles="manager-gui,admin-gui"/>
</tomcat-users>

Note that what's NOT in this successful snippet of XML are any <role /> tags. That's the crux of my question: I can't for the life of me figure out what purpose role tags are meant to serve.

In pursuit of learning how to configure access, I've read plenty of documentation and forum postings, but they all seem to go in a circle: One can define roles, but then roles don't really seem to themselves define anything useful(?)

For example, here's the recurring illustration used in both the tomcat-users.xml file and in numerous forum posts "explaining" the use of roles.

<tomcat-users>
  <role rolename="tomcat"/>
  <user username="uname" password="pword" roles="tomcat"/>
</tomcat-users>

Okay, so in this "explanation" a role element defines a rolename attribute equal to tomcat, then the user element contains a roles attribute that defines the user's role as tomcat. What's the point?

Asked another way, given that in role element the rolename attrbute defines tomcat, roles=tomcat does what, exactly? Especially compared to my working user definition of where manager-gui and admin-gui define roles that enable Tomcat Web Application Manager AND Tomcat Virtual Host Manager access.

Cheers & thanks,
Riley
SFO

Meltwater answered 19/2, 2013 at 1:13 Comment(1)
It really doesn't matter. This file is only a toy. You should be using LDAP or a database to hold serious users and roles, and a custom Realm.Brill
M
4

The use of the <role .../> element in tomcat-users.xml is optional. Tomcat builds the list of roles from the <role .../> elements and from the roles named in the roles="..." attribute of the users.

The benefit of using the <role .../> element is that you can declare the complete set of supported roles and you can include description attribute describing the role.

As an aside, tomcat-users.xml also supports groups although they are not shown in the example that ships by default with Tomcat. Groups are sets of roles that can then be assigned to users.

Moynihan answered 27/11, 2013 at 10:13 Comment(0)
O
3

From what I understand you (can) define roles:

  • because it gives you more flexibility, for example add a description an for instance. A GUI can use this information.

    <role rolename="customer" description="Customer of Java WebService"/>
    
  • you can remap or group the roles later in a specific servlet

    <security-role-ref>
        <role-name>cust</role-name>
        <role-link>bankCustomer</role-link>
    </security-role-ref> 
    

Please keep in mind that I am not a Tomcat expert so I hope that a true expert can refine this answer.

Orelee answered 26/11, 2013 at 15:57 Comment(0)
A
2

Asked another way, given that in role element the rolename attrbute defines tomcat, roles=tomcat does what, exactly? Especially compared to my working user definition of where manager-gui and admin-gui define roles that enable Tomcat Web Application Manager AND Tomcat Virtual Host Manager access.

Role/security constraints are defined in applications descriptor web.xml.

For Example, manager-gui is defined in tomcat manager application:

<security-constraint>
<web-resource-collection>
  <web-resource-name>HTML Manager interface (for humans)</web-resource-name>
  <url-pattern>/html/*</url-pattern>
</web-resource-collection>
<auth-constraint>
   <role-name>manager-gui</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description>
  The role that is required to access the HTML Manager pages
</description>
<role-name>manager-gui</role-name>
</security-role>
Agribusiness answered 7/8, 2015 at 7:2 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.