best practice for authentication and role assignation.

[alexandre russel]

I am using jboss4. I set it up so it check password with my LDAP. Now I want it to get the user role in a database but only the role(not checking the password once again because password are only stored in the LDAP).

from the jboss documentation:
It's often the case that a local LDAP server provides identity and authentication services but is unable to use the authorization services. This is because application roles don't always map well onto LDAP groups, and LDAP administrators are often hesitant to allow external application-specific data in central LDAP servers. For this reason, the LDAP authentication module is often paired with another login module, such as the database login module, that can provide roles more suitable to the application being developed.

but chapter 8.4.6.4 says about the databaseLoginModule:
You would use this login module if you have your username, password and role information relational database
My question:
How can I use the databaseLoginModule just to retrieve role or what module should I use to do so? I don't have the password in the database.
If not possible where and how should I assign a role to the user?

thanks in advance for help, link or anything usefull.

PS: I already posted to the jboss forum with no response. Appologies if someone had to read twice about my problem.

[Reid M. Pinchback]

Are you in a situation where you know that you aren't going
to be able to map logical roles to LDAP groups? I'm not
sure I agree with the degree of emphasis that JBoss
group statement places on the issue. I can think of
situations I've seen where it would be true, and situations
where it would definitely be false. Even if it were
true in your case, I would be hesitant to reflect in your
application code that this is happening, it would better
to write a JAAS provider to hide it.

[alexandre russel]

Reid thanks for your answer. My post wasn't really clear. In my company, the LDAP administrator doesn't want role to be mapped into the LDAP.
When you say "it would better to write a JAAS provider to hide it."
Do you mean write my own login module like in:
http://docs.jboss.org/jbossas/jboss4guide/r3/html/ch8.chapter.html#ch8.custom.sect
Another question (it is why my topic says best practices):
Once I checked password with LDAP, checked role with database I still need to get the id of the user(in LDAP) map it to an EJB Bean(made from another DB) and make that EJB a session Bean. Do you think those task still belongs to a jaas module or to the application controller or where...?

Alex.
PS: I order Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management, I hope everything is inside or I will have to ask Kathy and Bert to write the Head First J2EE Security ;-)

[Reid M. Pinchback]

Ah, ok now I get it.

JAAS has two pieces. A login (aka authentication) piece, and an authorization piece. In your case you want the former to be LDAP, and the latter to not be LDAP. You have one other decision to make.

For your application, you have to decide what you want from your roles, because that will determine if it makes sense for you to write your own authorization module.

There are three ways to use roles:

declarative use of roles

programmatic use of a single role at a time

programmatic use of multiple roles at a time

The first way corresponds to how security managers work. Let the user try to do something, and if they aren't supposed to an exception is thrown.

The second way lets you do the usual "context.isCallerInRole(X)" stuff. Useful if you want to change behaviour based on (typically a single) role. Example would be providing or hiding some info on a web page based on whether or not the user is an "admin" or not.

The third way comes up when you want to answer the questions "what are all the roles of the current user?" or "what are all the users and their corresponding roles?". Example usage would be to have a web page that allowed "admin" users of your application to maintain user and role info.

Writing a JAAS authorization module helps with the first two and is arguably the best solution for the first two. For the third you have a choice. You could use entity beans to look into the database tables directly, or you could still do JAAS but use more of the security API directly in your EJBs instead of just the smidgeon exposed through EJBContext. Whichever approach you take, the thing you have to watch out for is performance drag. I've seen applications pound themselves into the dust by continually re-reading security information from the database.