Multiple SP Overrides sites, generate Metadata

[Cantor, Scott]

On 10/16/12 8:18 AM, "Roger Jagoda" <rberryj3 at gmail.com> wrote:
>
>That way we can control our metadata AND not have to worry about this
>in the future (we have a LOT of pending Shibboleth SP entries to do).
>Generating MetaData this way is just ...inefficient to say the least.

My point remains: you should not need a LOT of entries. If all you have is
one service offering, then all you need is one SP. It doesn't matter how
many vhosts you have, or how many IdPs you support. You just have to
register endpoints for each vhost.

>So this works:
>
>     ShibRequestSetting entityID https://idp.example.org/idp/shibboleth
>
>However, there does not appear to be a way to specify SAML order. We
>usually do that in the ApplicationDefaults:

Ok. That's the point, you don't need to reproduce all that in the
overrides (which in fact I'm still not sure why you need).

>As this is a "general" setting, is there a way to set the order
>somewhere in the Default context generically (i.e. NOT tied to an
>entityID)?

You only need one entityID if this is one service. Is that not clear? That
is the point I'm trying to make.

>YUP, but it is the HTTPD logs and not the SHIBD logs that you need to
>look in as the error was from Apache, not SHIBD.

Or native.log.

>So the bottom line here is that you MUST have an ApplicationDefaults
>section AND that section MUST have an entityID. The latter may even be
>irrelevant, but you
>CANNOT have an ApplicationDefaults without it. SHIBD will complain and
>not launch.

Yes, because the normal approach is one entityID. In the rare event you
need > 1, then you can either override all requests and ignore the default
entityID, or use it alongside the rest.

>Since, we generate metadata against the Override sites using the
>Metadata method:
>
>     https://siteX.com/Shibboleth.sso/Metadata

>the file generated will always contain lines referring to what is in
>the  ApplicationDefaults entityID line.
>However, that might not be accurate or even point to an existing site.

That is incorrect. if you override requests for siteX.com, then a request
to that handler will produce example metadata with the entityID set from
the override.

>So is there no way to generate Metadata derived SOLELY from the
>entityID in the ApplicationOverride lines
>(i.e. containing no reference to what entityID is listed in the
>ApplicationDefaults lines?

Yes, there is, see above.

>We are not the only ones trying to do this. There are a lot of people
>out there trying to serve SP data while referencing any IdP meta or
>their own.

I don't know what that means, but you should never "serve" generated
metadata. You will have a broken system if you do because you can't
control key rollover if you don't separate metadata from configuration.

>So as we align one vhost per ApplicationOverride entityID, that would
>be the ideal situation.

It's not the ideal at all for the IdP. Once service, one name, one
entityID.

>I know it is probably not the way the creators of Shib had envisioned,
>but it seems to have evolved that way for SP-only providers.

Most of them are confused. If you host one service, it's one entityID.
Multiple entityIDs are needed when you have different kinds of services or
an application with multiple parts that contain different requirements for
attributes, authentication methods, or other things that need to be
exposed to IdPs.

>IS this not possible, or have we totally missed something very key here?

I think you're failing to understand what an entityID is. It has nothing
to do with vhosts or with vhosting in general, certainly. Names are not
locations. A vhost is a location, an entityID is a name. Or a label for
policy if you like.

-- Scott