Advice on planned IdP configuration changes associated with implementing SAML 2

[Julian Williams]

On 11/09/13 16:01, Cantor, Scott wrote:
> 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.

Thanks for the warning. I hope this isn't the case with us but we'll 
soon find out.

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

Yes well we are pretty sure that the problems we had last time with 2 
heavily used 'external' applications were caused by the lack of ePTID. 
We also use Shibboleth a lot internally where SPs will be using ePPN to 
identify users and there were no problems seen with any of those.

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

OK point taken. However in the last couple of days we have had a 
breakthrough and been able to test one of the SPs in this way and it's a 
relief that all worked fine, proving they can still use the ePTID that 
is provided with SAML2.

>
> 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's interesting and sounds very useful if we could do it. I'll have 
to check with the UK Federation but I suspect it will be to late for 
this time around. When you say "push transactions to an SP using the 
IdP's unsolicited SSO endpoint" can you give me an example of how this 
is done?

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

I hope they're not but take your point that we need to be aware that 
this might still be happening. At least we've now got reassurance that 
one of the main SPs (that broke last time) can use the new/correct 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.
>
OK understood.

Thanks again for sharing your real world experience in doing this kind 
of thing.

-Julian