Verification failed for URI
cantor.2 at osu.edu
Thu Aug 2 19:34:40 EDT 2018
On 8/2/18, 7:21 PM, "Cody Carmichael" <ccarmichael at voalte.com> wrote:
> The SP in this case is a product under development by the company I work for. I've been working with the SP's dev for
> several days on this and unfortunately it's very time sensitive. What would be the more 'usual' way to get metadata
> from the SP? FileBackedHttp? I'm new to most of the concepts involved with shibboleth so I don't have a concept of the
> typical way to do things.
You might want to read . If you're not following one of the models discussed, the fallback of doing it all manually by hand and punting security is simply the norm unfortunately.
The usual way is you need a federation, a third party to sign the metadata that exists between the two. If you're inside a firewall, then the usual way is doing things manually with the understanding that updates and revocation would be done by calling the guy up. That works inside an enterprise, just not otherwise. Even there, having automated metadata update is good, but you can't do that correctly unless the one producing it understands how to separate the metadata from the software's actual configuration to properly handle updates before they actually get made to the running system. That's essential for key rollover.
These are not Shibboleth concepts, for the record. The only standardized trust model SAML has is mine, and I published it at OASIS as the Metadata Interoperability Profile. Nobody not doing that is doing anything interoperable and usually they're not doing anything securely either. But doing that virtually requires a third party metadata source, or a fair amount of careful planning and work.
More information about the users