InCommon Technical Discussions

["Paul B. Henson" <>]

On Wed, Jun 07, 2017 at 09:52:20PM +0000, Wessel, Keith wrote:

> I'm curious why so many are changing. That, in my mind, is the question.

I second that question; I had no problem with eduPersonTargetedID issues
after my upgrade; other than that attribute doesn't really exist anymore
conceptually 8-/.

For SAML2, the eduPersonTargetedID is basically the "persistent" NameID:

https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration

To avoid breaking SP's that you were previously releasing
eduPersonTargetedID to with idpv2, you need to configure idpv3 to use
it, and make you set the same source attribute and salt. I'm not 100%
sure it was required, but I also found a recommendation that you should
set a relying party override for those SP's to set the NameID
precedence, for example, mine is:

<bean parent="RelyingPartyByName"
      c:relyingPartyIds="#{{
                            'https://www.educause.edu/shibboleth-sp',
                            'https://shib.lynda.com/shibboleth-sp',
                            'https://federation.campuslabs.com/shibboleth',
                            'https://e5.onthehub.com',
                            'https://sso.smartsheet.com/saml',
                            'cpp.zoom.us'
                          }}">
    <property name="profileConfigurations">
        <list>
            <bean parent="SAML2.SSO"
                  
p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
 />
        </list>
    </property>
</bean>

You should follow up on the shibboleth users list with any more technical
questions, but the long and the short of it is that you should *not*
have any broken SP's or mismatched identifers after an idpv2 to idpv3
upgrade.

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  

California State Polytechnic University  |  Pomona CA 91768