tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinay Sajip <>
Subject Re: Problems with Tomcat4 Security Design
Date Sun, 27 Oct 2002 08:55:03 GMT
>Sounds like you really should write a custom
Authenticator that doesn't
>use the standard Realm back end.  Nothing requires
you to do that -- 
>and,since you'd need a custom Realm anyway, you might
as well just combine
>everything into a single class.

Of course I can do this, but it looks as if the way is
littered with roadblocks: I can't install an
AbstractAuthenticator subclass at anything above the
Context level, because it throws an exception. So it
looks as if I would have to copy and paste quite a lot
of logic from AbstractAuthenticator into my custom
class, or is there a better way? Also, if I want to
have the freedom of choosing any auth-type for a
particular context, how can this easily be achieved
without copying relevant logic from the
xxxAuthenticator classes? 

>By the way, Tomcat has standard support for single
sign on.  The actual
>implementation of this won't help you, but the design
addresses one of
>your concerns.  You embed the <Valve> element that
implements this in 

Yes, I know about this. I got SSO working with my
custom realm, using the standard Tomcat valve, without
any trouble. All I want is to have access to the
request in the realm calls, so that I can stuff a
custom security token object from the realm into the
request. Is there some philosophical reason why the
request can't be passed in to the realm calls? How
would one go about making an official request for the
Realm API to be augmented? I'd be happy to submit a
patch, if that would help. It seems as if only, Realmbase.Java and some of the files would need to be changed.



Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message