a few initial questions

[Gilbert, Alistair]

Hi Scott,

Thanks for the reply and sorry for the delayed response.

Based on your feedback I believe that we may be ok using a gateway solution. The application in question supports WIF I was hoping that we could use shibboleth server as a gateway such that authentication requests from the client are made directly to the shibboleth box, authentication is done there and then the application authenticates against the gateway through WIF, is this a possible solution?

Best regards,
Alistair

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: 25 June 2012 15:42
To: Shib Users
Subject: Re: a few initial questions

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

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