Documentation : Authentication configuration, consortium Shibboleth

Le but de cette partie est de configurer l'IDP pour utiliser un annuaire LDAP pour l'authentification des utilisateurs.
Nous allons définir le mode d'authentification de notre fournisseur d'identités. L'IdP Shibboleth propose plusieurs connecteurs d'authentifications, appelés login flows :

• Password : permet une authentification par saisie de l'identifiant/mot de passe. Plusieurs types de backends sont proposés :
  • LDAP,
  • Kerberos ;
  • JAAS : JAAS (Java Authentication and Authorization Service) est une API d'authentification Java. PLusieurs modules d'authentification sont disponibles,
• RemoteUser : ce login flow repose sur un mécanisme d'authentification externe (HTTP BASIC auth, LDAP, Kerberos, SSO, etc.). Mais ce login flow ne permet pas l'utilisation de fonctions avancées (passive authentication, forced authentication). Pour un branchement avec un SSO externe, les développeur de Shibboleth recommandent l'utilisation d'un login flow de type External.
• RemoteUserInternal : variante du login flow RemoteUser adapté à des scénarios où le client n'est pas un navigateur web (profil ECP),
• X509 : authentification par certificat client TLS,
• X509Internal : variante du login flow X509 adapté à des scénarios où le client n'est pas un navigateur web,
• IPAddress : permet une authentification basée sur l'adresse IP du client. Ce login flow associe un username à une adresse IP,
• External : permet de reposer sur un mécanisme d'authentification externe. Ce login flow peut nécessiter l'écriture de code pour déclencher l'authentification externe.

Le premier annuaire LDAP mis à disposition dans le cadre de ce TP autorise les connexions anonymes, et autorise également les authentifications sur un canal non sécurisé. Nous allons donc configurer l'IdP pour utiliser une stratégie de type anonSearchAuthenticator, correspondant à une première connexion anonyme destinée à rechercher l'identifiant LDAP (Distinguished Name) de l'utilisateur, puis à tenter une nouvelle connexion authentifiée avec son mot de passe.

Ceci se fait dans le fichier /opt/shibboleth-idp/conf/ldap.properties :

# LDAP authentication configuration, see authn/ldap-authn-config.xml
# Note, this doesn't apply to the use of JAAS

## Authenticator strategy, either anonSearchAuthenticator, bindSearchAuthenticator, directAuthenticator, adAuthenticator
**idp.authn.LDAP.authenticator                   = anonSearchAuthenticator**

## Connection properties ##
**idp.authn.LDAP.ldapURL                          = ldap://ldap.cru.fr:389**
**idp.authn.LDAP.useStartTLS                     = false**
#idp.authn.LDAP.useSSL                          = false
# Time in milliseconds that connects will block
#idp.authn.LDAP.connectTimeout                  = PT3S
# Time in milliseconds to wait for responses
#idp.authn.LDAP.responseTimeout                 = PT3S

[...]

## DN resolution properties ##

# Search DN resolution, used by anonSearchAuthenticator, bindSearchAuthenticator
# for AD: CN=Users,DC=example,DC=org
**idp.authn.LDAP.baseDN                           = ou=people,dc=univ-test,dc=fr**
#idp.authn.LDAP.subtreeSearch                   = false
idp.authn.LDAP.userFilter                       = (uid={user})
# bind search configuration
# for AD: idp.authn.LDAP.bindDN=adminuser@domain.com
**idp.authn.LDAP.bindDN                           =**
**idp.authn.LDAP.bindDNCredential                 =**

Redémarrez le serveur Tomcat pour que les modifications prennent effet :

$> sudo systemctl restart tomcat

Vous pouvez à présent revenir sur votre SP non fédéré https://formsfede-014.renater.fr/sp-ABC, cliquer sur Connexion et entrer un des comptes de tests disponibles (cf. Le fournisseur d'identité de test RENATER). Par exemple etudiant1/etudiant1.

Une fois la connexion réussie, vous arrivez normalement sur cette page :

On peut constater que le tableau du haut, chargé de lister les attributs est vide. Ce qui est normal, puisque les règles de récupération et de diffusion des attributs n'ont pas encore été configurées. Le tableau du bas montre les informations mises à disposition par le SP aux applications qu'il protège.

Le deuxième annuaire LDAP mis à disposition n'autorise pas les connexions anonymes, et impose l'utilisation d'un canal sécurisé pour toute authentification. Nous allons donc passer à une stratégie de type bindSearchAuthenticator, similaire à la précédente à ceci près qu'elle utilise un compte dédié pour effectuer la recherche.

Le fichier ldap.properties devient alors:

# LDAP authentication configuration, see authn/ldap-authn-config.xml
# Note, this doesn't apply to the use of JAAS

## Authenticator strategy, either anonSearchAuthenticator, bindSearchAuthenticator, directAuthenticator, adAuthenticator
**idp.authn.LDAP.authenticator                   = bindSearchAuthenticator**

## Connection properties ##
**idp.authn.LDAP.ldapURL                       = ldaps://test-ldap.federation.renater.fr:636**
idp.authn.LDAP.useStartTLS                     = false
**idp.authn.LDAP.useSSL                          = true**
# Time in milliseconds that connects will block
#idp.authn.LDAP.connectTimeout                  = PT3S
# Time in milliseconds to wait for responses
#idp.authn.LDAP.responseTimeout                 = PT3S

## SSL configuration, either jvmTrust, certificateTrust, or keyStoreTrust
#idp.authn.LDAP.sslConfig                       = certificateTrust
## If using certificateTrust above, set to the trusted certificate's path
**idp.authn.LDAP.trustCertificates                = /etc/pki/tls/certs/test-ldap.federation.renater.fr.crt**
## If using keyStoreTrust above, set to the truststore path
idp.authn.LDAP.trustStore                       = %{idp.home}/credentials/ldap-server.truststore

[...]

## DN resolution properties ##

# Search DN resolution, used by anonSearchAuthenticator, bindSearchAuthenticator
# for AD: CN=Users,DC=example,DC=org
**idp.authn.LDAP.baseDN                           = ou=people,dc=renater,dc=fr**
**idp.authn.LDAP.subtreeSearch                   = true **
idp.authn.LDAP.userFilter                       = (uid={user})
# bind search configuration
# for AD: idp.authn.LDAP.bindDN=adminuser@domain.com
**idp.authn.LDAP.bindDN                           = cn=read,dc=renater,dc=fr**
**idp.authn.LDAP.bindDNCredential                 = read**

Pour établir la connexion TLS entre l'IDP et le LDAP, vous aurez besoin de récupérer le certificat de l'annuaire. Récupération certificat pour le LDAPS à coller dans le fichier /etc/pki/tls/certs/test-ldap.federation.renater.fr.crt :

$> openssl s_client -showcerts -connect test-ldap.federation.renater.fr:636
CONNECTED(00000005)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4
verify return:1
depth=0 C = FR, L = Paris, O = Renater, CN = test-ldap.federation.renater.fr
verify return:1
---
Certificate chain
 0 s:C = FR, L = Paris, O = Renater, CN = test-ldap.federation.renater.fr
   i:C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4
**-----BEGIN CERTIFICATE-----  **
**MIIHgTCCBWmgAwIBAgIQFPeZjfXHfXmck+p7Ksqd/DANBgkqhkiG9w0BAQwFADBE**
**MQswCQYDVQQGEwJOTDEZMBcGA1UEChMQR0VBTlQgVmVyZW5pZ2luZzEaMBgGA1UE**
**AxMRR0VBTlQgT1YgUlNBIENBIDQwHhcNMjEwNTI1MDAwMDAwWhcNMjIwNTI1MjM1**
**[...]**
**RbFdIG5mmgjYsfVNfCMOR/coGP4I3bA/kE1fgyj+KoCC62U8woDd5HuX8++PbAhN**
**KFuCTxuuagFtplNK8AfktxgRq9Bo2ppbRHwvxyIIOnvIERYwyg3MEV4Wx9IvsjVn**
**ZbJJPyDf8zPNcJMOwt3Smv2X4JgAsUumbuojZQ+Syr9Azc3NsQP5lJ5uFHCO3Z0s**
**7tfDaX4=**
**-----END CERTIFICATE-----  **
 [...]

Dans un autre contexte que le TP, vous devez vous adapter à la politique de votre annuaire LDAP, notamment pour ce qui concerne les points suivants:

• est-il nécessaire d'effectuer une recherche préalable pour identifier le DN de l'utilisateur final, ou celui-ci est-il déductible de l'attribut utilisé pour son authentification ?
• s'il faut effectuer une recherche préalable, est-il possible d'utiliser une connexion anonyme, ou faut-il utiliser un couple utilisateur/mot de passe dédié ?
• est-il possible d'effectuer une authentification sur une connexion non sécurisée, ou non ?