Question about best practice regarding release of deprecated encodings

[Bellina, Brendan]

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.

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.

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. For existing SP's it seems to be a communication and coordination effort that is required, getting them to switch to OID-based just at the same time that you switch the resolver to release only OID to them, which doesn't scale well when you have hundreds of SP's.

I think there is a scalability concern anytime that a technology change results in a major communication and coordination effort. These things generally do not happen quickly or well.  It would be better if the changes desired at the IdP - to update the resolver with new encoding - could be implemented independently of the changes at the SP's, and even if desired changes at the SP - to accept a new encoding of an attribute - could be implemented independently of the IdP's.  Now if there is a simple way to do this already that I am not aware of, then great and could someone please point me to the page in the wiki that describes that because I found nothing.

What I imagined might exist would be something like this...

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

Independence and removal of the need for coordination between the IdP's and SP's is the benefit of this approach, but it also resolves the duplicate attributes issue.

I hope this makes some sense.  I am not a skilled Shibboleth administrator so my Shibboleth-fu is weak and perhaps I am analyzing a problem that really doesn't exist or was solved by others.  If so, please direct me to appropriate documentation or best practice.

Regards,

Brendan Bellina
Identity Mgmt. Architect, IT Services, UCLA


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151110/d0ee26e6/attachment.html>