Questions about using ApplicationOverride to define all vhosts/protected sites
Cantor, Scott
cantor.2 at osu.edu
Wed May 30 15:33:43 BST 2012
On 5/30/12 10:04 AM, "csross" <cross at hccs.com> wrote:
>
>My shibboleth implementation
> will be for multiple clients/vhosts, each using different IDPs and
>different entityIDs, application_ids. Right now I am setting up the
>first but I was trying to think ahead.
What is it that leads you to think you need separate entityIDs for your
vhosts? Is your service really more than one service, or is it just one
service over and over again? If the latter, it isn't clear that you want
more than one entityID.
Particularly if you're going to supply dedicated metadata to each customer
anyway, since that metadata could contain only that customer's endpoints.
>Since I don't want to chance revealing a customer to another, I thought
>against specifying
> one customer site in the ApplicationDefaults and have a generic
>ApplicationDefault. Then I would define each vhost/client with
>RequestMap, ApplicationOverride and Apache.
You should not be using the RequestMap for anything with Apache.
I would also caution that the SP is not designed to hide anything like
this and you should not count on customers not being able to deduce
things. If you want that separation, you should deploy VMs and partition
everything. I would urge you to avoid making any guarantees to anybody
about what they can learn about your deployment. It's simply not designed
to do that.
>Can I put any site that is resolvable on this server as the entitiyID in
>ApplicationDefaults, even if it is not 443 need protection? The site
>will never be used as an application? Can I put any site as the HomeURL
>there (I thought I had read that it is where someone lands if the user is
>invalid or other problems)?
If a request never maps to an applicationId of "default", then the various
default properties are never used if they are overridden. In Apache terms,
if every VirtualHost has a ShibRequestSetting applicationId for all
requests, then all requests will be overridden.
>Since I specified the MetadataProvider only
> in the ApplicationOverride section for the site I am setting up, I
>received a warning that "no MetadataProvider available, configuration is
>probably unusable". I don't like warnings so can I use
>anyMetadataProvider entry from (ie) Testshib in the ApplicationDefaults?
Testshib on a production server? Just create a dummy metadata file of some
sort and load that, or pick one of the metadata sources actually used and
load that. If every override has a MetadataProvider defined, then the
default is never used.
> What could be the possible problems with this please? Can I just leave
>the ApplicatinDefaults section without one and define each in the
>ApplicationDefaults?
It won't hurt anything, it just causes the log message.
>If I can set up my sites by adding ApplicationDefaults/RequestMap
>sections, do I have
> to send new metadata to every client/vhost or just the new client I am
>adding please?
I don't know what that means, but every IdP needs appropriate metadata,
period. How you do that is deployment specific. Simple scripting is
usually an easy way to generate large amounts of metadata, e.g. the
metagen.sh example in the etc directory.
>Am I correct in thinking all I have to access each sites metadata or is
>https://site1.program.com/Shibboleth.sso/Metadata
>https://site2.program.com/Shibboleth.sso/Metadata
That is not a source of production metadata, it's for example use.
You have two major issues:
- why are you using overrides at all?
- don't use the RequestMap
-- Scott
More information about the users
mailing list