On 09/12/11 18:02, [email protected] wrote:
Hi Chuck,
Thanks for the pointer to the CombinedRealm, but, as I've been working with the
test implementation that I mentioned for extending the JNDIRealm, I *think*
that I'm coming to the realization that I was asking for is probably not
possible, or at least not practical, unless I'm totally missing something.
The reason I'm thinking this is that, for example, in the case where I'm
extending the JNDIRealm, in my custom JNDIRealm, I've had to make calls to the
super.setXXXX() methods to set parameters in the JNDIRealm class that I'm
extending, in order for the calls that I then make to the super class (e.g.,
super.getUser()) to work.
Again, I may be missing something, or doing things completely wrong, but if not, then
that means that if I was going to try go design my realm extender to support all of the
normal realm types, my code would get fairly complex, because it'd have to
"know" all of the parameters for all of the different realm types, in order to
set the parameters in the super class. It was messy enough doing that for just one realm
type (JNDIRealm), and for just calling two methods in the super JNDIRealm class, but I
imagine if I was trying to extend 5 or 6 realm types, all in one piece of code, it'd be a
real mess.
Anyway, if anyone has some insight into doing something like this, please post
back.
Otherwise, I think the best approach is to implement one realm extension for
each of the normal Tomcat realms that we'll want to be able to support.
Thanks again,
Jim
I have come to this thread rather late in the day and I don't want to
confuse the situation... take my comment, if it is relevant, with
caution. If it isn't relevant, don't let me spiral it off-topic.
The servlet 3.0 spec allows for "vendor specific" <Login-config>
<auth-method> values, e.g. tomcat uses "NONE" for containers that have
not defined a <login-config> section.
The standard login methods (FORM, BASIC, etc) are implemented as
concrete classes that extend
org.apache.catalina.authenticator.AuthenticatorBase (e.g.
FormAuthenticator, BasicAuthenticator, etc).
Have you considered writing a "vendor specific" NoPasswordAuthenticator
class to do what you need? It needs to contain little more than an
authenticate method that will be called by all appropriate code.
I have just submitted a suggested fix to NonLoginAuthenticator
(https://issues.apache.org/bugzilla/show_bug.cgi?id=52303) which shows
how to inject an existing Principal instance into a SingleSignOn
session. This might give you some idea how to achieve what you want
without the complexity of subclassing all the standard realms.
Regards,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
