You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Luis Fernando Planella Gonzalez <lf...@gmail.com> on 2008/12/15 13:09:45 UTC
Unauthenticated principal
HI.
I'm using openejb under tomcat (with openejb.war).
I implemented a custom Tomcat Realm, and everything was going fine, but
I found one problem:
I need to use a role name ("public") as the unauthenticated user, but I
didn't find out how to do this...
After some deep debugging, I found out that I could, at some point, call
SystemInstance.get().setComponent(RoleResolver.class, new Something()),
being something a class that returns the "public" role when no roles are
available. But it just don't smell well to me.
There must be a better way.
Any thoughts?
--
Luis Fernando Planella Gonzalez
lfpg.dev@gmail.com
Re: Unauthenticated principal
Posted by 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
Posted by 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.
Re: Unauthenticated principal
Posted by 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
Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.
Well, my problem is not really configuring the default (or unauthenticated)
username, but it's roles.
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() {}
That's why I've set another RoleResolver. If the default user name is guest,
public, joe or whatever won't change his roles...
I've also checked that my custom Realm's authenticate method is never
invoked by TomcatSecurityService, because there was no real "login".
So, my real question is: how to set the unauthenticated user roles in
OpenEJB integrated in Tomcat?
2008/12/29 David Blevins <da...@visi.com>
>
> On Dec 18, 2008, at 7:44 AM, Luis Fernando Planella Gonzalez wrote:
>
>> Luis Fernando Planella Gonzalez escreveu:
>>
>>> HI.
>>> I'm using openejb under tomcat (with openejb.war).
>>> I implemented a custom Tomcat Realm, and everything was going fine, but I
>>> found one problem:
>>> I need to use a role name ("public") as the unauthenticated user, but I
>>> didn't find out how to do this...
>>> After some deep debugging, I found out that I could, at some point, call
>>> SystemInstance.get().setComponent(RoleResolver.class, new Something()),
>>> being something a class that returns the "public" role when no roles are
>>> available. But it just don't smell well to me.
>>> There must be a better way.
>>> Any thoughts?
>>>
>>>
>> Why anybody has answers to more complicated questions? ;)
>>
>
> More like slipped through the cracks :)
>
> I'll leave it with SystemInstance.get().setComponent(RoleResolver.class,
>> ...) for now, but I'm sure there's a better way...
>> I've found that some web pages states about a security namespace, which
>> has a default-principal tag, but that's for geronimo.
>>
>
> Right, not applicable here.
>
> How to configure it in the tomcat integration? I'm sure there's a way to
>> do it...
>>
>
> Right now in the AbstractSecurityService, the default (or unauthenticated)
> principle name is hardcoded to "guest". We could easily make that
> configurable if you wanted to supply a patch for it. We'd be happy to
> commit it so everyone could get the improvement in the next release.
>
> Your other security related patch was pretty good, this fix should be
> pretty easy. You'd just need to add a getter and setter for defaultUser in
> AbstractSecurityService.java, then update each of the service-jar.xml files
> from this:
>
> <ServiceProvider
> id="Default Security Service"
> service="SecurityService"
> types="SecurityService"
>
> class-name="org.apache.openejb.core.security.SecurityServiceImpl"/>
> to this:
>
> <ServiceProvider
> id="Default Security Service"
> service="SecurityService"
> types="SecurityService"
> class-name="org.apache.openejb.core.security.SecurityServiceImpl">
>
> DefaultUser = "guest"
> </ServiceProvider>
>
> Then people would be able to configure the default user name.
>
> Let us know if you're up to implementing the feature.
>
> -David
>
>
Re: Unauthenticated principal
Posted by David Blevins <da...@visi.com>.
On Dec 18, 2008, at 7:44 AM, Luis Fernando Planella Gonzalez wrote:
> Luis Fernando Planella Gonzalez escreveu:
>> HI.
>> I'm using openejb under tomcat (with openejb.war).
>> I implemented a custom Tomcat Realm, and everything was going fine,
>> but I found one problem:
>> I need to use a role name ("public") as the unauthenticated user,
>> but I didn't find out how to do this...
>> After some deep debugging, I found out that I could, at some point,
>> call SystemInstance.get().setComponent(RoleResolver.class, new
>> Something()), being something a class that returns the "public"
>> role when no roles are available. But it just don't smell well to me.
>> There must be a better way.
>> Any thoughts?
>>
>
> Why anybody has answers to more complicated questions? ;)
More like slipped through the cracks :)
> I'll leave it with
> SystemInstance.get().setComponent(RoleResolver.class,
> ...) for now, but I'm sure there's a better way...
> I've found that some web pages states about a security namespace,
> which
> has a default-principal tag, but that's for geronimo.
Right, not applicable here.
> How to configure it in the tomcat integration? I'm sure there's a
> way to
> do it...
Right now in the AbstractSecurityService, the default (or
unauthenticated) principle name is hardcoded to "guest". We could
easily make that configurable if you wanted to supply a patch for it.
We'd be happy to commit it so everyone could get the improvement in
the next release.
Your other security related patch was pretty good, this fix should be
pretty easy. You'd just need to add a getter and setter for
defaultUser in AbstractSecurityService.java, then update each of the
service-jar.xml files from this:
<ServiceProvider
id="Default Security Service"
service="SecurityService"
types="SecurityService"
class-
name="org.apache.openejb.core.security.SecurityServiceImpl"/>
to this:
<ServiceProvider
id="Default Security Service"
service="SecurityService"
types="SecurityService"
class-
name="org.apache.openejb.core.security.SecurityServiceImpl">
DefaultUser = "guest"
</ServiceProvider>
Then people would be able to configure the default user name.
Let us know if you're up to implementing the feature.
-David
Re: Unauthenticated principal
Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.
Why anybody has answers to more complicated questions? ;)
I'll leave it with SystemInstance.get().setComponent(RoleResolver.class,
...) for now, but I'm sure there's a better way...
I've found that some web pages states about a security namespace, which
has a default-principal tag, but that's for geronimo.
How to configure it in the tomcat integration? I'm sure there's a way to
do it...
Tks.
Luis Fernando Planella Gonzalez
lfpg.dev@gmail.com
Luis Fernando Planella Gonzalez escreveu:
> HI.
> I'm using openejb under tomcat (with openejb.war).
> I implemented a custom Tomcat Realm, and everything was going fine,
> but I found one problem:
> I need to use a role name ("public") as the unauthenticated user, but
> I didn't find out how to do this...
> After some deep debugging, I found out that I could, at some point,
> call SystemInstance.get().setComponent(RoleResolver.class, new
> Something()), being something a class that returns the "public" role
> when no roles are available. But it just don't smell well to me.
> There must be a better way.
> Any thoughts?
>