a few initial questions

[Cantor, Scott]

On 6/25/12 8:28 AM, "Gilbert, Alistair" <Alistair.Gilbert at basware.com>
wrote:

>The documentation implies that the Web service must sit on the same
>physical box as the actual web application itself.

More than imply, it takes great pains to say so outright. If there's a
place you see that is soft-selling this issue, let us know and the docs
can be fixed.

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

This a given. The only way to avoid running code on every server is with a
reverse proxy. If that's what you think you want, then you can deploy
authentication code on the proxy, yes.

You don't have to run SAML itself on every server, but if you don't, then
you will be operating a second SSO protocol between a gateway server
running SAML and your applications, and the agent software for that
protocol will be running on all of those servers. A proxy is the only way
out of that.

>I would like to have shibboleth serving multiple different services in
>the future that could potentially sit in completely different data
>centres as well as different platforms.

For design reasons (I don't believe in coding applications to proprietary
APIs), the SP only runs inside web servers, never inside applications.
That's a feature, not a bug. It just may not be a feature you want, in
which case this isn't the right design for your needs.

The API issue is a bigger problem within an enterprise when deploying the
software for SSO then for your kind of scenario. Some people think it's a
good thing to have agent code available in every language people use. I
don't, because it means you will never, ever be able to stop running the
software due to the difficulty in getting applications to switch from one
API to another.

>How exactly, at a high level does the SP intercept requests to protected
>resources

It intercepts (or can intercept) every request, that's why it has to run
inside the web server(s) hosting the resources.

>I imagined that this would be a simple process of external traffic would
>be routed to the shibboleth server, it would then parse elements of the
>URI, perform its authentication against the appropriate idp and then
>redirect but the documentation implies that it somehow intercepts
>requests without the need for traffic to be directed towards it first·

What you are suggesting is not physically possible. There is no way to
secure the final redirect you have in mind. Securing that step *is* a SSO
protocol.

>Assuming that the shibboleth servers do not need to sit on the same
>system as the protected resource I am guessing that load balancing is
>simple to implement through the use of a standard H/W load balancer

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

Your applications undoubtedly already have their own clustering solution,
so using Shibboleth is a job of minimization. You want it running only for
an entry point into the system and then get out of the way so that the
Shibboleth piece doesn't need to be clustered.

>However, I am wondering how configuration is maintained across the nodes.
>Can we house all configuration on a shared San or / and is there a
>centralised configuration utility that can span across the nodes?

A load balanced configuration typically will run essentially the same
configuration files across servers. It could be hosted on a distributed
file system but it is generally better to stick with standard package
behavior and sync the configuration to all the nodes.

>Finally, when determining the correct idp to use for the authentication
>process (initial request) how exactly can this be achieved?

Discovery can be handled with a number of different mechanisms, including
URL patterns, or in the general case by running a SAML discovery service
such as the embedded DS offered by this project or others that are
available.

>o  
>I was hoping we would have options such as
>§ 
>Look at some uri parameter to determine the correct idp (preferred option)

You can, though it's best to rely on the vhost or path. That presumes your
application service is not actually federated. If each instance is
accessed only by users from one IdP, then compartmentalizing by vhost is
best for security. If not, then you shouldn't be assuming the IdP based on
the request at all, but using true discovery.

>§
>Source ip range

Not supported. Some discovery services can leverage IP ranges or
geolocation info to offer hints about IdPs. The Shibboleth DS software
options do not currently, but others do. In any case, it is a hint only,
as you can't assume an IdP based on an address.


>Also I was hoping that if no method for identifying the correct idp (no
>URI parameter or invalid URI parameter (invalid from the point of view of
>the SP)) could be used we could configure the system to (e.g. for those
>customers not using SSO):
>§ 
>Pass an unauthenticated request to the service itself. then the user
>selects the correct customer tenant and enters a username and password
>and click login (this login screen is part of the service we provide not
>the SP).

There are a variety of options for how to combine this with local
authentication. You can find plenty of list threads in the archives about
it.

> Selecting the tenant would initiate a redirect filling in the URI
>parameters with the entered details from the login screen; if recognised
>by the SP the SP would authenticate and redirect to the application where
>it would accept the SPs authentication or, in the event that the tenant
>selected was again unknown by the SP it would again redirect to the
>service but with the username and password for application level
>authentication. Is this a valid process?

Sort of, not really. What you do is discovery, and that's how you invoke
the SP with a chosen IdP. One of the discovery options is normally a local
login option to bypass federation. Or, a better option, deploy an IdP for
all local logins and abstract that behind the same SAML interface used for
federation.

-- Scott