Shibboleth Developers

[Brent Putman <>]

On 11/30/10 8:26 PM, Paul Hethmon wrote:
>
> It may well be me not understanding the concept here. Since I am using a
> custom login handler, there is at most one principal a user can resolve to.
> I really don't understand the use case of having multiple principals to
> represent a user. I can see the multiple login handlers, but it seems with
> the exception of the IPAddress handler, that is would be likely for the
> other "standard" handlers to resolve to the same Principal.

I think it's really just a matter of terminology: in the Java JAAS
model, that we reuse here, there is only 1 Subject for a given user, but
that Subject may be represented by multiple Principals.  Other
frameworks might conceptualize that differently, I don't think it's
universal.

Given that, I think there's at least 2 cases for multiple Principals:

1) some login handlers, e.g. the JAAS one, might themselves produce
multiple Principals.  In the Java notion of Subject and Principal, a
Principal can be a role or a group or entitlement, something like that -
in other words doesn't uniquely identify a single user, rather
represents some aspect of the user's security context. (Actually, often
much like an "attribute"). Some JAAS providers produce multiple
principals in the Subject for that reason (and servlet containers with
JAAS support will use those role Principals to populate the servlet
request's role info, for example). 

2) in the case in the IdP where the user authenticates multiple times,
against multiple LoginHandlers, you can have multiple Principals, which
are distinct because the mechanism used does not identify the user in
the same way.  E.g. username vs Kerberos principal name vs. X.509
certificate subject DN.  So it's the same user, conceptually, but the
principals (and principal names) differ b/c of the differnt mechanisms
used.  (And this is precisely the point of the issue in SIDPT-38: even
if multiple authentication mechs and principals are used, we need a
single way to identify the user internally; when the internal "principal
name" changes over time, or randomly, it causes issues with various
internal operations of the IdP).


If you're using your custom login handler and only that single handler,
then you likely don't have to worry about multiple principals (except as
I already noted that the authentication engine, as a side effect,
produces a second principal when the previous session login handler is
invoked).


--Brent