Multiple SP Overrides sites, generate Metadata

[Roger Jagoda]

Scott,

Many thanks for the answer and pointers.

Follow up embedded...


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.


Good question. We just provide SPs. The people we serve are very
distinct. They are geographically separate, they all have separate
user-bases with different needs and focuses. Some will deal with plain
"valid user." others have defined group entities. There just isn't a
way to segregate the need other than multiple Override sites. Unless I
ma missing something very basic. There just really isn't anything much
in common (no pun intended) amongst the entities.


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


Fine. Then we'll leave the Default almost blank since there will
really be no default. There is not much in common to leave in the
default.
There are even very different lifetimes among the various customer sites.


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


Yes, we are mapping the overrides to vhosts. Is there a better way?


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


Right. that seems to be the way to go. We'll probably join a Commons
Fed and public our meta there.



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



Excellent. Thanks so much. We were really wringing our hands about that.
That makes the Override much easier. However there is a really great
example of  doing it in the Overrides in the docs:

HERE:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride:

"The most common case is usually wanting to virtualize the SP by
making an application act as a new logical SP with a
different entityID. This is very simple."

Application Acting as a Distinct SP
<ApplicationOverride id="myappname"
entityID="https://myapp.example.org/shibboleth"/>



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


See above. I do not know another way when all of the SPs are using
very different vhosts (different domains, different geographies, etc)
in wildly different user space environments.
Apologies, but we really do have the need.

Scott, you know best, but if there is a better way to serve multiple
IdPs with distinct user sets we're going to listen to you, of course.





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