[Craig] >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 Realm.java, Realmbase.Java and some of the xxxAuthenticator.java files would need to be changed. Thanks Vinay __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
