This documentation explains how configure SAML service in LL::NG, in particular:
Attention
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.6.0).
You can use official Debian packages or those available here: http://deb.entrouvert.org/.
Tip
We recommend Lasso 2.6 for the SHA256 support, so use the stretch-testing repository of deb.entrouvert.org.
You will only need to install liblasso-perl package:
sudo apt-get install liblasso-perl
RPMs are available in LL::NG RPM “extras” repository (see YUM repository)
Then install lasso and lasso-perl packages:
yum install lasso lasso-perl
Attention
Only 64bits package are available.
Download the Lasso tarball and compile it on your system.
Go in Manager and click on SAML 2 Service
node.
Tip
You can use #PORTAL# in values to replace the portal URL.
Your EntityID, often use as metadata URL, by default #PORTAL#/saml/metadata.
Note
The value will be use in metadata main markup:
<EntityDescriptor entityID="http://auth.example.com/saml/metadata">
...
</EntityDescriptor>
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:
Replace by file
input)New keys
button)Tip
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.
Tip
You can easily generate a certificate to replace your public
key by saving the private key in a file, and use openssl
commands to
issue a self-signed certificate:
$ openssl req -new -key private.key -out cert.pem -x509 -days 3650
Attention
Default value is RSA SHA1 for compatibility purpose but we recommend to use RSA SHA256. This requires to test all partners to check their compatibility.
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.
Note
This parameter is used by SAML IDP to fill the NameID in authentication responses.
Customizable NameID formats are:
Tip
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:
Each LL::NG authentication module has an authentication level, which can be associated to an SAML authentication context.
Note
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:
Note
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>
Note
This concerns all parameters for the Service Provider metadata section:
<SPSSODescriptor>
...
</SPSSODescriptor>
Tip
These options can then be overridden for each Identity Provider.
For each binding you can set:
Available bindings are:
For each binding you can set:
Available bindings are:
The only authorized binding is SOAP. This should be set as Default.
Note
This concerns all parameters for the Service Provider metadata section:
<IDPSSODescriptor>
...
</IDPSSODescriptor>
Tip
This option can then be overridden for each Service Provider.
For each binding you can set:
Available bindings are:
For each binding you can set:
Available bindings are:
The only authorized binding is SOAP. This should be set as Default.
Note
This concerns all parameters for the Attribute Authority metadata section
<AttributeAuthorityDescriptor>
...
</AttributeAuthorityDescriptor>
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
, for example: lemonldapidp
.https://auth.example.com/saml/metadata/idp
.By default, the main session module is used to store SAML temporary data (like relay-states), but SAML sessions need to use a session module compatible with the sessions restrictions feature.
Tip
You can also choose a different session module to split SSO sessions and SAML sessions.
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:
Note
Discovery Protocol is also know as WAYF Service. More information can be found in the specification: sstc-saml-idp-discovery-cs-01.pdf.
When Discovery Protocol is enabled, the LL::NG IDP list is no more used. Instead user is redirected on the discovery service and is redirected back to LL::NG with the chosen IDP.
Attention
If the chosen IDP is not registered in LL::NG, user will be redirected to discovery service again.
Configuration parameters are:
urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol:single
)