# documentation:2.0:samlservice
Keywords: documentation,2.0,samlservice

# Configuration du service SAML

La configuration du service SAML est une étape commune pour configurer LL::NG comme fournisseur de service SAML (SP) ou fournisseur d'identité SAML (IDP).

## Présentation

Cette documentation explique comment configurer le service SAML dans LL::NG, en particulier :

- Installer les pré-requis
- Importer ou generer les clefs de securité
- Indiquer les points d'entrées SAML

La configuration du service est utilisée pour générer les métadatas SAML de LL::NG, qui sont partagées avec les autres fournisseurs. Ceci signifie que si vous modifiez quelque chose ici, vous devez ré-exporter les metadatas aux autres fournisseurs. En d'autres mots, prenez le temps de bien configurer cette partie avant de partager les metadatas.

## Pré-requis

### Lasso

L'implementation SAML est basée sur Lasso. Vous devez utiliser une version récente de Lasso (>= 2.3.0).

#### Debian/Ubuntu

Les paquets sont disponibles ici : http://deb.entrouvert.org/.

You will only need to install liblasso-perl package:

    sudo apt-get install liblasso-perl

#### RHEL/CentOS/Fedora

RPMs are available in LL::NG RPM repository (see yum_repository)

Then install lasso and lasso-perl packages:

    yum install lasso lasso-perl

Only EL6 64bits and EL7 64bits package are available.

#### Autres

Téléchargez l'archive Lasso et compilez là sur votre système.

### Rewrite rules

#### Apache

Assurez-vous que mod_rewrite est installé et que les règles de réécriture SAML2 sont activées dans la configuration Apache du portail:

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

#### Nginx

Be sure that SAML2 rewrite rules are activated in Nginx portal configuration:

      # Fournisseur d'identité SAML2
      rewrite ^/saml/metadata /metadata.pl last;
      rewrite ^/saml/.* /index.pl last;

## Configuration du service

Allez dans le Manager et cliquez sur le nœud `Service SAML 2`.

Vous pouvez utiliser le mot clef #PORTAL# dans les valeurs pour remplacer l'URL du portail.

### Identifiant d'entrée

Votre EntityID, souvent utilisé comme URL des métadatas, par défaut #PORTAL#/saml/metadata.

Cette valeur est utilisé dans les metadatas :

    <EntityDescriptor entityID="http://auth.example.com/saml/metadata">
      ...
    </EntityDescriptor>

Si vous modifiez le suffixe `/saml/metadata`, vous devez changer la règle de réécriture d'Apache.

### Paramètres de sécurité

Vous pouver définir des clefs pour la signature et le chiffrement des messages SAML. Si aucune clef de chiffrement n'est définie, la clef de signature est aussi utilisée pour le chiffrement.

Pour définir les clefs, vous pouvez :

- import your own private and public keys (`Replace by file` input)
- generate new public and private keys (`New keys` button)

Vous pouvez entrer un mot de passe de protection de la clef privée. Il vous sera demandé à la génération de la clef ou vous pouvez l'entrer dans le champ `Mot-de-passe de la clef privée`.

Vous pouver importer un certificat contenant la clef publique au lieu d'une simple clef. Toutefois, le certificat ne sera pas réellement validé par les autres composants SAML (date d'expiration, nom commun, etc.), mais simplement vu comme un conteneur de clef publique.

You can force LL::NG to use this certificate in SAML responses by enabling Use certificate in response option.

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.csr
    $ openssl x509 -req -days 3650 -in cert.csr -signkey private.key -out cert.pem

### Formats de NameID

SAML peut utiliser plusieurs formats de NameID. NameID est l'identifiant principal de l'utilisateur transmis dans les messages SAML. Vous pouvez indiquer ici l'attribut de session de LL::NG qui sera associé au format du NameID.

Ce paramètre est utilisé par l'IdP SAML pour construire le NameID dans les réponses d'authentification.

Les formats de NameID personnalisables sont :

- Email
- X509
- Windows
- Kerberos

Par exemple, si vous utilisez Active-Directory comme système d'authentification, vous pouvez utiliser sAMAccountName come format de NameID Windows.

Les autres formats de NameID sont automatiquement gérés :

- Transient: le NameID est généré
- Persistent: le NameID est restoré depuis la session précédente
- Undefined: le format de NameID par défaut est utilisé

### Contextes d'authentification

Chaque module d'authentification de LL::NG dispose d'un niveau d'authentification qui peut être associé à un contexte d'authentification SAML.

Ce paramètre est utilisé par l'IdP SAML pour renseigner le contexte d'authentification dans les réponses. Il utilise le niveau d'authentification enregistré dans la session de l'utilisateur pour établir le contexte d'authentification SAML. Il est également utilisé par le SP SAML pour définir le niveau d'authentification dans la session de l'utilisateur en se basant sur la réponse d'authentification.

Les formats de NameID personnalisables sont :

- Mot-de-passe
- Transport protégé du mot-de-passe
- Client TLS
- Kerberos

### Organisation

Ceci concerne tous les paramètres de la section "organization" des métadatas :

    <Organization>
      <OrganizationName xml:lang="en">Exemple</OrganizationName>
      <OrganizationDisplayName xml:lang="en">Exemple</OrganizationDisplayName>
      <OrganizationURL xml:lang="en">http://www.example.com</OrganizationURL>
    </Organization>

- Nom affiché (display name) : peut être affiché par le fournisseur d'identité (IDP), this is often your society name
- Name: nom interne
- URL: URL de votre organisation

### Fournisseur de service

Ceci concerne tous les paramètres de la section « fournisseur de service » des metadatas :

    <SPSSODescriptor>
      ...
    </SPSSODescriptor>

#### Options générales

- Requête d'authentification signée : mettre à « activé » pour toujours signer les requêtes d'authentifications.
- Exiger des assertions signées : mettre à « activé » pour exiger de recevoir des assertions signées.

Ces options peuvent être surchargées pour chaque fournisseur d'identité.

#### Single Logout (SLO)

Pour chaque déclaration, vous pouvez indiquer :

- Location: Point d'accès pour les requêtes de SLO.
- Response Location: Point d'accès pour les réponses SLO.

Les déclarations disponibles sont :

- HTTP Redirect
- HTTP POST
- HTTP SOAP

#### Consommateur d'assertions

Pour chaque déclaration, vous pouvez indiquer :

- Défaut : déclaration utilisée par défaut pour les réponses d'authentification.
- Location: Point d'accès des requêtes et réponses SSO.

Les déclarations disponibles sont :

- HTTP Artifact
- HTTP POST

#### Résolution des artifacts

The only authorized binding is SOAP. Peut être défini par défaut.

### Fournisseur d'identité

Ceci concerne tous les paramètres de la section « fournisseur de service » des metadatas :

    <IDPSSODescriptor>
      ...
    </IDPSSODescriptor>

#### Paramètres généraux

- Exiger des requêtes d'authentification signées : mettre à « activer » pour exiger de recevoir des requêtes d'authentification signées.

Cette option peut être surchargée pour chaque fournisseur de service.

#### Authentification unique (Single Sign On)

Pour chaque déclaration, vous pouvez indiquer :

- Location: Point d'accès pour les requêtes SSO.
- Response Location : Point d'accès pour les réponses SSO.

Les déclarations disponibles sont :

- HTTP Redirect
- HTTP POST
- HTTP Artifact
- HTTP SOAP

#### Single Logout (SLO)

Pour chaque déclaration, vous pouvez indiquer :

- Location: Point d'accès pour les requêtes de SLO.
- Response Location: Point d'accès pour les réponses SLO.

Les déclarations disponibles sont :

- HTTP Redirect
- HTTP POST
- HTTP SOAP

#### Résolution des artifacts

The only authorized binding is SOAP. Peut être défini par défaut.

### Autorité d'attributs

Ceci concerne tous les paramètres de la section « autorité d'attributs » des métadatas

    <AttributeAuthorityDescriptor>
      ...
    </AttributeAuthorityDescriptor>

#### Service d'attribut

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).

### Avancé

Ces paramètres ne sont pas obligatoires pour faire fonctionner le service SAML, mais peuvent aider à leur personnalisation :

- Nom du cookie de résolution de l'IDP: par défaut, c'est le nom du cookie LL::NG auquel est adjoint `idp`, par exemple: `lemonldapidp`.
- Conversion des métadatas un UTF8 : mettre à « activé » pour forcer la conversion des métadata des partenaires.

#### Options et nom du module de sessions SAML

Par défautBy, le module de session principal est utilisé pour stocker les données temporaires SAML (tel les états de relais), mais les sessions SAML doivent disposer d'un module compatible avec les fonctionnalités de restrictions des sessions.

C'est par exemple le cas de Memcached. Dans ce cas, vous devez utiliser un module différent pour gérer les sessions SAML.

Vous pouvez également utiliser un module différent pour répartir les sessions SSO et SAML.

- Durée de vie d'une session RelayState : durée de vie d'une session RelayState. Par défaut, la session RelayState est détruite lorsqu'elle est lue. 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.

#### Domaine commun de cookie

Le domaine commun de cookie est également connu comme service WAYF.

Le domaine commun est utilisé par le SP SAML pour trouver le fournisseur d'identité de l'utilisateur et par l'IdP SAML pour s'enregistrer dans la liste des IDP.

Les paramètres de configuration sont :

- Activation : mettre à « activé » pour activer le support du domaine commun de cookie.
- Domaine commun : Nom du domaine commun (où le cookie commun est disponible).
- URL de lecture : URL utilisée par le SP SAML pour lire le cookie. Laissez vide pour désactiver cette fonctionnalité.
- URL d'écriture : URL utilisée par l'IdP SAML pour écrire le cookie. Laissez vide pour désactiver cette fonctionnalité.