If you subclassed AbstractServerLoginModule,
you do not have to store ths data.
Your login module gets ( via callbacks ) username
( principal ) and password ( credential )
login() method just says OK to this combinaion,
and Group getRoleSets() returns assotiated roles.
Jboss stores Principal & credential somwhere out of your scope.
Yes, but that's just the username. I think the original question was, you access LDAP to retrieve all user information, including password. When you do the login stuff, the password gets verified.
But now, how do you access the other user data which may come from LDAP, like user's preferredLanguage etc.
Either, you can store an object somewhere during the login, but I don't see how ? Or, you have a later access to LDAP to get the other attributes, and this access is handled in an EJB. But this means I have to configure & handle my LDAP access at 2 different places : once in the auth.conf for JBossSX, and once in my application.
It would be better if these 2 needs, password checking & user attributes retrieval could be handled in a single step, I think this is what the first poster meant.
(Of course that might actually not be possible, because the password could be stored somewhere else or need to be accessed differently, with security, than the remaining attributes)
Other opinions regarding integration of LDAP data & EJBs ?
IMHO - no way. You'll have to lookup this information
later from LDAP.
Yes you were right. I meant exactly this. I am in need to store user information other than username and password somewhere to access it later instead of doing a second LDAP-Connection and search.
I am now thinking of storing that information somewhere in the JBoss namespace.
Any other ideas?
Well it's true that this need doesn't seem to fit the JAAS pattern. You authorize using one mechanism, perhaps even through a secure LDAP connection, so that password may be sent encrypted to LDAP for example.
And then, if authorization is OK, at a later time, you retrieve user information (other than password) from LDAP. For me, I wrote an EJBUserInfo which does this. The disadvantage is you have to go twice to LDAP and (worse), you have to configure your LDAP parameters in 2 different places ...
Storing the info in some static zone so that you avoid going to LDAP twice is probably not a good idea, in terms of architecture.
The information can be store in the Subject.getPublicCredentials or Subject.getPrivateCredentials depending on their sensitivity, or in JNDI.
You could store the user related data from LDAP in a stateful session bean and store a reference to SFSB in the HTTP session.