On Apr 21, 2013, at 11:37 PM, David Jencks <david_jen...@yahoo.com> wrote:
> On Apr 21, 2013, at 3:56 PM, Jeremy Boynes <jboy...@apache.org> wrote:
>
>> On Apr 19, 2013, at 11:04 PM, David Jencks <david_jen...@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.
I may be wrong, but I've viewed @DeclareRoles as more akin to
<security-role-ref> in that is declaring a role reference I make from within
code in a discoverable way; without annotation, an assembler or deployer would
need to rely on documentation supplied with the code to know this reference was
made. That's different to @RolesAllowed et al. which are specifying the
deployment concern of what roles are permitted to access the servlet.
Or, putting it another way, @DeclaresRole is metadata describing what the
implementation code does whereas @RolesAllowed is configuration about the how
the code should be used. Changing the role reference described by @DeclaresRole
requires modifying the code that calls isUserInRole() which is outside the
assembly/deployment role.
>> 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?
It's a portable way for an assembler creating a web-application from components
provided by different suppliers to link the roles declared in the annotations
(whose names are defined by the component providers) to a common set of
application roles (defined by the assembler). The deployer then maps one set of
application roles to principal names in a proprietary way.
Its trying to address the situation where two components from different
providers both specify @RolesAllowed("user") but mean different things by
"user," or where one defines "user" and the other defines "customer" and the
assembler wants them to map to the same application role.
Cheers
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
