I'm not sure I understand. But right now the SAML2 version of ePTID can be
sent in SAML1. IdPs are encouraged to produce it for SAML1 and SPs are
encouraged to understand both old and new.
Note however that when stripped of all the syntactic sugar the value is the
same and so you can massage one into the other,
http://svn.middleware.georgetown.edu/view/cpp-sp/branches/REL_2/configs/attr
ibute-map.xml?view=markup
gives some insight into how Shib2 worries about this...
There is definitely the possibility that when people start using SAML2 (we
still use a WAYF so I'm guessing that most traffic is SAML1) misconfigured
SPs may "lose" personalization.
> -----Original Message-----
> From: Discussion list for Shibboleth developments [mailto:JISC-
> [log in to unmask]] On Behalf Of Alistair Young
> Sent: 24 February 2010 14:03
> To: [log in to unmask]
> Subject: Re: Implications of SAML2
>
> thanks Rod and Peter. It's the SP side of things I'm worried about. It
> will see a different attribute from eduPersonTargetedID, i.e. it'll
> see the SAML2 version. I was just wondering if that could cause
> personalisation problems at the SP, as although the value is the same,
> the name isn't and the scope is inline. I know some SPs do a bit of
> munging with ePTID to store personalisations.
>
> Alistair
>
>
> --
> mov eax,1
> mov ebx,0
> int 80h
>
>
>
>
> On 24 Feb 2010, at 13:58, Rod Widdowson wrote:
>
> > Alistair,
> >
> > FWIW the Shib IdP explicitly handles this behaviour and you specify
> > the
> > attribute name depending on whether you are doing SAML1 or SAML2. The
> > distro supplies the defaults.
> >
> > ePSA
> > SAML1:
> > name="urn:mace:dir:attribute-
> > def:eduPersonScopedAffiliation"
> > SAML2:
> > name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9"
> > ePTID:
> > SAML1:
> > name="urn:mace:dir:attribute-def:eduPersonTargetedID"
> > *AND*
> > name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
> > SAML2:
> > name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
> > *ONLY*
> > ePPN:
> > SAML1:
> > name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
> > SAML2:
> > name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
> >
> > ePE:
> > SAML1:
> > name="urn:mace:dir:attribute-def:eduPersonEntitlement"
> > SAML2:
> > name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7"
> >
> > If you need anything else I would collect
> >
http://svn.middleware.georgetown.edu/view/java-idp/trunk/resources/conf/attr
> > ibute-resolver.xml?view=markup&pathrev=2712 and use that as reference
> >
> > Hth
> >
> > /r
> >
> >> -----Original Message-----
> >> From: Discussion list for Shibboleth developments [mailto:JISC-
> >> [log in to unmask]] On Behalf Of Alistair Young
> >> Sent: 24 February 2010 10:46
> >> To: [log in to unmask]
> >> Subject: Implications of SAML2
> >>
> >> Hi folks,
> >>
> >> Does anyone know of any possible access implications of broadcasting
> >> support for SAML2 in IdP metadata? Most entities at the moment use
> >> "shibboleth" attributes, i.e. eduPerson but these don't exist in the
> >> SAML2 attribute profile. The same values are sent in different
> >> formats
> >> from eduPerson.
> >> Just wondering if this may have an impact on personalisations at SPs.
> >>
> >> thanks,
> >>
> >> Alistair
> >>
> >>
> >> --
> >> mov eax,1
> >> mov ebx,0
> >> int 80h
|