Introduction
The installation of simpleSAMLphp is described in the manual. Follow these instructions.
This document describes the configuration of simpleSAMLphp as a Service Provider for SURFconext.
If you run Debian (or Ubuntu) you can also use the simpleSAMLphp package from the repository. If you run Fedora, CentOS or Red Hat Enterprise Linux you can use the experimental package under review here.
SURFconext Metadata
Take note that the metadata and the metadata locations used for the test and production environments of SURFconext differ. Use them accordingly:
Configuration
The simpleSAMLphp manual at its website is fairly complete for configuring it as a service provider. The snippets below will help you get started with SURFconext quicker. It is still recommended to follow the configuration guide from the simpleSAMLphp manual and check here what you need to configure at a particular step in the process. You do not need to fiddle with the certificates as described there for SURFconext.
Authentication Source
The following snippet can be added to config/authsources.php. Do not forget to update the name and description and attributes fields to match your service name, description and the required attributes:
'SURFconext' => array(
'saml:SP',
// The entity ID of this SP.
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => NULL,
// The entity ID of the IdP this should SP should contact.
// Can be NULL/unset, in which case the user will be shown a list of available IdPs.
'idp' => 'https://engine.surfconext.nl/authentication/idp/metadata',
// The URL to the discovery service.
// Can be NULL/unset, in which case a builtin discovery service will be used.
'discoURL' => NULL,
// The entries below are all OPTIONAL but RECOMMENDED to tell SURFconext
// some details about your service and the attributes it requires.
'name' => array(
'en' => 'Name of the Service',
),
'description' => array(
'en' => 'Description of the Service',
),
// We would like to get the mail and displayName attributes
'attributes' => array(
'urn:oid:0.9.2342.19200300.100.1.3', // mail
'urn:oid:2.16.840.1.113730.3.1.241', // displayName
),
// But only the mail attribute is strictly required
'attributes.required' => array(
'urn:oid:0.9.2342.19200300.100.1.3',
),
// set the corresponding name format for attributes
'attributes.NameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
// Only expose HTTP-POST binding
'acs.Bindings' => array (
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST'
),
// We want to have a persistent NameID instead of transient in order to be
// able to distinguish users on subsequent visits
'NameIDPolicy' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
// Sign outgoing and verify incoming SAML messages
// 'privatekey' => 'sp.pem',
// 'certificate' => 'sp.crt',
// 'sign.authnrequest' => TRUE,
// 'redirect.sign' => TRUE,
// 'redirect.validate' => TRUE,
// Limit the SAML IdPs that SURFconext lists in the WAYF to
// the following list of IdPs (with entity IDs)
//
// This is essentially a SP-based access control list for IdPs
//'IDPList' => array (
// 'https://frkosp.wind.surfnet.nl/simplesamlphp/saml2/idp/metadata.php',
// 'https://idp.surfnet.nl',
//),
// The maximum number of proxies allowed, since SURFconext is
// a proxy and the institute may have one we set this to 2.
// 'ProxyCount' => 2,
),
SURFconext as Identity Provider
Also, the configuration of SURFconext (as an IdP to this SP) needs to be added to simpleSAMLphp in metadata/saml20-idp-remote.php:
$metadata['https://engine.surfconext.nl/authentication/idp/metadata'] = array (
'SingleSignOnService' => 'https://engine.surfconext.nl/authentication/idp/single-sign-on/key:20181213',
'certificate' => 'surfconext.pem',
// convert OID formatted attributes from SAML assertion to 'name' similar to LDAP
// so they will be available as 'mail' and 'displayName'
'authproc' => array(
50 => array(
'class' => 'core:AttributeMap', 'oid2name',
),
),
);
Signing AuthnRequests
As an SP it is possible to sign your AuthnRequests you send towards SURFconext. This is OPTIONAL as using TLS/SSL is enough to prevent attacks. See also the simpleSAMLphp manual about signing.
First you generate a certificate and private key using OpenSSL:
$ openssl req -subj '/O=SURFnet, CN=FrKo Service Provider/' -newkey rsa:2048 -new -x509 -days 3652 -nodes -out sp.crt -keyout sp.pem
Put these certificates in the cert/ directory and modify the SAML SP configuration in config/authsources.php, see the commented out section in the example above.
If you want to do key rollover in your SP, follow the excellent manual in simpleSAMLphp here.
Verifying your signed AuthnRequest has to be explicitly enabled in SURFconext, by default all signatures on the AuthnRequest are ignored.
Write an Application
In order to use this in your application, the following snippet will be illustrative.
Your application SHOULD use the NameID "Value" to uniquely identify users for new deployments. For existing SPs this is of course usually not possible or would require mapping.
<?php
require_once('/var/simplesamlphp/lib/_autoload.php');
$as = new SimpleSAML_Auth_Simple('SURFconext');
$as->requireAuth();
echo "<h1>NameID</h1>";
echo "<pre>";
print_r($as->getAuthData("saml:sp:NameID"));
echo "</pre>";
echo "<h1>IdP</h1>";
echo "<pre>";
print_r($as->getAuthData("saml:sp:IdP"));
echo "</pre>";
echo "<h1>SessionIndex</h1>";
echo "<pre>";
print_r($as->getAuthData("saml:sp:SessionIndex"));
echo "</pre>";
echo "<h1>Attributes</h1>";
echo "<pre>";
print_r($as->getAttributes());
echo "</pre>";
?>
See the simpleSAMLphp SP API for more detailed information.
Further steps
We recommend you consider Securing your simpleSAMLphp setup.