Question about best practice regarding release of deprecated encodings

[Bellina, Brendan]

On 11/10/15, 10:04 AM, "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 18:07]:
>> For institutions that started with Shibboleth back with SAML 1 and
>> later upgraded to SAML 2 one of the complexities introduced with the
>> upgrade was the recommended switch from URN based attribute encoding
>> to OID based attribute encoding. Making that switch at the IdP in
>> the resolver could be done but to avoid user impact would have to be
>> coordinated with the SP's that were dependent on the deprecated
>> encoding formats. Since IdP's support multiple SP's and SP's work
>> with multiple IdP's there could remain reasons for some time why an
>> IdP would want to release deprecated formats as well as reasons why
>> an SP would need to accept them.
>
>The MACE-Dir SAML Attribute Profiles are pretty clear about this,
>calling urn:mace:dir:attriute-def: "legacy names" even for SAML1,
>including a MUST NOT for use of legacy names within SAML2.
>I.e., as an IDP you'd only ever release one variant to a given SP,
>depending on the protocol used.

Practically speaking that isn¹t going to always be the case.  ³MUST NOT²
is not compelling enough in all cases for all SP¹s who upgrade from SAML 1
to SAML 2.

>
>> A problem occurs though if an IdP is releasing multiple encodings of
>> an attribute (perhaps because it has some SP's relying on
>> URN-encoding and some relying on OID-encoding) if the SP receiving
>> the attribute is also configured to recognize multiple formats
>> (perhaps because one of its IdP's releases the URN-based encoding
>> and another releases OID-based).  In that case the attribute is
>> decoded twice at the SP and so it gets duplicate values, which is an
>> unintended consequence.
>
>Same if you were duplicating persistent NameID in the Assertion's
>Subejct element and as eduPersonTargetedID Attribute in the Attribute
>Statement (which the eduGAIN Attribute Profile still recommends,
>unfortunately). So don't do that.

Well, it happens though.

>
>If the IDP behaved the way the Shib IDP would by default (see below)
>the SP would only ever receive one of the formal attribute names
>(either the SAML1 or the SAML2 one, depending on the protocol version
>used) and is able to map that to the same internal attribute id,
>isolating the application from all that.
>
>> Having spoken with different folks at different institutions about
>> this there doesn't seem to be consensus on how best to migrate away
>> from the old encoding.  For new SP's one can define a version of the
>> attribute that only has the current encoding and release only that
>> to them, but if it is an older SP that may not be a viable
>> option.
>
>The Shibboleth IDP comes with example encoders out of the box that
>will do The Right Thing if activated/uncommented. (Use SAML1
>convention with SAML1 protocol, use SAML2 convention with SAML2
>protocol.)

SP¹s upgrading from SAML 1 may not agree to switch from URN¹s to OID.

>The Shibboleth SP is able to map either of those to the same internal
>attribtue id, so it's all peachy *unless* you go about "fixing" it in
>the way proposed, by sending both name formats always (violating the
>eduPerson specs, if eduPerson attributes are affected, in the
>process.)

³Violation² seems like a pretty harsh word for variant behavior with the
eduPerson specs.  The eduPerson specs were never cast in stone and were
usually considered more experimental than dogmatic. But we should probably
discuss this topic over pints sometime.

>
>> * An IdP should have defined in the resolver all of the encoding
>> formats that it has ever had to release to any SP (URN, OID, and
>> whatever may come next).  When a new encoding scheme becomes
>> standard then the IdP can update their resolver at any time, just
>> adding the new encoding to the attributes but not removing the old
>> encodings.
>
>That's just what the Shib IDP does (default examples in the resolver).

Yes, but without the second bullet below this can lead to the duplicates
problem I describe.

>
>> * An SP should specify a preference list for the encodings of an
>> attribute that it receives. Those preferences might be SAML2 OID is
>> preferred over SAML2 URN which is preferred over SAML1 URN.  Then
>> when it receives multiple encodings it discards all but the most
>> preferred.  So when an SP wants to indicate that it now prefers a
>> new encoding format it can updates its configuration independently
>> of the IdP's When the IdP's start sending the new format the SP will
>> handle it fine, but if they don't it will continue to work with the
>> old ones.
>
>Not sure that's possible in an abstract, easily doable way, but could
>still be done in the Shib SP using the attribute-policy.xml
>But it shouldn't be neccessary unless IDPs did The Wrong Thing and
>always sent both formats.

There is only what works and what doesn¹t work. In the real world IdP¹s do
not always (ever?) have the luxury of enforcing standards on SP vendors.

I¹ll look at the attribute-policy.xml.  I am surprised that with all of
the early adopters who must have run into this problem there is nothing
posted as to how to handle it in a way that least impacts users and SP¹s.

>-peter

Regards,

Brendan