Implementation Stategy, Multiple Subdomain (SaaS)
xzyfer
I'm developing a SaaS system where users can sign up for accounts,
which generates a new app instance on a subdomain. My question is
regarding the proper implementation of a SAML SSO system.
Requirements:
* there can be an infinite number of client systems hosted at
http://*.example.com (where * is a unique identifier for that system)
* there is a central user data store (mysql). It's a small database
that lists all the unique system identifiers (subdomains), users and
the relationships describing which users can access which client
systems.
notes: a single user account can (and is expected to) belong to
multiple unique systems.
At the moment I have a single IdP on an independent domain (http://
sso.foo.com), and a SP for each unique client system. i.e. (saml20-sp-
remote.php on the IdP has a metadata entry for each subdomain of
example.com). As you can imagine this becomes a maintainence
nightmare.
Is is possible to have a single SP (http://www.example.com) ?
Peter Schober
> At the moment I have a single IdP on an independent domain (http://
> sso.foo.com), and a SP for each unique client system. i.e. (saml20-sp-
> remote.php on the IdP has a metadata entry for each subdomain of
> example.com). As you can imagine this becomes a maintainence
> nightmare.
Why use SAML at all, when there is only your single IdP and your SPs?
Because you need the IdP to not share a domain with the SPs?
Or are you planning to accept logins from other IdPs at some point (as
opposed to forcing Yet Another Account for your IdP upon users)?
-peter
xzyfer
* there is a dynamic number of client instance of our application.
* we need clients to have a central user account (username, password).
* a client can have access to any number of client instances (via an
invitation system)
We wanted a client to login from a central location, and the
authentication cookie to persist over the multiple client instances.
This is achieved relatively simply when all the application instances
run under a single parent domain.
But we also have other applications, i.e. invoices and billings, cms
and educational applications that we would like to share the same
authentications tokens.
The process was heavily inspired by 37signals. Where a user logins
(under the 37signals domain) with a system wide 37signals account, and
it then able to access any number of applications in the 37signals
suite without re-authenticating, even though each application is on
its own separate domain.
What I am currently trying to achieve is having a user able to login
in at http://www.foo.com, and have that authentication cookie shared
under all instance of http://*.bar.com (where they are subscribed
ofcause). And then to also be able to share that authentication cookie
when the access our billings app (http://www.baz.com)
The idea being we will then switch over all our products to our
IdP(s).
On Oct 6, 10:07 am, Peter Schober <sp+lists.simples...@univie.ac.at>
wrote:
Olav Morken
It is possible, but maybe not in the current stable version of
simpleSAMLphp. The reason is that we need to set a cookie for the
.example.com-domain, and the required options were added after version
1.6 was released.
In the current developement version (which at some point will become
version 1.7), you can do something like the following in config.php:
/* The cookie must be valid for all subdomains of example.com. */
'session.cookie.domain' => '.example.com',
/* We need a common session store for all our domains. */
'store.type' => 'sql',
'store.sql.dsn' => 'mysql:host=mysql.example.com;dbname=somedb',
'store.sql.username' => 'someuser',
'store.sql.password' => 'somepassword',
You must also be careful when doing authentication. You must always
start it from the domain you have configured at the IdP. This means
that at each site, you must do something like:
$as = new SimpleSAML_Auth_Simple('default-sp');
if (!$as->isAuthenticated()) {
/* Need to log in. */
SimpleSAML_Utilities::redirect('https://www.example.com/startauth.php',
array('ReturnTo' => SimpleSAML_Utilities::selfURL())
);
}
And in startauth.php:
if (!isset($_REQUEST['ReturnTo'])) {
die('Missing ReturnTo parameter.');
}
$as = new SimpleSAML_Auth_Simple('default-sp');
$as->login(array(
'ReturnTo' => (string)$_REQUEST['ReturnTo'],
));
(The reason for the startauth.php on the common site is that we
currently autogenerate the AssertionConsumerServiceURL we send in the
authentication request. If we don't start the authentication from
www.example.com, we will end up with an URL that points to a domain
that isn't registered at the IdP, which may cause it to be confused.)
(Also note that much of this hasn't been tested very much, so more
testing would be welcome.)
Regards,
Olav Morken
UNINETT / Feide