You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Wendy Smoak <ja...@wendysmoak.com> on 2005/04/08 19:41:11 UTC
Tomcat user 'roles' question
The only exposure that I have to this is configuring tomcat-users.xml so I
can use the manager webapp, so please bear with me.
I've got several web front-ends for a non-JDBC database. There is a 'green
screen' (telnet) app running against the DB that uses a system of user
security classes to which different 'screens' are assigned. That data is
stored in the DB itself. We've fit the web front end into this system by
assigning each 'page' of the webapp a 'screen id', so that the admin can
define who sees what in a single place.
What I'm wondering is if there's any hope of using this data with the
existing request.isUserInRole() method. (The security classes are (loosely)
roles.) I only need to deal with authorization. Authentication is handled
separately by a Filter that redirects elsewhere to make them log in.
Can someone point me in the right general direction? Everything Google
turns up starts in with configuring a JDBC or JNDI realm, and I don't think
that part of it will ever work with this database. Would I end up defining
my own kind of a Realm?
Confused,
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Tomcat user 'roles' question
Posted by Jerome Jar <je...@gmail.com>.
Excellent reply :)
I guessed to write a customized UserDatabase just because it was there
in the server.xml, and indeed it took me some hours :(
On Apr 9, 2005 10:46 AM, Bill Barker <wb...@wilshire.com> wrote:
> Yeah, but writing your own custom UserDatabase is usually harder than
> writing your own custom Realm (at least four classes vs. one.). It does
> have the advantage that (in theory) it should work with the admin webapp
> ;-).
>
> Custom Realms really aren't all that hard. You typically create a class
> that extends RealmBase
> (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/realm/RealmBase.html,
> changing the '5.5' to the TC version you care about, unless it's 3.3 where
> the package is different). Then you override the 'getPassword(String)'
> (returns the db-password of the user), the 'getPrincipal(String)' (returns
> the userPrincipal for the user), and the 'getName()' (returns the name of
> the realm -- any identifying string). If you return anything but a
> o.a.c.realm.GenericPrincipal from getPrincipal, then you'll have to override
> the 'hasRole(Principal, String)' method as well.
>
> One strategy is to just do the above, and you are done. The other is to
> implement the required overrides (except 'getName') to return null, and
> override the 'authenticate(String, String)' method. Whichever works better
> with your DB.
>
> "Jerome Jar" <je...@gmail.com> wrote in message
> news:57fe892e0504081825459c8882@mail.gmail.com...
> >I think you can modify the "UserDatabase" part in server.xml, to
> > change the authentiation to use in your own way.
> >
> > On Apr 9, 2005 1:41 AM, Wendy Smoak <ja...@wendysmoak.com> wrote:
> >> The only exposure that I have to this is configuring tomcat-users.xml so
> >> I
> >> can use the manager webapp, so please bear with me.
> >>
> >> I've got several web front-ends for a non-JDBC database. There is a
> >> 'green
> >> screen' (telnet) app running against the DB that uses a system of user
> >> security classes to which different 'screens' are assigned. That data is
> >> stored in the DB itself. We've fit the web front end into this system by
> >> assigning each 'page' of the webapp a 'screen id', so that the admin can
> >> define who sees what in a single place.
> >>
> >> What I'm wondering is if there's any hope of using this data with the
> >> existing request.isUserInRole() method. (The security classes are
> >> (loosely)
> >> roles.) I only need to deal with authorization. Authentication is
> >> handled
> >> separately by a Filter that redirects elsewhere to make them log in.
> >>
> >> Can someone point me in the right general direction? Everything Google
> >> turns up starts in with configuring a JDBC or JNDI realm, and I don't
> >> think
> >> that part of it will ever work with this database. Would I end up
> >> defining
> >> my own kind of a Realm?
> >>
> >> Confused,
> >> --
> >> Wendy Smoak
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Tomcat user 'roles' question
Posted by Bill Barker <wb...@wilshire.com>.
"Wendy Smoak" <ja...@wendysmoak.com> wrote in message
news:010f01c53d36$04128ca0$020ea8c0@imbrium1...
> From: "Bill Barker" <wb...@wilshire.com>
>> Custom Realms really aren't all that hard. You typically create a class
>> that extends RealmBase
>> (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/realm/RealmBase.html,
>> changing the '5.5' to the TC version you care about, unless it's 3.3
>> where the package is different). Then you override the
>> 'getPassword(String)' (returns the db-password of the user), the
>> 'getPrincipal(String)' (returns the userPrincipal for the user), and the
>> 'getName()' (returns the name of the realm -- any identifying string).
>> If you return anything but a o.a.c.realm.GenericPrincipal from
>> getPrincipal, then you'll have to override the 'hasRole(Principal,
>> String)' method as well.
>
> Thank you, that gives me a place to start. But I don't want to
> _authenticate_ the user at all... that's done elsewhere (one of two
> different places, actually,) and handled by a Filter. And yet I realize
> that somehow Tomcat has to know who the user is. :/
>
> If I create a realm and configure it, will I be able to circumvent the
> user getting prompted for a userID and password? Can I (in the Filter)
> place a GenericPrincipal object in the session under some key? I'm really
> only after the programmatic security of isUserInRole(...) here, but would
> like to stick to the standard way of doing things as much as possible.
>
The Realm will populate the 'userRoles' only if they are accessing a
protected page (one that is under a <security-contraint>), so it doesn't
change prompting. And, no, a normal Filter can't set the userPrincipal,
since that requires access to Tomcat internals.
You could use a Valve, but it sounds like for what you want, you could
simply wrap the HttpServletRequest in your Filter with a wrapper that
overrides isUserInRole. If anything, this would be more 'the standard way',
since then your app would also be portable to another Servlet Container.
> --
> Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Wrapping a Request (was Re: Tomcat user 'roles' question)
Posted by Wendy Smoak <ja...@wendysmoak.com>.
(Apologies for the repost a minute ago... wrong button.)
From: "Wendy Smoak" <ja...@wendysmoak.com>
> Wrapping the request sounds like a good way to go, but I'm on Tomcat 4.1
and
> the HttpRequestWrapper appears to be deprecated without suggesting a
> replacement:
>
>
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/docs/api/org/apache/catalina/connector/HttpRequestWrapper.html
>
> Should I use something else?
Apparently...
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/servletapi/javax/servlet/http/HttpServletRequestWrapper.html
So, in my Filter, I have:
HttpServletRequestWrapper wrappedRequest = new MyRequestWrapper(
request );
chain.doFilter( wrappedRequest, response );
and
public class MyRequestWrapper extends HttpServletRequestWrapper { ... }
Google didn't turn up any examples, so I'm feeling my way through this.
Please yell if I've gotten off on the wrong track,(otherwise I'll be back
when something stops working...)
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Wrapping a Request (was Re: Tomcat user 'roles' question)
Posted by Wendy Smoak <ja...@wendysmoak.com>.
----- Original Message -----
From: "Wendy Smoak" <ja...@wendysmoak.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Monday, April 11, 2005 9:59 AM
Subject: Wrapping a Request (was Re: Tomcat user 'roles' question)
> Bill Barker wrote:
> > You could use a Valve, but it sounds like for what you want, you could
> > simply wrap the HttpServletRequest in your Filter with a wrapper that
> > overrides isUserInRole.
>
> Wrapping the request sounds like a good way to go, but I'm on Tomcat 4.1
and
> the HttpRequestWrapper appears to be deprecated without suggesting a
> replacement:
>
>
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/docs/api/org/apache/catalina/connector/HttpRequestWrapper.html
>
> Should I use something else?
>
> --
> Wendy Smoak
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Wrapping a Request (was Re: Tomcat user 'roles' question)
Posted by Wendy Smoak <ja...@wendysmoak.com>.
Bill Barker wrote:
> You could use a Valve, but it sounds like for what you want, you could
> simply wrap the HttpServletRequest in your Filter with a wrapper that
> overrides isUserInRole.
Wrapping the request sounds like a good way to go, but I'm on Tomcat 4.1 and
the HttpRequestWrapper appears to be deprecated without suggesting a
replacement:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/docs/api/org/apache/catalina/connector/HttpRequestWrapper.html
Should I use something else?
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Tomcat user 'roles' question
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Bill Barker" <wb...@wilshire.com>
> Custom Realms really aren't all that hard. You typically create a class
> that extends RealmBase
> (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/realm/RealmBase.html,
> changing the '5.5' to the TC version you care about, unless it's 3.3 where
> the package is different). Then you override the 'getPassword(String)'
> (returns the db-password of the user), the 'getPrincipal(String)' (returns
> the userPrincipal for the user), and the 'getName()' (returns the name of
> the realm -- any identifying string). If you return anything but a
> o.a.c.realm.GenericPrincipal from getPrincipal, then you'll have to
> override the 'hasRole(Principal, String)' method as well.
Thank you, that gives me a place to start. But I don't want to
_authenticate_ the user at all... that's done elsewhere (one of two
different places, actually,) and handled by a Filter. And yet I realize
that somehow Tomcat has to know who the user is. :/
If I create a realm and configure it, will I be able to circumvent the user
getting prompted for a userID and password? Can I (in the Filter) place a
GenericPrincipal object in the session under some key? I'm really only
after the programmatic security of isUserInRole(...) here, but would like to
stick to the standard way of doing things as much as possible.
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Tomcat user 'roles' question
Posted by Bill Barker <wb...@wilshire.com>.
Yeah, but writing your own custom UserDatabase is usually harder than
writing your own custom Realm (at least four classes vs. one.). It does
have the advantage that (in theory) it should work with the admin webapp
;-).
Custom Realms really aren't all that hard. You typically create a class
that extends RealmBase
(http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/realm/RealmBase.html,
changing the '5.5' to the TC version you care about, unless it's 3.3 where
the package is different). Then you override the 'getPassword(String)'
(returns the db-password of the user), the 'getPrincipal(String)' (returns
the userPrincipal for the user), and the 'getName()' (returns the name of
the realm -- any identifying string). If you return anything but a
o.a.c.realm.GenericPrincipal from getPrincipal, then you'll have to override
the 'hasRole(Principal, String)' method as well.
One strategy is to just do the above, and you are done. The other is to
implement the required overrides (except 'getName') to return null, and
override the 'authenticate(String, String)' method. Whichever works better
with your DB.
"Jerome Jar" <je...@gmail.com> wrote in message
news:57fe892e0504081825459c8882@mail.gmail.com...
>I think you can modify the "UserDatabase" part in server.xml, to
> change the authentiation to use in your own way.
>
> On Apr 9, 2005 1:41 AM, Wendy Smoak <ja...@wendysmoak.com> wrote:
>> The only exposure that I have to this is configuring tomcat-users.xml so
>> I
>> can use the manager webapp, so please bear with me.
>>
>> I've got several web front-ends for a non-JDBC database. There is a
>> 'green
>> screen' (telnet) app running against the DB that uses a system of user
>> security classes to which different 'screens' are assigned. That data is
>> stored in the DB itself. We've fit the web front end into this system by
>> assigning each 'page' of the webapp a 'screen id', so that the admin can
>> define who sees what in a single place.
>>
>> What I'm wondering is if there's any hope of using this data with the
>> existing request.isUserInRole() method. (The security classes are
>> (loosely)
>> roles.) I only need to deal with authorization. Authentication is
>> handled
>> separately by a Filter that redirects elsewhere to make them log in.
>>
>> Can someone point me in the right general direction? Everything Google
>> turns up starts in with configuring a JDBC or JNDI realm, and I don't
>> think
>> that part of it will ever work with this database. Would I end up
>> defining
>> my own kind of a Realm?
>>
>> Confused,
>> --
>> Wendy Smoak
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Tomcat user 'roles' question
Posted by Jerome Jar <je...@gmail.com>.
I think you can modify the "UserDatabase" part in server.xml, to
change the authentiation to use in your own way.
On Apr 9, 2005 1:41 AM, Wendy Smoak <ja...@wendysmoak.com> wrote:
> The only exposure that I have to this is configuring tomcat-users.xml so I
> can use the manager webapp, so please bear with me.
>
> I've got several web front-ends for a non-JDBC database. There is a 'green
> screen' (telnet) app running against the DB that uses a system of user
> security classes to which different 'screens' are assigned. That data is
> stored in the DB itself. We've fit the web front end into this system by
> assigning each 'page' of the webapp a 'screen id', so that the admin can
> define who sees what in a single place.
>
> What I'm wondering is if there's any hope of using this data with the
> existing request.isUserInRole() method. (The security classes are (loosely)
> roles.) I only need to deal with authorization. Authentication is handled
> separately by a Filter that redirects elsewhere to make them log in.
>
> Can someone point me in the right general direction? Everything Google
> turns up starts in with configuring a JDBC or JNDI realm, and I don't think
> that part of it will ever work with this database. Would I end up defining
> my own kind of a Realm?
>
> Confused,
> --
> Wendy Smoak
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org