Question about best practice regarding release of deprecated encodings

[Bellina, Brendan]

My understanding is that the resolver is not SP specific, so you define
each encoder you need within it.  An example of one demonstrating what I
am talking about would have encoder lines like so:

<resolver:AttributeEncoder xsi:type="SAML1String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                        name="urn:mace:dir:attribute-def:sn" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                        name="urn:oid:2.5.4.4" friendlyName="sn" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                        name="urn:mace:dir:attribute-def:sn"
friendlyName="sn" />

In this case a SAML2 SP is going to get duplicated values of sn if it
accepts both of the SAML2String encodings defined, which it may want to do
because it has one IdP giving it OID and another giving it URN. I am
asking if there is a way in the attribute release policy to indicate that
for a specific SP I only want to use one of the SAML2String encodings, not
both of them?


Regards,

Brendan Bellina
Identity Mgmt. Architect, IT Services, UCLA


On 11/10/15, 12:47 PM, "users on behalf of Cantor, Scott"
<users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>
>
>
>
>
>On 11/10/15, 3:25 PM, "users on behalf of Peter Schober"
><users-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at>
>wrote:
>
>>* Bellina, Brendan <bbellina at ucla.edu> [2015-11-10 21:03]:
>>> If the above is a reasonable approach, then would custom attributes be
>>> used, one for each encoding, or is there a way in the release rule to
>>> restrict release to a specific encoding so as to avoid duplicates?
>>
>>The IDP already handles that case in the examples shipped with the
>>software, e.g.:
>>
>>   <resolver:AttributeDefinition id="givenName" xsi:type="ad:Simple"
>>sourceAttributeID="givenName">
>>     <resolver:Dependency ref="myLDAP" />
>>     <resolver:AttributeEncoder xsi:type="enc:SAML1String"
>>name="urn:mace:dir:attribute-def:givenName" />
>>     <resolver:AttributeEncoder xsi:type="enc:SAML2String"
>>name="urn:oid:2.5.4.42" friendlyName="givenName" />
>>   </resolver:AttributeDefinition>
>
>Right, you would literally have to deliberately (and for reasons that I
>can't imagine) add two more encoders that reversed the protocol/name
>association.
>
>There's no scenario I can imagine for which that "fixes" a problem. If
>the SP doesn't support SAML 2 correctly (which happens), so be it. You
>don't break your IdP to accomodate it. There's no reason to.
>
>-- Scott
>
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net