Questions about using ApplicationOverride to define all vhosts/protected sites

[Cantor, Scott]

On 5/30/12 12:10 PM, "csross" <cross at hccs.com> wrote:
>
>If I get another customer/site that wants to use shib, then I will need
>to create a new vhost for that site. This I am thinking will mean a
>different entityID?

It doesn't. An entityID is just a name. A vhost is a location, or a set of
locations anyway. An entityID could be made-up URL that identifies your
application service in a totally abstract way.

Please read the NativeSPApplicationModel topic for background on the
concepts here.

>So I was under the impression that executing
>https://site2.program.com/Shibboleth.sso/Metadata would display the
>metadata for that entityID?

No, that generates test metadata specific to a vhost. The entityID it
happens to put into the *example* metadata is derived from the application
settings used for that location. It has nothing directly to do with the
vhost name.

>>You should not be using the RequestMap for anything with Apache.
>
>I was just being thorough and mentioning another vhost in Apache and
>possible changes to the apache22.config.

None of that has anything to do with the RequestMap though. The RequestMap
feature is there for IIS and is unneeded for Apache. That's why it's not
even in the non-Windows config by default. I documented that in the Apache
configuration reference.

> 
>I appreciate that.  I am very very new to deploying this.

I just don't want you to be held responsible by your boss because some
customer can figure something out by just a small amount of probing or
guesswork. I understand the use case, but this implementation wasn't
designed for that kind of scenario and it does lots of default and even
built-in things that make it possible to learn things about how it's
deployed. Nothing security-sensitive, but things that could reveal
customer "presence".

>Does the ShibRequestSetting applicationId  define the applicationId for
>the vhost like it does in RequestMap?

Yes. It can define anything the RequestMap can, that's why you don't need
the map. The map is easy to circumvent when Apache is misconfigured.
Apache commands can't be.

>If so, then that is why I am using RequestMap
> because on this server, the <Location /> statement in the
>apache22.config would be the same for each vhost/entityID

Why would they be the same?

>Thank you.  Testshib was just an example.

It's an extremely dangerous one though. You don't want that metadata to
allow anything you don't want to allow.

>What I mean is that every time I add a shibboleth customer (a new vhost
>like site2.program.com) and add a new ApplicationOverride for that vhost
>with a new entityID, do I have to generate new Metadata for every vhost
> or just the new one by executing
>https://site2.program.com/Shibboleth.sso/Metadata?.

You shouldn't be managing production metadata using that endpoint. It's a
learning tool.

I don't know anything about how you are managing federated trust with your
customers, and that is entirely the issue. If you're manually exchanging
metadata, then you need to prepare correct metadata for your system that
reflects the system state to give to the new IdP and a mechanism for
keeping it up to date. That's what federations do, and why we pay them
money.

If you're trying to isolate things, then you could probably have a fixed
metadata shell with a single generic entityID and simply create endpoints
specific to a customer's vhost and make that available to each customer. A
basic shell script can do that very easily.

Or you can manage separate entityIDs for each vhost, and it's still much
the same.

> 
>Do I have to send new metadata to every IDP every time I make any change
>to the shibboleth2.xml?

That depends on the change and the overall deployment and how it works. It
depends on what the change is and whether the change impacts something
relevant to the metadata provided to an IdP.

What you're loosely describing here is about adding vhosts for customers,
and that answer would be no. Any one customer is seeing only one vhost and
they don't care about any of the others or any new ones.

I still think you'd be better served avoiding overrides altogether. If you
have a single entityID, the only thing the override is buying you is
per-vhost metadata. That's not necessary. You can enforce policy over
which IdP(s) can direct traffic to a given vhost in the application layer
in most cases.

>>why are you using overrides at all?
>
>There may be more than one customer, vhost.

That doesn't mean you need overrides. That's a very high-overhead tool.
Any time you can avoid changing the SP configuration entirely, that's the
best option.

>Thank you very much.  I am sorry for the simplistic questions but this
>requirement came up fast and I cannot find training classes for this.

They aren't simplistic questions. That's why I can't just answer them in
simple terms.

-- Scott