|
[
Permlink
| « Hide
]
David Jencks added a comment - 23/Jul/05 06:27 AM
Basically, the problem is that getCallerPrincipal's behavior is undefined. We can't figure out an appropriate way to decide which of the 1001 principals in a subject should bet returned. If this is really important, make sure you login module only puts one principal into the Subject, containing the information you want to retrieve from the ejb.
I think we need to look at this issue in more detail. I believe the app servers I've used all managed to pick out the "user" principal to return from getCallerPrincipal, and every time I've used it it's been with the intention of identifying the login name of the current user. It seems that most login modules produce both a "user" and at least one "group" principal. We need to be able to figure out which principal class is "primary" and should be returned from getCallerPrincipal. It seems like this could be metadata we associate with the login module or realm.
What about having a special Geronimo class that is designated as by Geronimo as primary, then have a convention where a special login module would insert it into the subject? This way, people could have a variety of schemes to insert the primary principal by simply writing their own login module that followed the convention and we wouldn't have to have an "uber" metadata and code to handle all the different possibilities.
That works for me too. We could even make it an interface that extends Principal, so a custom LoginModule could either have one of their principal classes implement it or add a separate Gernoimo LoginModule that just adds a trivial implementation based on the login username (thus keeping the Geronimo interface out of an otherwise portable custom login module). I think it should be pretty obvious how to apply it to our own login modules. And when the server needs to reply to getCallerPrincipal, it can scan the principals and return the first one that implements that interface, or if none do, just the first principal it comes across.
Not going to make it into M4
Implemented by adding a GeronimoCallerPrincipal interface, making GeronimoUserPrincipal implement it, and returning it preferentially for getCallerPrincipal. Reuse of GeronimoUserPrincipal may possibly lead to confusion if there are several login modules all adding GeronimoUserPrincipal instances, but this seems somewhat unlikely.
Sending modules/security/src/java/org/apache/geronimo/security/ContextManager.java |
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Unable to determine username from EJB method
