documentation:1.2:samlservice

SAML service configuration

SAML service configuration is a common step to configure LL::NG as SAML SP or SAML IDP.

This documentation explains how configure SAML service in LL::NG, in particular:

  • Install prerequisites
  • Import or generate security keys
  • Set SAML end points
Service configuration will be used to generate LL::NG SAML metadata, that will be shared with other providers. It means that if you modify some settings here, you will have to share again the metadata with other providers. In other words, take the time to configure this part before sharing metadata.

SAML2 implementation is based on Lasso. You will need a very recent version of Lasso (>= 2.3.0).

Debian/Ubuntu

There are packages available here: http://deb.entrouvert.org/.

You will only need to install liblasso3-perl package:

sudo apt-get install liblasso3-perl

RHEL/CentOS/Fedora

RPMs are available at http://repo.cyrus-project.org/centos$releasever-$basearch/RPMS.cyrus-extras/

Fill $releasever and $basearch with the correct values to get packages for your environment, for example http://repo.cyrus-project.org/centos5-i386/RPMS.cyrus-extras/

Then install lasso and lasso-perl packages.

Other

Download the Lasso tarball and compile it on your system.

Be sure that mod_rewrite is installed and that SAML2 rewrite rules are activated in Apache portal configuration:

<IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteRule ^/saml/metadata /metadata.pl
        RewriteRule ^/saml/.* /index.pl
</IfModule>

Go in Manager and click on SAML 2 Service node.

You can use #PORTAL# in values to replace the portal URL.

Entry Identifier

Your EntityID, often use as metadata URL, by default #PORTAL#/saml/metadata.

The value will be use in metadata main markup:
<EntityDescriptor entityID="http://auth.example.com/saml/metadata">
  ...
</EntityDescriptor>
If you modify /saml/metadata suffix you have to change corresponding Apache rewrite rule.

You can define keys for SAML message signature and encryption. If no encryption keys are defined, signature keys are used for signature and encryption.

To define keys, you can:

  • import your own private and public keys (Load from a file input)
  • generate new public and private keys (Generate button)
You can enter a password to protect private key with a password. It will be prompted if you generate keys, else you can set it in the Private key password.

You can import a certificate containing the public key instead the raw public key. However, certificate will not be really validated by other SAML components (expiration date, common name, etc.), but will just be a public key wrapper.

SAML can use different NameID formats. The NameID is the main user identifier, carried in SAML messages. You can configure here which field of LL::NG session will be associated to a NameID format.

This parameter is used by SAML IDP to fill the NameID in authentication responses.

Customizable NameID formats are:

  • Email
  • X509
  • Windows
  • Kerberos
For example, if you are using AD as authentication backend, you can use sAMAccountName for the Windows NameID format.

Other NameID formats are automatically managed:

  • Transient: NameID is generated
  • Persistent: NameID is restored from previous sessions
  • Undefined: Default NameID format is used

Each LL::NG authentication module has an authentication level, which can be associated to an SAML authentication context.

This parameter is used by SAML IDP to fill the authentication context in authentication responses. It will use the authentication level registered in user session to match the SAML authentication context. It is also used by SAML SP to fill the authentication level in user session, based on authentication response authentication context.

Customizable NameID formats are:

  • Password
  • Password protected transport
  • TLS client
  • Kerberos
This concerns all parameters for the Organization metadata section:
<Organization>
  <OrganizationName xml:lang="en">Example</OrganizationName>
  <OrganizationDisplayName xml:lang="en">Example</OrganizationDisplayName>
  <OrganizationURL xml:lang="en">http://www.example.com</OrganizationURL>
</Organization>
  • Display Name: should be displayed on IDP, this is often your society name
  • Name: internal name
  • URL: URL of your society
This concerns all parameters for the Service Provider metadata section:
<SPSSODescriptor>
  ...
</SPSSODescriptor>

General options

  • Signed Authentication Request: set to On to always sign authentication request.
  • Want Assertions Signed: set to On to require that received assertions are signed.
These options can then be overridden for each Identity Provider.

Single Logout

For each binding you can set:

  • Location: Access Point for SLO request.
  • Response Location: Access Point for SLO response.

Available bindings are:

  • HTTP Redirect
  • HTTP POST
  • HTTP SOAP

Assertion Consumer

For each binding you can set:

  • Default: will this binding be used by default for authentication response.
  • Location: Access Point for SSO request and response.

Available bindings are:

  • HTTP Artifact
  • HTTP POST

Artifact Resolution

The only authorized binding is SOAP. This should be set as Default.

This concerns all parameters for the Service Provider metadata section:
<IDPSSODescriptor>
  ...
</IDPSSODescriptor>

General parameters

  • Want Authentication Request Signed: set to On to require that received authentication request are signed.
This option can then be overridden for each Service Provider.

Single Sign On

For each binding you can set:

  • Location: Access Point for SSO request.
  • Response Location: Access Point for SSO response.

Available bindings are:

  • HTTP Redirect
  • HTTP POST
  • HTTP Artifact
  • HTTP SOAP

Single Logout

For each binding you can set:

  • Location: Access Point for SLO request.
  • Response Location: Access Point for SLO response.

Available bindings are:

  • HTTP Redirect
  • HTTP POST
  • HTTP SOAP

Artifact Resolution

The only authorized binding is SOAP. This should be set as Default.

This concerns all parameters for the Attribute Authority metadata section
<AttributeAuthorityDescriptor>
  ...
</AttributeAuthorityDescriptor>

Attribute Service

This is the only service to configure, and it accept only the SOAP binding.

Response Location should be empty, as SOAP responses are directly returned (synchronous binding).

These parameters are not mandatory to run SAML service, but can help to customize it:

  • IDP resolution cookie name: by default, it's the LL::NG cookie name suffixed by idp, for example: lemonldapidp.
  • UTF8 metadata conversion: set to On to force partner's metadata conversion.

SAML sessions module name and options

By default, the session storage module is used to store SAML temporary data (as relay-states and pending SAML requests).

It is possible to use a different storage module to store SAML data.

This is recommended to improve performances. Indeed, it may be necessary to browse all SAML sessions to retrieve some data : so, dissociate SAML data from SSO sessions prevents from browsing all SSO sessions.

This is mandatory if session storage module is not compatible with the sessions restrictions feature - as Memcached for example.

Common Domain Cookie is also know as WAYF Service.

The common domain is used by SAML SP to find an Identity Provider for the user, and by SAML IDP to register itself in user's IDP list.

Configuration parameters are:

  • Activation: Set to On to enable Common Domain Cookie support.
  • Common domain: Name of the common domain (where common cookie is available).
  • Reader URL: URL used by SAML SP to read the cookie. Leave blank to deactivate the feature.
  • Writer URL: URL used by SAML IDP to write the cookie. Leave blank to deactivate the feature.