Advice on planned IdP configuration changes associated with implementing SAML 2

[Cantor, Scott]

On 9/11/13 10:25 AM, "Julian Williams" <julian.williams at it.ox.ac.uk> wrote:

>As you can appreciate this is long overdue but the last time it was
>attempted here (2011) we had problems with a number of SPs/applications
>and had to back-out the change. The problems we had last time seem to be
>associated with the eduPersonTargetedID not being provided in SAML2
>connections.

I'd be shocked if that were the only issue, but this may depend on the
nature of your SPs. In my case, we had a number of vendors involved, and
many were using non-Shibboleth software. And even the Shibboleth cases
were broken in some cases. Each one was a case by case analysis of the
potential issues and involved a lot of external probing and deduction of
their configuration.

It sounds like you don't believe this is the case, and have focused in on
the specific mess of the ePTID encoding, but I don't want you to be
blindsided if that turns out to be the tip of the iceberg.

In my case, I don't support ePTID and I was mercifully able to avoid all
of what you're referring to.

>Unfortunately further progress has been stalled until recently because
>it's been difficult to arrange testing of other 3rd party applications
>against our test IdP.

I don't recommend that approach precisely because they have to alter
things to test them.

What I did, which may not apply to the UK, is to manipulate my InCommon
metadata to include a SAML 2 ArtifactResolutionService only, which causes
(in the InCommon case) my IdP metadata to include the necessary SAML 2
protocol support string, but with no SSO endpoint. That allowed me to push
transactions to an SP using the IdP's unsolicited SSO endpoint and probe
for problems ahead of time, before users are impacted. This was with the
same IdP users use, and doesn't require SP changes.

That alone still actually broke one SP running SimpleSAML, which still
concerns me, but it didn't affect the vast majority.

>We have realised now that the new type of eduPersonTargetedID (currently
>id="eduPersonTargetedIDNew") wasn't being included in the default release
>policy in attribute-filter.xml so that was the main reason why there
>wasn't any eduPersonTargetedID type attribute
>(urn:oid:1.3.6.1.4.1.5923.1.1.1.10) released once SAML2 connections were
>being used.

Even if you do that, that doesn't help you if the SPs are keying
information solely by the original/accidental scoped syntax.

>1. That there is no need to include a SAML2 encoding for the old type of
>scoped eduPersonTargetedID
>(urn:mace:dir:attribute-def:eduPersonTargetedID). >From what I have read
>it shouldn't be provided in a SAML2 request and SPs should be able to
>work without it provided they have the new type of eduPersonTargetedID.
>Or are there some instances where a 'legacy' SP/application might still
>have to get it?

There is no broken version defined for use with SAML 2, but having said
that, see above. If their application doesn't know how to deal with
anything else, that means something else has to give.

-- Scott