Google apps with multiple domains, and one SSP IDP

[Simon Annetts]

Hi all,
apologies if this question has been asked before.

I have one SSP IDP setup to authenticate users to google apps. The users
authenticated by our IDP are in one of any number of different google
apps domains, and all our users have unique ids so there can never be
two users in diferent google apps domain with the same uid.

here is my sp-remote metadata for google apps:

'google.com' => array(
'name' => 'Google Apps',
'AssertionConsumerService' =>
'https://www.google.com/a/g.networcs.net/acs',
'spNameQualifier' => 'google.com',
'ForceAuthn' => false,
'NameIDFormat' =>
'urn:oasis:names:tc:SAML:2.0:nameid-format:email',
'simplesaml.nameidattribute'=> 'uid',
'simplesaml.attributes' => false,
'attributes' => array(
'eduPersonScopedAffiliation',

'eduPersonPrimaryAffiliation',
'eduPersonTargetedID',
'eduPersonPrincipalName',
'o',
'uid',
'givenName',
'sn',
'salutation',
'displayName',
'mail'),
'redirect.validate' => false,
)

Now when google apps redirects to the IDP it includes the ACS URL in the
saml data it sends, because each google apps domain uses a different ACS
url. How do I get SSP to use that data instead of the hard coded value
in the config, which works of course for g.networcs.net but not for
anything else. If I remove the config setting then SSP gives me an error.

kind regards
Simon

[Simon Annetts]

;-) as is often the case i end up answering my own question....
an array of acs urls does the trick:

'AssertionConsumerService' =>
array('https://www.google.com/a/domain1.net/acs',
'https://www.google.com/a/domain2.net/acs'), ...etc

Simon

--

This e-mail and any attachment is confidential.
If you have received it in error, please delete it from your system, do not use
or disclose the information in any way, and notify me immediately. The contents
of this message may contain personal views which are not necessarily the views
of Ateb Ltd, unless specifically stated.
Mae'r e-bost hwn ac unrhyw atodiad sydd ynghlwm wrtho, yn gyfrinachol.
Os yw wedi eich cyrraedd mewn camgymeriad dil�wch ef oddi ar eich system.
Peidiwch � defnyddio na datgelu'r wybodaeth mewn unrhyw ffordd a rhowch wybod
imi ar unwaith os gwelwch yn dda. Gall y neges gynnwys barn bersonol nad yw o
anghenraid yn farn Ateb Cyf, oni ddywedir hynny'n benodol.

***********************************
Ateb Ltd.
Company No. 3769059
VAT No. 736568987
Registered Address:
Marteg House,
St. Harmon,
Rhayader,
Powys LD6 5LG
T: 01597 870329
M: 07932 014055
***********************************

[Olav Morken]

On Fri, Jan 06, 2012 at 16:47:48 +0000, Simon Annetts wrote:
> ;-) as is often the case i end up answering my own question....
> an array of acs urls does the trick:
>
> 'AssertionConsumerService' =>
> array('https://www.google.com/a/domain1.net/acs',
> 'https://www.google.com/a/domain2.net/acs'), ...etc

This is not really the proper solution, since these are separate SPs
that appear to share a single entityID. Instead switch Google Apps to
use a separate entityID for each SP. See this recent thread:

http://groups.google.com/group/simplesamlphp/browse_thread/thread/ebe663f7645fe809#286ac9645143c2b8

Best regards,
Olav Morken
UNINETT / Feide

[Simon Annetts]

Hi Olav,
thanks for the info on this. Just out of interest, what are the
consequences of using the multi valued ACS parameter in the config? It
appears to work well enough and avoids the headache of defining possibly
up to 250 SP entries for the google apps domains .

kind regards
Simon

--

[Olav Morken]

On Mon, Jan 09, 2012 at 09:16:44 +0000, Simon Annetts wrote:
> Hi Olav,
> thanks for the info on this. Just out of interest, what are the
> consequences of using the multi valued ACS parameter in the config?
> It appears to work well enough and avoids the headache of defining
> possibly up to 250 SP entries for the google apps domains .

One thing that will not work is IdP initiated SSO, which happens
automatically to users that bookmark the login page. (I do not know
if Google Apps supports this though, so it may not actually create
additional problems in practice.)

The second issue is unlikely to happen, since I doubt Google wants to
risk breaking many IdPs around the world, but according to the
specifications, they are not required to include the
AssertionConsumerService URL in their authentication request.

Separating it into different domains may have other advantages also.
For example, you can create filters to do extra validation on the IdP
to ensure that you only allow users from one domain to attempt to log
into that domain. (That would require some custom code, but it may be
worthwhile if users are likely to end up on the wrong login page by
accident.