Azure as IDP protecting multiple Shibboleth Apps- Cert error

[Sean Flannery]

Merging them into a single metadata file with multiple certs did work- thank you Peter.

Yes, I agree this is the best way to make it work, but its bad to have different behaving IDPs in a single metadata.

Will see if I can get a better solution at the Azure IDP level, but sort of doubt it.

For now, I am good.  Thank you!

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Peter Schober <peter.schober at univie.ac.at>
Sent: Wednesday, September 20, 2017 3:33:13 AM
To: users at shibboleth.net
Subject: Re: Azure as IDP protecting multiple Shibboleth Apps- Cert error

* Sean Flannery <sean.flannery at jwt.com> [2017-09-20 04:38]:
> I think the short version of this question is: in shibboleth SP, can
> you map multiple certs to a given IDP entity ID?

An IDP can have multiple certs in its metadata, no problem. The SP can
use any of those for verification of signed protocol messages.

>   *   Azure IDP generates metadata for each each app you want to
>   protect. The metadata for an app contains a unique cert, but
>   the same entityID is used for all metadata.
>
>   *   when you import all the metadata and setup the multiple
>   applications in Shibboleth- only one of the apps will
>   work. The others will all fail because their certs don't align
>   with what shibboleth expects for that (IDP's) entityID.

You could "merge" all those individual EntityDescriptors into a single
one, that has the union of all protocol endpoints (ACS URLs, etc.) and
keys.(SLO won't work that way, though, but that's just yet another reason
why SLO doesn't work properly, of course.)

Since they all claim to be the *same* entity there's no other sane way
to handle those, IMHO.

> Does the problem make sense?

Obviously it's not a good idea to generate vastly different metadata
and then give it all the same entityID.

-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170920/b70ba692/attachment.html>