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 Mon, 22 Apr 2013 06:37:46 GMT
On Apr 21, 2013, at 3:56 PM, Jeremy Boynes <jboynes@apache.org> wrote:

> On Apr 19, 2013, at 11:04 PM, David Jencks <david_jencks@yahoo.com> wrote:
>> 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.
> 
> Mark does bring up a gap here though. Before 3.0, the only reference to a role from code
would be in the parameter value passed to isUserInRole(), and the assembler was responsible
for listing all of those in web.xml; the deployer was responsible for linking them to actual
roles in <security-role> elements, and then linking those to groups/principals in the
authorization system in a container-specific manner. Declarative security (security-constraint/auth-constraint)
did not require a linkage mechanism as the deployer could modify the value in the <auth-constraint>
declaration in web.xml. With 3.0 annotations, however, the auth-constraint is now declared
in code and the deployer has no mechanism to link its roleNames() to an actual role.

Not quite following you here.  I thought you'd declare all your roles using the @DeclareRoles
annotation or in @AllowRoles inside constraints.  These are equivalent to <security-role>
elements in web.xml.  If for some reason you don't like the role names in the annotations
you can always override them in web.xml just like you can override other non-cdi annotations.
 Otherwise the deployer can link the principal names to the role names just like with web.xml.

 
> 
> 
> Option b) sounds like a potential solution but as you say that is not something the spec
currently allows. The spec could be extended to allow this, and I think that would even be
a compatible change given the existing requirement for <security-role-ref> to default
to a <security-role> with the same name if no explicit link is specified.

How is this different from the existing possibility to define a proprietary mapping between
principal names and application role names?

thanks
david jencks
> 
> There is a scoping issue for role ref names but that is not new - 2.x libraries can also
conflict by using the same value in calls to isUserInRole(). 
> 
>> 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.
> 
> As the spec stands with <security-role-ref>/@DeclareRoles only allowed on Servlets
and not on Filters I'd come to the same conclusion. It is a weird coupling though as the role
reference is made by the filter and not the servlet, the servlet author does not know a-priori
what filters will be applied or vice versa. Again, more of an issue now we have annotation
based config. IMO, getting the spec to clarify this, and potentially allowing filters to declare
role references would be useful.
> 
> I've assumed the same model would apply for calls to isUserInRole() from within listeners
e.g. request or request attribute? Or from within an extension-mapped servlet like the JSP
servlet?
> 
>> 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.
> +1, although falling back to mapping application roles to groups in the absence of configuration
by the deployer is temptingly convenient (although with the "new-group" problem you mention).
> ...
>> On Apr 19, 2013, at 2:28 PM, Mark Thomas <markt@apache.org> wrote:
> ...
>>> 
>>> 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?
> 
> Seems to me there's ambiguity there that would be worth clarifying.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message