Anyone have any success setting up with Starfishsolutions?

[Peter Schober]

* Michael A Grady <mgrady at unicon.net> [2019-05-07 20:30]:
> That was certainly my first (and somewhat continuing) reaction also,
> but if one starts with the given of a non-"fully SAML
> interoperability capable SP implementation" and the need to manage
> bilaterally, it actually does have one advantage -- you can have
> both entityIDs set up to work in your IdP at the same time, and
> remove the need to carefully coordinate when they make the change on
> the Starfish side. (The "trying to see the silver lining"
> perspective :-)

Last time I checked Keycloak generated a new entityID for *itself* for
every new IDP you manually configured (it doesn't do metadata), so
this would be similar. In this model you're trading no-flag-day
changes (e.g. key rollover) /within/ the same EntityDescriptor for
having to manage IDP-specific-SP-metadata.
Then add on top specific snapshots of that metadata (along the lines
of the "immutable server" trend), i.e., you don't ever modify your
metadata, you replace it with different metadata then referenced by a
different entityID. E.g. you can reference snapshots of metadata
stored in git repo by their sha1 commit id and adding a git repository
server's URL to this you now have a URI pointing to a certain state of
the metadata, make this URI your entityID.

So now you have commit-specific, IDP-specific SP metadata to manage,
which could easily be in the thousands. Is that really easier than
adding support for metadata and multiple keys to your SP software?
(I guess it might be if you get away with forcing all that additional
work onto your federation "partners".)

-peter