> Unfortunately, I am going to have to do a lot of
> reading about jsr 196 before I can begin to write an
> authentication module for it.
it is actually quite simple to do this but we can leave that for now.
> I guess I don't understand or I did not explain the
> issue well enough. seam is calling the GF
> LdapLoginModule.
pelase be specific as to how seam is calling the login module.
Are we not talking about a login occuring within the Glassfish
Appserver, in order to authenticate a caller?
I am not calling the seam login
> module at all. The concept of an intermediate login
> module is interesting, but I need a little more
> clarity.
>
> By this are you meaning that I should write a login
> module that in effect only verifies that the user has
> submitted username and password credentials. Then the
> commit method would set the required password
> credential on the subject so that the LDAP login
> module can properly authenticate? I believe that I
> can do this, but the PasswordCredential constructor
> requires the realm name, how would I get this from
> within the custom LoginModule.
before we continue, we need to work out the use model.
so please make that as clear as possible. I though you just wanted to use the
seam login module. maybe you want to use the seam login module for authentication, and the ldap module for group info. It would definitely help if you can clarify.
fwiw, what you write above was not exactly what I was recommending. Maybe the difference is due to a difference is what I presumed to be the use model, and the problem that nIthough eeded to be solved. I thought you needed to be able to get the username and password in your seam login module via the callback handler, and that the way things work in glassfish, there is a problem, in that a competent cbh is not passed through to the login modules; so I suggested that you create a helper in front of your login module, to provide a cbh, that would return the username and password values by exploiting the correponding attributes defined by the glassfish realm contract.
Your login module would presumably add caller and group principals to a subject. In addition to providing the cbh, the bridge would need to know how to look into the subject and find the caller and group principals, and pass them back through the interfaces of the glassfish realm interface.
> You stated, "As you know they use the jaas interfaces
> in a "special" and yet public way; which we need to
> honor for backward compatability reasons." what do
> you mean?
pluggable realms are an advertised integration interface; so we have to retain backward compatability; which can limit the options available to us, to support the type of things I think you want to do.
>
> The AppservPasswordLoginModule could have a flag that
> would enable it to look for the username and password
> in the callback or as a Private Credential, thus
> enabling JAAS compatible or backwards compatibility
> modes. The problem is that the module violates the
> manner in which a JAAS login module is supposed to
> function according to the interface's javadocs.
> Although after digging into the implementation
> javadocs one clearly sees that this is true as it is
> commented as such, but when reading the javadocs for
> the interface and how it is supposed to function this
> becomes very confusing.
imo, jass is not a good match for pluggable authentication on the server side.
that said, its use in this capacity is a fact of life,in most appservers.
the key problem, imo, is that jaas does not differentiate principals within the subject, and we need a way for the login module to pass back caller and group principals in a form that is compatible with the container's representation of the caller and group principals.
if you look at our realm interface, you could come to the conclusion that most of its departure form jass was done specifically so that it could return a list of gorup names; which appears to be an element of your use model as well.
imo, the role of the intermediate would be to extract the caller and group principals and return them to the container, and to provide a suitable cbh for login modules that depend on username and password callbacks.
Ron
>
> -- Chad
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=275518