Support for Multiple IdPs in a single configuration

[David Cortijo]

According to the SimpleSAMLphp documentation, it is possible to have multiple IdPs configured simultaneously.  What is unclear to me is exactly what data points in each configuration need to be distinct.

To clarify my goals here, we are implementing an SSO solution that will allow us to "mix and match" the following authentication sources (using the multiauth module as a front end):

• Local, Shibboleth-backed authentication
• Google
• Facebook
• LinkedIn
• Twitter
• Federated authentication (InCommon) [Will be implemented later]

I have already successfully configured a single IdP for this multiauth setup, and have added/removed underlying authentication sources successfully.  What I am hoping to provide is multiple "instances" of the IdP based on the combination of authsources that I need to provide to a set of SPs.

For example, we may have some apps that only want to use Google+Facebook+LinkedIn (social logins that provide an email address) as a sort of "guest" portal; simultaneously, there may be other apps that only want Local+InCommon, while others still may allow all possible options.

Can someone please help identify which of these I need:

• Some sort of configuration trickery so that Service Providers can identify to the IdP server which specific IdP 'instance'/EntityID they are trying to use?
• A separate folder for each "IdP" on the server (so I would change <idphost>/simplesaml to <idphost>/localonly, <idphost>/local_incommon, <idphost>/local_social, etc - names are just for examples)?
• A separate hostname for each IdP. I would really prefer to avoid this for a wide variety of reasons, but technical limitations are called that for a reason.

For the record, I have poured through the documentation repeatedly, and can find no real detail on how to approach this. We've made a lot of progress in customizing our setup over the last week, and this has suddenly become a show stopper, so any help (no matter how vague) would be appreciated.

-David

[David Cortijo]

Please note - I'd also be happy to trigger the authsource change at the IdP entirely (based on the sp-remote metadata), rather than having different endpoints/entityIDs that we would have to point users to. I just don't see a way to do that either.

-David

[Sixto Martin]

simpleSAMLphp lets you to create multiple SPs with an unique instance, but only let you to deploy an IdP instance.

I could suggest you some aproachs.

1. Go to a Hub&Spoke model, set an IdP/SP bridge and connect several IdPs to it,

(Create an IdP skell with the multiauth elements configured and use that instance as "base template" for your IdPs (enabling and disabling auths when required) .

2. Extend the multiauth module in order to offer differents auth sources based on the SP.

You could have 1 IdP with all the possible auth sources configured and extend the multiauth module. Based on the SP that is requiring the access, offer to the user a subset of the auth  sources available.  I already worked in that when I was doing proof of concepts playing with LoAs and account-linkins.

https://github.com/Yaco-Sistemas/accountLinking

Best regards.

2014-04-03 18:00 GMT+02:00 David Cortijo <draxiu...@gmail.com>:

Please note - I'd also be happy to trigger the authsource change at the IdP entirely (based on the sp-remote metadata), rather than having different endpoints/entityIDs that we would have to point users to. I just don't see a way to do that either.

-David

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

--
Sixto Pablo Martín García
Ingeniero Informático

Yaco Sistemas SL

Teléfono +34 954 50 00 57
C/Rioja 5-1ª Planta

41001 Sevilla

[David Cortijo]

Thanks for the reply.

I did quite a bit more digging since I posted, tracing back how SimpleSAMLphp determines the desired IdP entityID. I've found a rather simple way to "hijack" the selection using a simple GET variable. First, a little background. All the examples below change saml2 code - similar changes could easily be made for shib13, the adfs module (in its variant incarnations), or other instances. I wanted to keep this simple, however.

My authsources.php file has multiple authentication sources defined. local-only uses our organizations local shibboleth IdP, while local-social uses the stock multiAuth module and includes the local-only source as well as configurations for google, facebook, etc.

My current saml20-idp-hosted.php file has 2 IdP entities defined:

$metadata['local-social'] = array(

'host' => 'idp.example.org',

'auth' => 'local-social-multi', 

// All other variables snipped as they are fairly standard

);

$metadata['local-only'] = array(

'host' => 'idp.example.org',

'auth' => 'local-only',

'append.idpentityid' => TRUE,

 

// All other variables snipped as they are fairly standard

);

 

All of the configuration above is relatively standard EXCEPT for that new 'append.idpentityid' variable for our local-only IdP (the choice of where to add it was pretty arbitrary - we're still in early development and testing). I changed things to handle this new variable, and the entityID selection, as follows.

In www/saml2/idp/metadata.php, I added 4 lines of code (right after the $metaArray definition finishes on line 67 - in my 1.11 version, anyway):

if($idpmeta->getBoolean('append.idpentityid', FALSE)){

$metaArray['SingleSignOnService'][0]['Location'] .= "?idpentityid=$idpentityid";

$metaArray['SingleLogoutService'] .= "?idpentityid=$idpentityid";

}

This causes the SSO and SLO urls to append an 'idpentityid' get variable in the metadata. Since we will be using both SSP and Shib SPs, I wanted to make sure that the metadata was generated properly.

In www/saml2/idp/SSOService.php and www/saml2/idp/SingleLogoutService.php, I replaced a single line:

$idpEntityId = $metadata->getMetaDataCurrentEntityID('saml20-idp-hosted');

with

$idpEntityId = isset($_GET['idpentityid']) ? $_GET['idpentityid'] : $metadata->getMetaDataCurrentEntityID('saml20-idp-hosted');

This mirrors code that actually already existed within the metadata.php file (corrected to fix case differences).

The $_GET['idpentityid'] call overrides any determination from getMetaDataCurrentEntityID() (which actually relies on a cross-reference of hostname and path - which would break things for our desired implementation). As a result, SimpleSAMLphp is able to determine the actual desired IdP, with associated configuration (most importantly, the 'auth' variable), and proceeds beautifully.  Because the IdP entities are different, things seem to segregate properly (although more testing is required here).

I would love for people to point out any issues with this approach (apart from the expected "you've modified the core code - shame on you!" response, as I'd like to propose this gets merged if it works out well). We will, over the course of the next few months, come to rely on this very heavily, so anything someone can think of as a pitfall will certainly need to be investigated.

Thank you all for your help.

-David

[Sixto Martin]

1. Adding an extra param --> ?idpentityid=$idpentityid to the SSO and SLO endpoints does not follow the SAML standard.  Maybe you think that it is ok for you, but changing the rules you could carry to your client security bugs. If you decide to go in this way you will need to do a security audition to your final release in order to have a clear conscience.

2. I don't know if the trick that you are doing "hacking simpleSAMLphp", changing the normal flow gonna affects you later. For example, what happen with the session handler? what happen with the IdP metadata publication? what happen with the certs required to sign and encrypt the message/assertions?.  I think that you gonna change a lot of code in order to solve that issues.

Review the proposes that I did in the previous message.

My 2$

[David Cortijo]

My reply got eaten halfway through typing it up, so I apologize if I shorthand any part of this. Hopefully I can reply to your concerns from both of your emails.

We are seeking to implement a multi-tiered architecture in a hub-and-spoke approach (as you suggested earlier), although the mechanics are slightly different than what you proposed. Our "hub" is to be the SimpleSAMLphp IdP, with our "spokes" being the authentication sources I mentioned earlier (local-sourced auth, Federation, Google, etc). Our Shibboleth IdP is the federation member Entity - that will not be changing. This solution is just to expand our options to applications within the organization, so we have full control over all SPs involved, which removes some of the concerns with cross-federation compatibility.

The idea of setting up separate servers to function as (for example) a Google OAuth -> SAML translator and function as its own IdP seems a bit overkill to me, which seems to be the only option to make a hub-and-spoke in a SAML-standards compliant manner.  That being said, compliance is important, so I need to see what else could possibly be done to issue SAML-compliant URIs while still acquiring the entityID from requested resource without requiring a server farm to make this happen.

In regards to metadata, everything is generating as expected. I have already integrated our test SSP and Shibboleth SPs to use the variant IdP as a test. In the case of SSP, it was a simple copy-paste. Shibboleth is pulling the metadata using its own internal refresh mechanisms. Both are working as expected.  Since this IdP will not be used by the Federation (it will instead function as a Service Provider there, and with a single profile), and I'm not worried about SP metadata changing, this simply needs to function properly in-house.

As to the certificates, I am using the same certs across each IdP instance running on this server, so I'm not running into any issues there either.

Any issues introduced by triggering an "alternate" entityID are already going to exist (to some degree) with SSP's internal IdP code, as it uses the URL to determine what IdP entity to leverage. The only SAML 2.0 IdP code that a browser can access is under www/saml2/idp, and the only pages there that leverage the entityid are:

- metadata.php - already patched

- SingleLogoutService.php - already patched

- SSOService.php - already patched

- ArtifactResolutionService.php - not patched, not in use. However, should probably be patched for compatibility.

- several deprecated iFrame pages, no need to touch them.

Since SimpleSAMLphp must be able to determine the entityID from data set to the web page or stored from such an action, every time the entityID is referenced, it is coming from one of the above-mentioned pages.  Of course, it's dangerous to assume 100% compatibility once anything is changed - hence the need to extensive testing - but I'm confident that assertions will work properly if I can bring this back into a standards-compliant mode.

One thing that I may try to do is to replace ?idpentityid=$idpentityid another type of append on the endpoints, similar to the way that SimpleSAMLphp does so for module loads. By way of example, the default:

https://<idpHostname>/simplesaml/saml2/idp/SingleLogoutService.php

which I've modified for non-default IdPs to be:

https://<idpHostname>/simplesaml/saml2/idp/SingleLogoutService.php?idptentityid=<idp entity ID>

could instead be:

https://<idpHostname>/simplesaml/saml2/idp/SingleLogoutService.php/<idp entity ID>

This would keep everything standards-compliant (as it doesn't leverage a parameter, which is the only thing pulling it out of compliance in the first place), which should resolve the rest of the attendant issues as well.

Thanks for all the feedback. It is appreciated.

-David

[Peter Schober]

* David Cortijo <draxiu...@gmail.com> [2014-04-03 22:52]:

> We are seeking to implement a multi-tiered architecture in a hub-and-spoke
> approach (as you suggested earlier), although the mechanics are slightly
> different than what you proposed. Our "hub" is to be the SimpleSAMLphp IdP,
> with our "spokes" being the authentication sources I mentioned earlier
> (local-sourced auth, Federation, Google, etc). Our Shibboleth IdP is the
> federation member Entity - that will not be changing. This solution is just
> to expand our options to applications within the organization, so we have
> full control over all SPs involved, which removes some of the concerns with
> cross-federation compatibility.
>
> The idea of setting up separate servers to function as (for example) a
> Google OAuth -> SAML translator and function as its own IdP seems a bit
> overkill to me, which seems to be the only option to make a hub-and-spoke
> in a SAML-standards compliant manner. That being said, compliance is
> important, so I need to see what else could possibly be done to issue
> SAML-compliant URIs while still acquiring the entityID from requested
> resource without requiring a server farm to make this happen.

Not sure I understand all of that (hardly anything, I fear) but since
you mentioned InCommon several times, have you looked at the Internet2
working groups on that?
https://spaces.internet2.edu/display/socialid/ and its successor:
https://spaces.internet2.edu/display/socialid/Draft+Charter+for+External+Identities+Working+Group
They have done some work (conceptual and deployment) that seems to do
exactly what you intend to achieve: Offering more authentication
services (non-SAML IDPs, if you will) to existing local SAML SPs.
-peter

[Dave]

I wasn't aware of those working groups - thanks for the links.  It seems like I have duplicated some of their work locally, with some subtle (but important) differences:

1) I've implemented several of their authentication sources into one IdP, whereas it appears they are using a separate SimpleSAMLphp instance for each authentication permutation (which I am trying to avoid).

2) Because each permutation is a separate SSP instance, it would (I assume) force the administrators to configure separate linkback locations.

3) Regarding the model - since the gateways are centrally available and centrally managed, it would introduce dependencies on external systems and procedures above and beyond the authentication source.

4) Likewise, introducing SPs to these centrally managed IdPs introduces metadata sprawl that shouldn't really be necessary for the model we're looking for (where we can easily add and manage applications locally within our own SimpleSAMLphp implementation).

I'll have to look further into their goals - their policy approach and documentation will definitely be helpful moving forward.