[JIRA] Closed: (IDP-69) AuthenticationEngine randomly selects a JAAS Principal from the authenticated Subject for purposes of producing the authenticated principal name

[Chad La Joie (JIRA)]

     [ https://issues.shibboleth.net/jira/browse/IDP-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chad La Joie closed IDP-69.
---------------------------

    Resolution: Invalid

The new authentication APIs now make this an impossibility.  An authentication workflow can produce one, and only one, Principal for the user and during attribute resolution the principal for the peer service is what will be used.

> AuthenticationEngine randomly selects a JAAS Principal from the authenticated Subject for purposes of producing the authenticated principal name
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: IDP-69
>                 URL: https://issues.shibboleth.net/jira/browse/IDP-69
>             Project: Identity Provider
>          Issue Type: Bug
>            Reporter: Brent Putman
>            Assignee: Chad La Joie
>            Priority: Minor
>
> This issue is discussed in users list thread:
> http://groups.google.com/group/shibboleth-users/browse_thread/thread/cf12d8d36fcb28d7#
> Basically, the AuthenticationEngine currently just pulls the first Principal from the authenticated Subject, for purposes of producing the authentication principal, which produces the authenticated principal name. This is an unordered set, so in case there are multiple principals this choice is non-deterministic.
> Chad makes the point above that all the Principals are valid and identify the user in some way. Not sure I agree with the latter (a group principal for example doesn't really "identify" the user, it represents a principal for purposes of access control and authZ. In particular, it can't be used as an identifier for looking up the user in our resolver in any meaningful way for our purposes). In any case, they are certainly not all all *equivalent*, and can not be interchanged. We specifically call out a concept of "principal name", which we expect to have some specific meaning and to be used in a specific way.
> Regardless of the subtleties of those JAAS interfaces, from a practical perspective currently the Principal type that gets used is random choice, which can vary even across requests. I think we should give the user a stable target to use in their resolver, etc, rather than a moving one.
> The attached patch does 2 things:
> 1) On the AuthenticationEngine, exposes a a new init param that allows the user to specify the Principal class name that is to be used for purposes of the "authentication principal" and the principal name. This defaults to edu.internet2.middleware.shibboleth.idp.authn.UsernamePrincipal if not set. Code then uses this to select the chosen Principal, rather than just getting the first one from the Set iterator.
> 2) UsernamePassword LoginHandler now always ensures that there is an instance of edu.internet2.middleware.shibboleth.idp.authn.UsernamePrincipal in the Subject principals set. Formerly it only added that if the Principals set was empty. This is mainly to support the default value in #1, which in turn is mainly for backward compatibility.
> This allows the user to have control over which Principal type gets selected, in conjunction with their choice of JAAS module and specific JAAS config.
> For the record #1 isn't an original thought: other JAAS calling code that I have seen (e.g. Tomcat JAASRealm) does the same thing, for purposes of distinguishing "username principals" from "role principals" from whatever else a JAAS module might produce. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira