Multiple SP Overrides sites, generate Metadata

[Roger Jagoda]

Scott,

Thanks for all the pointers and answers. Replies in-line, others might
find the information useful too.


On Thu, Oct 11, 2012 at 6:35 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 10/11/12 6:25 PM, "Roger Jagoda" <rberryj3 at gmail.com> wrote:
>
>>Folks,
>>
>>Being somewhat new to Shibboleth but not to HTTPD. Linux or other
>>systems, I think I have the correct approach for multiple SPs in one
>>configuration if i read everything correctly here:
>>
>>
>>https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride
>>
>>1) Put the multiple SP entities in the Overrides section.
>>2) Generate Meta separately for each Override site.
>
> You can, but a first question to ask is why you want to. Why does the
> system need to have that many entityIDs? Are they really distinct
> services? In particular, do NOT create a different entityID per customer.
> Very bad, do not do.
>
>>That seems logical , but what about the ApplicationDefaults entityID?
>>If I read the docs right, since we're a provider only (we house no
>>IdPs here),  I think we might want to leave the ApplicationDefaults
>>very bare. Maybe that would be a good place for the Shib "Status"
>>config?
>
> Well, you really want anything that's common config-wise to be there IMHO.
> You don't have to actually leave any resources on your server mapping to
> that applicationId, and then it does nothing but consolidate your settings
> where possible. The entityID alone would never get used.
>
>>1) What are people using for the "Default" application. We do not want
>>that to be a remote site since we're just a SP Provider. Is there a
>>"safe" page for that entity?
>
> You decide what resources map to what applications, not the SP. There
> doesn't have to be anything mapped to anything you don't want.
>
>>2) If the Override sites are done as above, can the meta files for
>>those sites be generated like this:
>>
>>      https://siteX.com/Shibboleth.sso/Metadata
>
> That depends on your RequestMap / Apache commands. Nothing in the override
> itself dictates what resources in the server correspond to it, that's
> separate. If you're mapping to overrides by vhost, then that's correct,
> more or less, but once you have an example to work from, you can manage
> your metadata yourself, not via that tool. That's for generating initial
> examples to work off of.
>

Actually, we do that for the client IdPs. They all ask for it to enter
into the IdP structures,otherwise we would not do it this way.
Instead, we'd probably publish from InCommons:

    http://www.incommon.org/federation/metadata.html

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.


>>3) What can you put in the Override sections. For example can you add
>>SSO entries  like the one above in the Default entity:
>>
>>                 <SSO entityID="urn:mace:incommon:defaultsite.com">
>>              SAML2 SAML1
>>                 </SSO>
>
> Yes, but don't. If you want to set the IdP to use by vhost accessed, then
> you do that with "ShibRequestSetting entityID whatever" in the Apache
> configuration. And you don't necessarily need overrides to do that.
>

Yes, this is the way. In vhost files the structure is: <Directive>
<setting> <value>

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:

    <SSO entityID="urn:mace:incommon:defaultsite.com">
           SAML2 SAML1
    </SSO>

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)?


>>4) If the "default" cannot be used for the "status page," what is the
>>best way to do that? Whenever we run this:
>>
>>             https://default.com/Shibboleth.sso/Status
>>
>>We get a permission denied error (Forbidden, 403 error)
>
> ACL. Look in your logs.
>

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.
I should have known that, but alas, tunnel vision rules when you're
focused...:-(


>>5) We're thinking of trying to join the In common Federation. So could
>>the Default entity be our entry from that? We're sort of mystified
>>about what to do with the default if we're using Overrides.
>
> I think you're going down an overly complex path to start with, and you
> may be better off stepping back. Why do you think you need multiple
> entityIDs?
>

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.

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.

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?

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.
The client wants something to plug into THEIR IdP server from OUR SP
generated meta only .

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

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.

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

Many, Many thanks so much!
You are a huge help to the Community!

--R


>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net