Question about best practice regarding release of deprecated encodings

[Cantor, Scott]

On 11/10/15, 12:06 PM, "users on behalf of Bellina, Brendan" <users-bounces at shibboleth.net on behalf of bbellina at ucla.edu> wrote:


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

There are SAML 1 names and SAML 2 names, and in some cases they overlap and some don't. Either way, there is absolutely no ambiguity whatsoever about what any attribute is called in either version.

I have never had a need to mis-name an attribute in that way. I've had to provide *custom* names, and in some cases I had to coordinate the protocol switch with a small number of SPs, but I've never had to apply a SAML 1 name to a SAML 2 interaction or vice versa.

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

These aren't "deprecated" formats, they're just invalid. SAML 1 isn't really deprecated. Its naming is clear in the profile, just like SAML 2's.

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

Yes, but since many attributes are multi-valued anyway, trying to shield applications from duplicates is a poor use of time IMHO, but I've said as much before.

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

You're not doing that, you're migrating a SAML 1 interaction to SAML 2. The names change (or not as the case may be, depends on the attribute) but you do NOT provide the wrong names. That would be the worst choice. You'd be better off just leaving it SAML 1.

>I think there is a scalability concern anytime that a technology change results in a major communication and coordination effort.

But this one did *not*. I know because I did it. It still took a long time, but that's only in absolute terms. In IT terms, it was quite smooth.

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

The transition to SAML 2 was managed exactly that way.

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

It can/does.

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

I wouldn't do that, but any Shibboleth SP is free to map names in SAML to any names it wants internally. If it wants to map them into different attribute names, it certainly can do that.

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

There are a couple of ways to approach the duplicate issue, which IMHO is really a manufactured issue, but to do it in the SP given the current design will involve expensive work on every request. Could be done, might get done, will definitely not be on by default, and I think would be foolish to use vs. just fixing application code.

But I would generally always tell anybody pulling data from headers to implement a wrapper that pulls from a list of headers, and if you do that, you can always map things separately the way you want to do. That happens to also address the problem.

I don't believe it would be productive to break the entire attribute mapping configuration people are used to to implement that in the SP, and if it were some kind of secondary format option, you wouldn't see any uptake, and so your problem would remain. The fact is that if somebody is too lazy to fix a simple bug in code, they're not going to fix it in the SP either. They just don't care. Caring a tiny bit is the solution to most problems and not caring is the cause of most of them.

-- Scott