SP Customizations

[Cantor, Scott]

On 5/22/13 7:24 PM, "Roger Jagoda" <rberryj3 at gmail.com> wrote:
>
>Our goal is to have a very stripped down shibboleth2.xml file and do
>most of the customizations in the vhost files.

The default file at this point is about as stripped down a starting point
as exists, I suspect.

>There's a different vhost for each client, but we do not want to
>create a slew of ApplicationOverride entires.
>Hopefully, we can use ShibRequestSetting to do the bulk of what we need.

It really depends on the requirements, but as a general matter I would not
think you need overrides in such a case since the sessions are already
compartmentalized by vhost. But it is possible for somebody to manipulate
a cookie store such that the client will send the session cookie to a
different vhost, and from the SP's perspective it will be valid, because
the applicationId is the same.

The session cache boundaries that an applicationId creates are not really
meant as authorization tools, but sometimes they get used that way.

There is no secret to the fact that the point of the SP as I designed it
is not for siloed systems. That's not really federation at all, and so the
whole point of the software was to support services that would be accessed
by many IdPs at once, not one per host. As a result, many things don't
work all that cleanly with such a model.

For example, you end up with a ton of endpoints in the metadata if you
create separate vhosts per customer. That really doesn't scale. The new
IdP gets around that problem with signed requests, but it isn't something
one can rely on yet since adoption is minimal.

But when you ask the reasonable question "why would it work that way?",
the answer is that it was meant for applications with one entry point that
serve everybody.

>One approach we're investigating is to use separate configuration
>files for each client.

Can't be done, other than the Apache stuff.

>Is it possible to use SHIBSP_CONFIG to specify a different
>configuration file for each client in the vhost file?

No.

>Ideally, we would also like to have a separate log file for each
>client's shibd traffic.

There's nothing one could use in shibd.log to even begin to route anything
that way. It's meant solely for diagnostics.

The transaction log could in theory be routed to syslog and from that
point one could possibly do some degree of filtering on it to control
things, I suppose. syslog isn't my specialty.

>Would SHIBSP_LOGGING do that for us? Looking through that file
>(default file: console.logger) we see logging levels but no way to
>specify a log file. Is there another Environment Variable that handles
>that?

console.logger is the logging configuration for command line tools.

Log files are specified with appenders, like log4j and other logging
frameworks use, as illustrated in the logging configurations supplied.
Appenders work by category, and the category has nothing to do with which
IdP is used.

-- Scott