Question about best practice regarding release of deprecated encodings

[Peter Schober]

* 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.

> 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.

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.)
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.)

> * 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).

> * 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.
-peter