SP registration APIs
peter.schober at univie.ac.at
Wed Aug 1 12:01:29 EDT 2018
* Liam Hoekenga <liamr at umich.edu> [2018-08-01 17:31]:
> One concern raised by our campus is that our legacy SSO provided the
> ability for SPs to self provision (as long as your host met certain
> criteria, you could just point the SP at Cosign and it would work).
As long as their TLS certificate matches a previously configured
whitelist of CAs, AFAIR? Or some regexes on hostnames?
> It seems like some of this might be doable using the metadata
> managed configuration... but there's still the issue of getting the
> metadata onto the IDP.
No idea whether it would be possible to wire stuff in a way so that
you'd accept signed authn requests from unknown SPs (i.e., ones you
have no metadata for) over the HTTP POST binding (so that you have the
signing cert available verbatim) and validate the signing cert's PKIX
trust path, and if that's all fine, send the reponse to the requested
That should give you something pretty close to what Cosign did, no?
As to the more literal question: I guess standing up a Shib-protected
HTML form where people can upload metadata to and request (possibly
pre-configured sets of) attributes shouldn't be too hard (and one or
two institutions might have mentioned they stood up something like
that in the past). Though both the "shib-protected" as well as the
"attribute release request" (i.e., workflow) aspects would probably
rule out the dynamicity or level of automation you're looking for?
Creating an API endpoint from scratch where anyone HTTP POSTs their
SAML 2.0 Metadata to (possibly encoded or wrapped in JSON or
whatever): How would you secure that endpoint (against bogus uploads),
or allow the uploader to make changes?
When metadata is used to convey technical trust (that the endpoints
and keys are legit and belong to the party you think they do) how are
you going to boostrap that trust? Nothing you do (e.g. standing up a
toy CA where operators can get client certs from that authorize write
access to that hypothetical registration API) will probably satisfy
the desires of those "container orchestrators" you mention.
More information about the users