Re: Unauthenticated principal

[David Blevins <da...@visi.com>]

On Dec 30, 2008, at 3:51 AM, Luis Fernando Planella Gonzalez wrote:

> Well, my problem is not really configuring the default (or  
> unauthenticated)
> username, but it's roles.

We should already be adding a role of the same name so that people  
could do as you demonstrate below.  I've checked the code to be sure  
and it looks like that is the case.

> I'd like to annotate EJB methods like this:
>
> @RolesAllowed({"public", "broker"})
> public void x() {}
>
> @RolesAllowed({"public", "admin"})
> public void y() {}
>
> @RolesAllowed("admin")
> public void z() {}

I tried this out in embedded mode using "guest" instead of "public"  
and it worked fine.  Should work the same way in Tomcat.

Give the code above a try in Tomcat but with "guest" in the  
RolesAllowed instead of "public".  If that works as I suspect, than  
making the change to allow the default username to be changed should  
do the trick.

-David

Re: Unauthenticated principal

[David Blevins <da...@visi.com>]

On Jan 5, 2009, at 4:13 AM, Luis Fernando Planella Gonzalez wrote:

>>
>> I tried this out in embedded mode using "guest" instead of "public"  
>> and it
>> worked fine.  Should work the same way in Tomcat.
>>
>> Give the code above a try in Tomcat but with "guest" in the  
>> RolesAllowed
>> instead of "public".  If that works as I suspect, than making the  
>> change to
>> allow the default username to be changed should do the trick.
>>
>>
> It doesn't work in Tomcat. I've noticed that TomcatSecurityService  
> overrides
> the getLogicalRoles() method.
>
> AbstractSecurityService implements it by iterating over the logical  
> roles
> and the principal names, granting roles matching principal names. In  
> that
> case, what you said is true: having a default principal named  
> "guest" would
> have a role named "guest".
>
> However, TomcatSecurityService understands two Principal  
> implementations:
> TomcatUser (which carries together the Realm, and delegates to it) and
> RunAsRole, which knows the role being "runned as".
>
> In my case, to make it work, I've implemented the following in a  
> tomcat
> Valve:
>
>    @Override
>    public void invoke(Request request, Response response) throws
> IOException, ServletException {
>
>        if (!initialized) {
>            SystemInstance systemInstance = SystemInstance.get();
>            final RoleResolver defaultResolver = (RoleResolver)
> systemInstance.getComponent(SecurityService.class);
>            systemInstance.setComponent(RoleResolver.class, new
> RoleResolver() {
>                @Override
>                public Set<String> getLogicalRoles(Principal[]  
> principals,
> Set<String> logicalRoles) {
>                    Set<String> roles =
> defaultResolver.getLogicalRoles(principals, logicalRoles);
>                    if (roles == null || roles.isEmpty()) {
>                        roles.add("public");
>                    }
>                    return roles;
>                }
>            });
>            initialized = true;
>        }
>    }
>
> It works, because the defaultResolver (TomcatSecurityService)  
> returns no
> roles.
>
> So, it seems to me that it's really a new feature to be implemented.  
> I've
> registered https://issues.apache.org/jira/browse/OPENEJB-984 for it.

I see.  Looks like we should update the TomcatSecurityService to  
understand the User and Group principals that will be in the  
defaultSubject created by its parent.  That in addition to letting the  
defaultSubject name be configurable seems like it'd do the trick.

-David

Re: Unauthenticated principal

[Luis Fernando Planella Gonzalez <lf...@gmail.com>]

>
> I tried this out in embedded mode using "guest" instead of "public" and it
> worked fine.  Should work the same way in Tomcat.
>
> Give the code above a try in Tomcat but with "guest" in the RolesAllowed
> instead of "public".  If that works as I suspect, than making the change to
> allow the default username to be changed should do the trick.
>
>
It doesn't work in Tomcat. I've noticed that TomcatSecurityService overrides
the getLogicalRoles() method.

AbstractSecurityService implements it by iterating over the logical roles
and the principal names, granting roles matching principal names. In that
case, what you said is true: having a default principal named "guest" would
have a role named "guest".

However, TomcatSecurityService understands two Principal implementations:
TomcatUser (which carries together the Realm, and delegates to it) and
RunAsRole, which knows the role being "runned as".

In my case, to make it work, I've implemented the following in a tomcat
Valve:

    @Override
    public void invoke(Request request, Response response) throws
IOException, ServletException {

        if (!initialized) {
            SystemInstance systemInstance = SystemInstance.get();
            final RoleResolver defaultResolver = (RoleResolver)
systemInstance.getComponent(SecurityService.class);
            systemInstance.setComponent(RoleResolver.class, new
RoleResolver() {
                @Override
                public Set<String> getLogicalRoles(Principal[] principals,
Set<String> logicalRoles) {
                    Set<String> roles =
defaultResolver.getLogicalRoles(principals, logicalRoles);
                    if (roles == null || roles.isEmpty()) {
                        roles.add("public");
                    }
                    return roles;
                }
            });
            initialized = true;
        }
    }

It works, because the defaultResolver (TomcatSecurityService) returns no
roles.

So, it seems to me that it's really a new feature to be implemented. I've
registered https://issues.apache.org/jira/browse/OPENEJB-984 for it.