On Wed, Sep 16, 2009 at 2:04 PM, Peter Ledbrook <[email protected]> wrote: >> I propose that we add a 'getPrimaryPrincipal()' method to the >> PrincipalCollection interface. > > I do like this option. With regard to Alan's comment, the primary > principal is (in my view) something that's important to the > application, not to the realms.
I agree - and we've got that covered by the Subject#getPrincipal() method. However, our implementation of that method just returns the PrincipaCollection's first iterated element. There is no control for an Realm implementor to specify what the primary would be other than our heuristic. > So the application should decide what > constitutes the primary principal. Of course, I guess realms can also > have their own primary principal, so there's a possibility for > confusion here. I think there would only be confusion in a multi-realm configuration. In a single-realm configuration, the Subject#getPrincipal() implementation would just delegate to singleRealmPrincipalCollection#getPrimaryPrincipal(). But in a multi-realm scenario, the AuthenticationStrategy#afterAllAttempts method has the final say as to what PrincipalCollection backs the Subject after login. I suspect the person performing application-wide configuration would specify a custom AuthenticationStrategy to control what is the aggregate PrincipalCollection's primary principal should be if they didn't like our existing heuristic. Is that a good enough solution if adding a getPrimaryPrincipal() method?
