SP registration APIs

Cantor, Scott cantor.2 at osu.edu
Wed Aug 1 11:53:39 EDT 2018

> I would really not rather loosen the restrictions on the
> UnverifiedRelyingParty and run an open IDP.

That's essentially what you were doing. ;-)  There are inherent costs to not running open, obviously. I don't think there's really a meaningful middle ground. If you understand how HTTP works, you know that wildcarding URLs means nothing (hint, /etc/hosts).

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

That's the cost. You hardly need much in the way of any configuration for on-campus systems anyway, so the sum total *is* the metadata being needed most of the time. Assuming you release basic attributes by default at least.

The only hair splitting is URL registration. Signed requests can be used to bypass the endpoint checks so you do have the option of one-time metadata setup  with no individual maintenance of URLs, which helps with vhosting depending on how much entityID separation you want to require. That helps a lot for some kinds of deployments, e.g. content management sites spanning hundreds of hosts.

Obviously some campuses have very advanced tools for automating and delegating metadata management, and at the extreme end it could be automated, but it’s certainly a lot of work, and likely means regulating whatever's happening through some other key I guess. That's more or less what happens if you had the metadata managed by the customer(s) and you pulled it in under their signature, which I have done for some groups.

To fully automate trust is to not require it, it's pretty cut and dried to me. I don't begrudge anybody believing that's better for them, but I think it's largely a waste of time to try and go halfway with it. To be able to stand up a system at random and have it "just work", that's just an open IdP. We certainly support it but since so few people run that way there are probably things we haven't documented well or considered fully.

-- Scott

More information about the users mailing list