On Thu, 4 Jul 2002, Bruno Antunes wrote:
> Date: Thu, 04 Jul 2002 20:55:09 +0100
> From: Bruno Antunes <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Role Mapping
>
> The mapping of roles to OS users/groups was only an example, I could
> have used other names or groups of whatever realm, the example clarifies
> things, because most people know the root user in Unix, and the
> Administrator user in Windows.
>
> Observation: I can in fact simply, map roles to OS users and groups,
> using a JAAS LoginModule. There are LoginModules for Unix and Windows.
>
> The <role-link> in the <security-role-ref> is for a different purpose. I
> think that is well clarified in the specification. In the case of a
> webapp, is just a way to link, different roles to single <security-role>
> in a single webapplication. This way you can unify different role names
> with the same "role" to a unique role. This makes deployment less
> painful, and you can reuse code in different webapps
>
More generally, it lets the application developer use a completely
separate set of role names than those recognized by the underlying
security infrastructure. Whether it is 1:1 or n:1 does not make any
difference.
> The <security-role-ref> is only for <servlet>, so imagine I have a jsp,
> that uses logic to check for a role, just to show different options to a
> user:
> Example
> <logic:hasRole name="AdminRole">
> My presentation code for Admin role here
> </logic:hasRole>
>
> I can't use a <security-role-ref> for a jsp.
>
That is not correct. You can say:
<servlet>
<servlet-name>My JSP Page Servlet</servlet-name>
<jsp-file>/admin/mainmenu.jsp</jsp-file>
<security-role-ref> ... </security-role-ref>
</servlet>
and so on for each page. (This is where development tools that create
web.xml for you, like deploytool in JWSDP and the J2EE reference
implementation, can come in handy.)
> I know I can have in Tomcat different realms webapps, but I want to
> share the same.
>
That's possible as well. The default configuration shares them across all
webapps on all virtual hosts. You can also share them per virtual host if
you want -- it's just a matter of where you stick the <Realm> element.
> In a production environment it is not acceptable, that everytime I want
> to deploy a new webapp, and in that webapp I have a new role name (that
> does not, and maybe it should not) exist in the realm, I must register
> that role in the realm. Lets suppose we have 100 webapplications, each
> webapplication as role named AdminRole<n> where n is 1, 2, ...., 100.
> With Tomcat I must register in my realm the roles AdminRole1,...,
> AdminRole100 just to run that WebApplications.
That is true only if they are truly unique roles.
> If Tomcat supported role
> mapping per web application and the deployer decided that each AdminRole
> will map to a group named Admin in the realm, that was simple to do.
>
(Side Note - The concept of "group" is not a required notion in J2EE
servers, but it is quite handy. The user database implementation in
Tomcat 4.1.x supports the notion of groups, so you can assign roles to a
group and they are inherited by all the members of that group. But this
is just a Tomcat feature, and has nothing to do with any spec
requirements, which only speak of "users" and "roles".)
The important issue is that, ultimately, authorization questions *must* be
answered in terms of the role names that the Realm understands, not those
that the application uses. You have several architectural choices,
depending on which best meets your needs.
Let's assume that you've configured a single Realm that is shared across
all of your webapps, and it has a role named "admin" in it. If you want
to use that role in a given webapp, you have two choices:
* Use the role named "admin" (i.e. exactly the one used in the
realm). No role mapping is required.
* Use some other role name like "foo", and configure something like:
<security-role-ref>
<role-name>foo</role-name>
<role-link>admin</role-link>
</security-role-ref>
which says, in effect, "whenever I talk about role 'foo' in this
servlet, I really mean role 'admin' in the underlying Realm".
As an alternative, you could define your "foo" as a new role in the realm,
and assign it to some users. But you don't *have* to do this -- it's just
one of your options. If you're using something like JDBCRealm or
JNDIRealm, it's trivially easy to add a new role (or a new user, for that
matter), which is instantly available to Tomcat for decision making
purposes.
Tomcat implements role mapping exactly as the specs require it. And, since
it's the web container inside the J2EE reference implementation and passes
all the TCK tests, you can pretty much count on the accuracy of that
statement. :-)
Craig
> Craig R. McClanahan wrote:
>
> >
> >Note that you cannot map roles to real operating system users, because all
> >of this stuff runs in a single JVM process, which (from the point of view
> >of the operating system) has only a single user identity. However, it's
> >possible to use your OS level facilities for authentication by setting up
> >a JAASRealm appropriately -- although IMHO this has security risks,
> >because the username and password are sent across the network unencrypted
> >unless you use SSL for everything. But authenticating this way still has
> >no impact on the Tomcat JVM -- unless you start it as root initially,
> >there is no way for an authenticated web application user to gain root
> >access privileges at the OS level.
> >
> >The general mechanism for role mapping that you are looking for is the
> ><security-role-ref> element nested inside a <servlet> element (which
> >Tomcat does support). To deal with the multiple webapps case, you can
> >either use the role mapping, or set up a separate Realm for each webapp,
> >by nesting a <Realm> element inside <Context> in your server.xml file.
> >
>
> --
> Bruno Antunes,
> Java Software Engineer
>
> email: mailto:[EMAIL PROTECTED]
> Phone: +351.21.7994200
> Fax : +351.21.7994242
>
> WhatEverSoft - Java Center
> Centro de Competencia Java
> Praca de Alvalade, 6 - Piso 4
> 1700-036 Lisboa - Portugal
> URL: http://www.whatevernet.com
>
>
>
>
> _____________________________________________________________________
> INTERNET MAIL FOOTER
> A presente mensagem pode conter informa��o considerada confidencial.
> Se o receptor desta mensagem n�o for o destinat�rio indicado, fica
> expressamente proibido de copiar ou endere�ar a mensagem a terceiros.
> Em tal situa��o, o receptor dever� destruir a presente mensagem e por
> gentileza informar o emissor de tal facto.
> ---------------------------------------------------------------------
> Privileged or confidential information may be contained in this
> message. If you are not the addressee indicated in this message, you
> may not copy or deliver this message to anyone. In such case, you
> should destroy this message and kindly notify the sender by reply
> email.
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
