thanks for the pointers Rod,
> misconfigured
> SPs may "lose" personalization
yes, that's what I'm worried about.
Alistair
--
mov eax,1
mov ebx,0
int 80h
On 24 Feb 2010, at 14:14, Rod Widdowson wrote:
> 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
|