tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: <security-role-ref> and security constraints
Date Sat, 20 Apr 2013 06:04:04 GMT
Hi Mark,

I hope my being tired doesn't come across as being unpleasant… if so I apologize in advance.

I think a lot of the security discussion in the servlet spec is vague and misleading.  I think
the JACC spec provides a firmer basis for thinking about how security is supposed to work.

IMO you have misinterpreted roles in the ee specs.  The specs including the servlet spec define
application roles and base the declarative security constraints on them.  Then you can map
strings that bits of the application like, at least ejbs and servlets, to these declared security
roles using a security-role-ref.  The role-link has to be one of the declared application
roles.  For web apps the security-role-ref is defined on servlets.  The application roles
no matter where defined are scoped to the entire application not just one web app or web fragment.
 If a security-role-ref is not defined for a string, and you call isUserInRole with that string,
the string is assumed to be a defined application role.

Based on the JACC WebRoleRefPermission, where the constructor arguments are the servlet name
and the role name, I've concluded that the a filter gets the same isUserInRole behavior as
the servlet the request ends up at after going through the filter.  I think this is a satisfactory
solution, and it's passed quite a few ee tcks by now.  It's also quite easy to implement :-).
 I think talking to Ron Monzilla if you disagree with it would be the way to go.

Then you presumably have an external security system such as ldap with some defined entities
such as groups, and these usually get represented as Principals, perhaps in a Subject..  These
are not application roles.  You need to map the externally defined entities to the application
roles.

IIUC tomcat has chosen to only support mappings where the principal name equals the name of
the application security role.  IIRC the last time I looked many years ago tomcat did not
verify that all the security roles used in security constraints or by isUserInRole calls were
actually declared application roles.

From my limited recollection of tomcat internals, I don't understand why tomcat doesn't verify
that security roles that are used are declared, and why there isn't a more flexible mapping
from e.g. groups to application roles.

For your specific example "admin" and "sysuser" are distinct application roles available for
use across the entire application and the problem is that there is no way in tomcat to map
the hr-manager principal representing an ldap group to roles with different names.

Your option (b) is IMO definitely and very clearly not spec compliant.

I think (a) is correct, by providing a more flexible way to map between principals and application
roles.  I've always thought that even a default map between principals and roles using name
equality was somewhat dangerous in the case that you don't want  to assign any groups to a
particular role.  The ldap administrators could not know about the role and create a matching
group and suddenly there are users in that role.

A little googling to try to remind myself about security-role-refs turned up http://docs.oracle.com/javaee/5/tutorial/doc/bncav.html#bncax
which indicates very clearly that Sun thinks groups are not roles and that you need a flexible
mapping between them. (see the sun-web-app snippet at the bottom).

thanks
david jencks



On Apr 19, 2013, at 2:28 PM, Mark Thomas <markt@apache.org> wrote:

> Currently, Tomcat only checks against <security-role-ref> elements if
> there is a call to isUserInRole(). Prior to Servlet 3.0 this made sense.
> The person deploying the web application has control over web.xml and
> hence the security roles (those used in security constraints) but no
> control over application roles (those used by developers in Servlets
> with isUserInRole()) and therefore needed a mechanism to map the
> application roles to security roles.
> 
> This mechanism is usually used to map application roles to security
> roles that exist in an external authentication and authorisation system
> such as an LDAP directory. For example, the application role admin in
> the HR application may get mapped to the hr-manager role that exists in
> the LDAP directory.
> 
> With Servlet 3.0 plugability features the picture changes a little.
> 
> Now a fragment may define security constraints that use a security role
> that does not match the organisations security roles and can't be
> modified in the application's web.xml. For example, an HR application
> with two fragments may define a role "admin" in fragment A and "sysuser"
> in fragment B both of which need to be mapped to the "hr-manager" role.
> 
> Oh, and just to throw a spanner in the works, if a Filter uses
> isUserInRole() there is no way to map the application role to a security
> role.
> 
> I'm currently unsure how this issue should be addressed. The options as
> I see them are:
> 
> a) There is an obvious solution I have missed.
> 
> b) Check <security-role-ref>'s when processing security constraints.
> 
> c) Something else.
> 
> 
> Given the Filter issue, I think c) is the only viable option.
> 
> 
> Tomcat's current behaviour looks to be specification compliant but there
> appears to me to be an issue here the the Servlet EG needs to address.
> Before I move this issue there what do folks think about this? Is there
> an issue or am I missing the obvious?
> 
> Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message