Shibboleth Developers

[Brent Putman <>]

On 5/26/2010 8:41 AM, Chad La Joie wrote:
>
> - Clean up the behavior of the principal and authentication method
> attribute definition.  Since a user can have multiple principals and
> authentication methods it's not always clear exactly what you'll get
> from these definitions.  My current thinking is to always use the
> principal and authentication method established with whatever relying
> party the IdP is communicating. For example, if you log in in to SP A
> with a username/password and SP B with a cert then, the username is
> the principal returned by the definition when communicating with SP A
> and the subject DN of the cert is the principal returned by the
> definition when communicating with SP B.  In the cases where a single
> authentication method might result in multiple principal names some
> means for selecting the right one will be necessary and I'm not yet
> sure what the best way to do that is.  Probably a precedence list.


Absolutely agree that this is a problem.  This is somewhat related to an
issue I earlier opened:

https://bugs.internet2.edu/jira/browse/SIDPT-38

Some observations/counter-proposals:

1) The main problem with the current way of doing things (principal name
is non-deterministically selected when there's multiple authentications
over time) with respect to the attribute resolver is that it becomes
difficult/impossible to write resolver configurations against that.   If
say the IdP can authenticate users in 3 different ways, which produce
principal names in 3 different "formats" (for lack of a better word),
then you have a problem trying to use the principal name as the lookup
key to data sources, say LDAP or RDBMS.  You probably have to form the
query slightly differently depending on what kind of principal name you
have.  So for example, you might have to have 3 different LDAP data
connectors, with a slightly different filter constructions, and then
presumably run only one of them for a given request based on principal
name type, using the new conditional logic.  That's pretty messy and
complicated, IMHO.  I don't think the above proposal alone really
addresses this.  It makes it perhaps slightly more deterministic, but to
me it doesn't address the fundamental issue of resolver configs
vis-a-vis multiple principal name representations.

Alternatively, you could "canonicalize" the principal name (produced as
proposed above) within the resolver by using a Scriptlet or something,
and use this canonicalized form as the input to other things like data
connectors.  That general notion was pretty much what I was advocating
for in SIDPT-38, but:  I think the problem is broader than the attribute
resolver.  It cuts across multiple components, see more at end.


2) Somewhat stating the obvious but: It isn't always the case that, for
purposes of attribute resolution, the user is currently "logging into"
SP X (or has in the past).

  A) In the case of multiple authentications to 2 or more SP's followed
by SSO (via the PreviousSession login handler) to a new SP, it's not
clear what the principal name ought to be in that case since the user
didn't log in specifically for that SP (the authN method would
presumably be the previous session authN context URI).  You could make
up some algorithm (e.g. pick the principal associated with the
"strongest" authN method), but it would just be pretty arbitrary.

  B) It might be a SAML AttributeQuery (or some other non-SAML usage of
the attribute resolver, like the Grouper people want to do), where there
is not a presumption that there has been any previous act of
authentication by the user. In those cases would this new Principal
AttributeDefinition return a null value?  Presumably the principal name
is potentially available via a PrincipalConnector, but just noting that
that modifies the proposed definition.


3) I do think the "SP context sensitive" principal name and authN method
attribute definitions proposed above have value.  There may be cases
where you want to know and use that info in the resolver, or
particularly the attribute filter engine.  Using the same terminology,
though, I think that it's more common at least in the resolver itself
that you want the "IdP context sensitive" principal name, or perhaps
better stated, the "IdM system context sensitive" principal name or
identifier.  For example, I may have authenticated as
""
 (via Kerberos) or "cn=Brent Putman,o=Georgetown
University" (via an X.509 cert) - but what really matters is that I'm
"putmanb" in the IdM system (or parts thereof) and that's how I'm
commonly going to be identified in queries to the pieces of the IdM system.

 
I think that's true in the attribute resolver for sure, since it
directly interacts with the IdM system(s) at the institution, but also
true in other components in the IdP where we need to deal with the
concept of the "principal name". Not to go into details and stray from
the attribute resolver topic but there are many places where you'd
ideally want a normalized, consistent principal name, for a given user: 
logging (via MDC principalName variable), storage of state based on
principal name (persistent ID's, consent engine, etc).

So for me, the issue of principal name(s) and multiple authentications
with different methods is a first-order problem, and I believe requires
an IdP-wide solution.  I was proposing in SIDPT-38 a component that
produces a canonicalized principal name from a given authenticated
Subject. (Have also some code sitting around somewhere, I can upload
that at some point). I'm bringing it up here b/c it was primarily the
attribute resolver madness that engendered that idea.

--Brent