Differences
This shows you the differences between two versions of the page.
— |
documentation:2.1:samlservice [2019/09/02 22:21] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== SAML service configuration ====== | ||
+ | < | ||
+ | |||
+ | ===== Presentation ===== | ||
+ | |||
+ | This documentation explains how configure SAML service in LL::NG, in particular: | ||
+ | * Install prerequisites | ||
+ | * Import or generate security keys | ||
+ | * Set SAML end points | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | ===== Prerequisites ===== | ||
+ | |||
+ | ==== Lasso ==== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | SAML2 implementation is based on [[http:// | ||
+ | |||
+ | === Debian/ | ||
+ | |||
+ | You can use official Debian packages or those available here: [[http:// | ||
+ | |||
+ | <note 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 | ||
+ | </ | ||
+ | |||
+ | === RHEL/ | ||
+ | |||
+ | RPMs are available in LL::NG RPM " | ||
+ | |||
+ | Then install lasso and lasso-perl packages: | ||
+ | < | ||
+ | yum install lasso lasso-perl | ||
+ | </ | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | === Other === | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | |||
+ | ===== Service configuration ===== | ||
+ | |||
+ | Go in Manager and click on '' | ||
+ | |||
+ | <note tip>You can use #PORTAL# in values to replace the portal URL.</ | ||
+ | |||
+ | ==== Entry Identifier ==== | ||
+ | |||
+ | Your EntityID, often use as metadata URL, by default # | ||
+ | |||
+ | < | ||
+ | The value will be use in metadata main markup: | ||
+ | <file xml> | ||
+ | < | ||
+ | ... | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | ==== Security parameters ==== | ||
+ | |||
+ | 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 ('' | ||
+ | * generate new public and private keys ('' | ||
+ | |||
+ | <note 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 '' | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | 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. | ||
+ | |||
+ | <note tip> | ||
+ | You can easily generate a certificate to replace your public key by saving the private key in a file, and use '' | ||
+ | < | ||
+ | $ openssl req -new -key private.key -out cert.pem -x509 -days 3650 | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | * **Use certificate in response**: Certificate will be sent inside SAML responses. | ||
+ | * **Signature method**: set the signature algorithm | ||
+ | |||
+ | <note important> | ||
+ | ==== NameID formats ==== | ||
+ | |||
+ | 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: | ||
+ | |||
+ | * X509 | ||
+ | * Windows | ||
+ | * Kerberos | ||
+ | |||
+ | <note tip>For example, if you are using [[authldap|AD as authentication backend]], you can use sAMAccountName for the Windows NameID format.</ | ||
+ | |||
+ | Other NameID formats are automatically managed: | ||
+ | * **Transient**: | ||
+ | * **Persistent**: | ||
+ | * **Undefined**: | ||
+ | |||
+ | ==== Authentication contexts ==== | ||
+ | |||
+ | Each LL::NG authentication module has an authentication level, which can be associated to an [[http:// | ||
+ | |||
+ | < | ||
+ | |||
+ | Customizable NameID formats are: | ||
+ | * Password | ||
+ | * Password protected transport | ||
+ | * TLS client | ||
+ | * Kerberos | ||
+ | |||
+ | ==== Organization ==== | ||
+ | |||
+ | < | ||
+ | This concerns all parameters for the Organization metadata section: | ||
+ | <file xml> | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | * **Display Name**: should be displayed on IDP, this is often your society name | ||
+ | * **Name**: internal name | ||
+ | * **URL**: URL of your society | ||
+ | |||
+ | ==== Service Provider ==== | ||
+ | |||
+ | < | ||
+ | This concerns all parameters for the Service Provider metadata section: | ||
+ | <file xml> | ||
+ | < | ||
+ | ... | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | === 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. | ||
+ | |||
+ | <note tip> | ||
+ | |||
+ | === Single Logout === | ||
+ | |||
+ | For each binding you can set: | ||
+ | * **Location**: | ||
+ | * **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**: | ||
+ | * **Location**: | ||
+ | |||
+ | Available bindings are: | ||
+ | * HTTP Artifact | ||
+ | * HTTP POST | ||
+ | |||
+ | === Artifact Resolution === | ||
+ | |||
+ | The only authorized binding is SOAP. This should be set as Default. | ||
+ | |||
+ | ==== Identity Provider ==== | ||
+ | |||
+ | < | ||
+ | This concerns all parameters for the Service Provider metadata section: | ||
+ | <file xml> | ||
+ | < | ||
+ | ... | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | === General parameters === | ||
+ | |||
+ | * **Want Authentication Request Signed**: set to On to require that received authentication request are signed. | ||
+ | |||
+ | <note tip>This option can then be overridden for each Service Provider.</ | ||
+ | |||
+ | === Single Sign On === | ||
+ | |||
+ | For each binding you can set: | ||
+ | * **Location**: | ||
+ | * **Response Location**: Access Point for SSO response. | ||
+ | |||
+ | Available bindings are: | ||
+ | * HTTP Redirect | ||
+ | * HTTP POST | ||
+ | * HTTP Artifact | ||
+ | |||
+ | === Single Logout === | ||
+ | |||
+ | For each binding you can set: | ||
+ | * **Location**: | ||
+ | * **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. | ||
+ | |||
+ | ==== Attribute Authority ==== | ||
+ | |||
+ | < | ||
+ | This concerns all parameters for the Attribute Authority metadata section | ||
+ | <file xml> | ||
+ | < | ||
+ | ... | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | === 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). | ||
+ | |||
+ | ==== Advanced ==== | ||
+ | |||
+ | 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 '' | ||
+ | * **UTF8 metadata conversion**: | ||
+ | * **RelayState session timeout**: timeout for RelayState sessions. By default, the RelayState session is deleted when it is read. This timeout allows one to purge sessions of lost RelayState. | ||
+ | * **Use specific query_string method**: the CGI query_string method may break invalid URL encoded signatures (issued for example by ADFS). This option allows one to use a specific method to extract query string, that should be compliant with non standard URL encoded parameters. | ||
+ | * **Override Entity ID when acting as IDP**: By default, SAML entityID is the same for SP and IDP roles. Some federations (like [[renater|Renater]]) can require a different entityID for IDP. In this case, you can fill here the IDP entityID, for example: '' | ||
+ | |||
+ | === SAML sessions module name and options === | ||
+ | |||
+ | By default, the main session module is used to store SAML temporary data (like relay-states), | ||
+ | |||
+ | This is not the case of [[memcachedsessionbackend|Memcached]] for example. In this case, you can choose a different module to manage SAML sessions. | ||
+ | |||
+ | <note tip>You can also choose a different session module to split SSO sessions and SAML sessions.</ | ||
+ | |||
+ | === Common Domain Cookie === | ||
+ | |||
+ | The common domain is used by [[authsaml|SAML SP]] to find an Identity Provider for the user, and by [[idpsaml|SAML IDP]] to register itself in user's IDP list. | ||
+ | |||
+ | Configuration parameters are: | ||
+ | * **Activation**: | ||
+ | * **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. | ||
+ | |||
+ | === Discovery Protocol === | ||
+ | |||
+ | < | ||
+ | |||
+ | 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. | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | Configuration parameters are: | ||
+ | * **Activation**: | ||
+ | * **EndPoint URL**: Discovery service page | ||
+ | * **Policy**: Set a value here if you don't want to use the default policy ('' | ||
+ | * **Is passive**: Enable this option to avoid user interaction on discovery service page |