This documentation explains how configure SAML service in LL::NG, in particular:
SAML2 implementation is based on Lasso. You will need a very recent version of Lasso (>= 2.5.0).
You can use official Debian packages or those available here: http://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
Download the Lasso tarball and compile it on your system.
Go in Manager and click on SAML 2 Service
node.
Your EntityID, often use as metadata URL, by default #PORTAL#/saml/metadata.
<EntityDescriptor entityID="http://auth.example.com/saml/metadata"> ... </EntityDescriptor>
/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:
Replace by file
input)New keys
button)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.
openssl
commands to issue a self-signed certificate:
$ openssl req -new -key private.key -out cert.csr $ openssl x509 -req -days 3650 -in cert.csr -signkey private.key -out cert.pem
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.
Customizable NameID formats are:
Other NameID formats are automatically managed:
Each LL::NG authentication module has an authentication level, which can be associated to an SAML authentication context.
Customizable NameID formats are:
<Organization> <OrganizationName xml:lang="en">Example</OrganizationName> <OrganizationDisplayName xml:lang="en">Example</OrganizationDisplayName> <OrganizationURL xml:lang="en">http://www.example.com</OrganizationURL> </Organization>
<SPSSODescriptor> ... </SPSSODescriptor>
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.
<IDPSSODescriptor> ... </IDPSSODescriptor>
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.
<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
.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.
This is not the case of Memcached for example. In this case, you can choose a different module to manage 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:
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.
Configuration parameters are:
urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol:single
)