As part of an ongoing series, we’re helping to explain ways to configure SimpleSAMLphp as a centralized identity provider (IDP) for your organization.

Systems with critical identity management requirements need strong cryptography and multi-factor authentication. End users often struggle keeping track of discrete, secure passwords for various systems – short of eliminating passwords entirely, the easiest way to keep disparate systems secure is to federate authentication between them from a single, trusted authentication source.

To enable such security for as many unconnected tools as possible, administrators can set up a centralized authentication service – one particularly useful service, that can easily be self-hosted, is SimpleSAMLphp. A centralized authentication server allows end users to log in once to a known location and carry their verified identity to certain other services at the same time.

Conveniently, users of many hosted products – tools like Office 365 and Google’s G-Suite – can leverage such an authentication server. We have published a plugin for SimpleSAMLphp that allows LDAP users to authenticate using Tozny’s Authenticator. This means your users can access all of your in-the-cloud resources while still leveraging secure authentication by way of Tozny.

To help get you started, this series will walk you through the basics of configuring SimpleSAMLphp on your server. We’ll follow up by enabling integration with Tozny as a centralized identity provider, then illustrate the steps involved in configuring both Google’s G-Suite and Microsoft’s Office 365 to authenticate against the server.

Key Components

In order to follow along with this tutorial, you’ll need access to the following components:

SimpleSAMLphp is an open source SAML provider that you can install on your own server. It can act as either a hosted identity provider (the central service against which users sign in and prove their identity – the case for which we’ll be using it moving forward) and as an authentication service for external identity providers.

SimpleSAMLphp requires a publicly-accessible server and domain name to be usable. We recommend a cloud host like Amazon Web Services or Microsoft Azure. Whichever host you choose, we’ll defer to their setup instructions.

Configuring SimpleSAMLphp

Once the server is set up and ready to go, installing SimpleSAMLphp is as straightforward as installing any other PHP application: get a copy of the source onto your server. The product’s website has detailed step-by-step instructions and configuration guides, so I won’t belabor the point.

For all of the steps from this point forward, we will assume you are setting up authentication for users of the somesite.com domain (i.e. email addresses alice.smith@somesite.com) and will be configuring your SimpleSAMLphp server to run on a subdomain like sso.somesite.com.

If there are multiple websites hosted your server, configure a virtual host for the new sso.somesite.com domain. This could be a name-based virtual host in Apache or a custom server in Nginx. Whichever server technology hosts the site, be sure to configure SSL for proper security – the Certbot client from Let’s Encrypt makes this free and easy to setup.

Authentication Sources

Once SimpleSAMLphp is installed and the server configured for your subdomain, you’ll need to configure an authentication source – the core definition of user credentials. For the purposes of this and future walkthroughs, the default “exampleauth:UserPass” module is sufficient to for authenticating to the service.

While enabling the module, you will need to add the following block to authsources.php:

'somesite' => array(
    'exampleauth:UserPass',
    'user1@somesite.com:user1pass' => array(
        'uid' => array('user1'),
        'IDPEmail' => array('user1@somesite.com'),
    ),
    'user2@somesite.com:user2pass' => array(
        'uid' => array('user2'),
        'IDPEmail' => array('user2@somesite.com'),
    ),
),

The key identifying the configuration can be anything, but keeping it the same as your authentication domain helps to disambiguate things if you later use the same SimpleSAMLphp installation for alternative authentication sources. The two users are merely placeholders – a real configuration would use a tool like LDAP, Tozny, or similar to query for users, credentials, and attributes.

Identity Provider

The configuration for your identity provider maps the virtual host you’ve set to serve the domain to the authentication service defined above and the certificate used to encrypt and sign requests. Add the following block of metadata to /metadata/saml20-idp-hosted.php, replacing the appropriate fields with your own server’s information:

$metadata['https://sso.somesite.com'] = array(
    // The hostname of the server this SAML entity will use.
    'host'        => 'sso.somesite.com',
    // X.509 key and certificate. Relative to the /cert directory.
    'privatekey'  => 'somesite.key',
    'certificate' => 'somesite.crt',
    'auth'        => 'somesite',
);

Testing the Workflow

Once the server is configured, you can test the setup by navigating to https://sso.somesite.com and clicking the Authenticate tab. Next, click “Test authentication sources” and select your new configuration from the list.

Entering the credentials that are hard-coded into the “exampleauth” provider will log you in and present you with the preconfigured meta information of the test users. This proves that the server is working and authenticating users properly.

Come back next week to learn how to integrate SimpleSAMLphp with a real authentication provider and move beyond hard-coded credentials. After the server is both configured and leveraging real user credentials, we’ll move on to configuring some relying parties (specifically Office 365 and Google’s G Suite) to authenticate against the server as well.