Vous pouvez utiliser la connexion unique
pour les demandes HTTP à l'aide de l'authentification Web SPNEGO
(Simple and Protected GSS-API Negotiation Mechanism) pour WebSphere Application Server Liberty. La connexion unique SPNEGO permet aux utilisateurs
HTTP de se connecter à un contrôleur de domaine
Microsoft® une seule fois depuis leur bureau puis d'obtenir une
connexion unique avec le serveur Liberty.
Avant de commencer
Configurez les logiciels suivants et assurez-vous qu'ils sont
disponibles :
- Microsoft Windows®
Server exécutant un contrôleur de domaine Active Directory
et le centre de distribution de clés (KDC) Kerberos associé. Pour
les besoins de cette rubrique, l'exemple d'hôte
pour contrôleur de domaine est myAdMachine.example.com. Le nom de contrôleur de domaine est
mydomain.example.com
et le nom de domaine Kerberos est
MYDOMAIN.EXAMPLE.COM,
lequel est le nom de contrôleur de domaine en lettres majuscules.
- Membre de domaine (client) Microsoft
Windows®
qui prend en charge le mécanisme d'authentification
SPNEGO tel que défini dans
l'IETF RFC 2478. Un client approprié peut être un navigateur
moderne ou un client Microsoft .NET. La
plupart des navigateurs modernes prennent en charge l'authentification SPNEGO. Pour
les besoins de cette rubrique, l'hôte exemple pour le client est
myClientMachine.example.com.
- Une plateforme de serveur avec un serveur Liberty qui comporte une ressource protégée au sein d'une
application. Les utilisateurs d'Active Directory doivent pouvoir
accéder aux ressources protégées par le serveur Liberty au
moyen d'un mécanisme d'authentification de serveur Liberty natif. Pour les besoins de cette rubrique, l'exemple d'hôte
de serveur Liberty
est myLibertyMachine.example.com.
Remarque : La configuration logicielle doit comporter un contrôleur de domaine en
cours d'exécution, au moins une machine client de ce
domaine et une plateforme de serveur avec un serveur
Liberty comportant une ressource protégée au sein d'une
application, pour un total de trois machines obligatoires. Il n'est
pas possible d'utiliser l'authentification SPNEGO directement à partir du
contrôleur de
domaine.
Remarque : Assurez-vous que les horloges du client, du
serveur Microsoft Active
Directory et du serveur Liberty sont
synchronisées à 5 minutes d'intervalle les unes des autres, et ce par
défaut. La marge de différence permise en termes de
synchronisation est configurable.
Remarque : Seuls les JDK
IBM® sont actuellement pris en
charge. Les JDK non IBM ne sont pas pris en charge.
Pourquoi et quand exécuter cette tâche
L'objectif de cette tâche est d'autoriser les
utilisateurs à accéder aux ressources du serveur Liberty
sans avoir à s'authentifier de nouveau, et ainsi obtenir une
connexion unique du bureau
Microsoft Windows®.
Cette
tâche illustre comment configurer un serveur Liberty pour la prise en charge de la
connexion unique pour les demandes
HTTP à l'aide de authentification Web SPNEGO.
Procédure
- Sur le contrôleur de domaine
Microsoft
(myAdMachine.example.com), créez un nom
de principal de service (SPN) Kerberos et un fichier de clés pour le serveur Liberty :
- Créez un compte utilisateur pour le serveur Liberty. Ce compte est utilisé pour le mappage au nom de principal du service (SPN) Kerberos. Sur les machines Active Directory, cette création
de compte s'effectue généralement en sélectionnant , en cliquant avec le bouton droit sur Utilisateurs dans le panneau,
et en sélectionnant . Cette rubrique suppose que l'utilisateur myLibertyMachine_http a
été créé avec le mot de passe security.
- Exécutez la commande
Microsoft
setspn pour mapper le compte utilisateur
à un SPN Kerberos. Ce compte utilisateur
représente le serveur Liberty comme étant un service
Kerberos auprès du KDC. Exemple de commande setspn :
C:\> setspn -a HTTP/myLibertyMachine.example.com myLibertyMachine_http
Registering ServicePrincipalNames for CN=myLibertyMachine_http,CN=Users,DC=MYDOMAIN,DC=EXAMPLE,DC=COM
HTTP/myLibertyMachine.example.com
Updated object
Remarque : Si la version de votre commande
Microsoft setspn command
prend en charge l'option -S, vous devez utiliser
l'option -S à la place de l'option -A.
- Créez le fichier de clés Kerberos à l'aide de l'outil
Microsoft ktpass. Le nom par défaut de ce fichier est
krb5.keytab.
Exemple de commande ktpass :
C:\> ktpass -out krb5.keytab -princ HTTP/myLibertyMachine.example.com@MYDOMAIN.EXAMPLE.COM -mapUser myLibertyMachine_http -mapOp set -pass security -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL
Targeting domain controller: myAdMachine.MYDOMAIN.EXAMPLE.COM
Using legacy password setting method
Successfully mapped HTTP/myLibertyMachine.example.com to myLibertyMachine_http.
Key created.
Output keytab to krb5.keytab:
Keytab version: 0x502
keysize 93 HTTP/myLibertyMachine.example.com@MYDOMAIN.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x148d643db283327d3f3d44547da8cade)
Assurez-vous qu'aucun SPN en double ne figure dans la forêt Microsoft à l'aide de l'une de ces commandes :
- Si votre version de commande
Microsoft
setspn prend en charge l'option
-X pour la recherche d'un SPN en double, utilisez
setspn -X:
C:\>setspn -X HTTP/myLibertyMachine.example.com
Processing entry 0
found 0 group of duplicate SPNs.
- Vous pouvez également utiliser la commande
Microsoft
ldif. Dans l'exemple ci-après, une entrée est retournée, ce qui signifie qu'il n'y a pas de SPN en double.
C:\>ldifde -f check_SPN.txt -t 3268 -d "" -l servicePrincipalName -r "
(servicePrincipalName=HTTP/myLibertyMachine.example.com)" -p subtree
Connecting to "myAdMachine.MYDOMAIN.EXAMPLE.COM"
Logging in as current user using SSPI
Exporting directory to file check_SPN.txt
Searching for entries...
Writing out entries.
1 entries exported
Pour plus d'informations sur la création de SPN et de fichiers de clés sur différents systèmes du KDC, voir
Création d'un nom de principal de service Kerberos et d'un fichier de clés.
- Sur la machine du serveur Liberty
(myLibertyMachine.example.com),
activez la clé Kerberos et les fichiers de
configuration ainsi que l'authentification Web SPNEGO.
- Copiez le fichier de clés Kerberos du contrôleur de domaine
sur la machine du serveur Liberty. Le nom par défaut de ce
fichier est
krb5.keytab et l'emplacement par défaut
varie en fonction de la
plateforme mais il s'agit du même répertoire que celui du
fichier de configuration Kerberos. Pour les emplacements par défaut
de différentes plateformes, reportez-vous à l'étape suivante.
- Créez un fichier de configuration Kerberos.
Le fichier de configuration Kerberos contient des informations de configuration client. Ces informations incluent les emplacements des KDC pour les domaines d'intérêt, les valeurs
par défaut du domaine Kerberos en cours et les mappages de noms d'hôte sur les domaines Kerberos. Pour les serveurs Liberty, vous devez créer ce
fichier manuellement.
Voici un exemple de fichier de configuration Kerberos pour les plateformes AIX, z/OS, HP-UX ou Solaris (en
fonction de l'emplacement de la clé par défaut) :
[libdefaults]
default_realm = MYDOMAIN.EXAMPLE.COM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
forwardable = true
renewable = true
noaddresses = true
clockskew = 300
udp_preference_limit = 1
[realms]
MYDOMAIN.EXAMPLE.COM = {
kdc = myAdMachine.example.com:88
default_domain = example.com
}
[domain_realm]
.example.com = MYDOMAIN.EXAMPLE.COM
Remarque : Les noms de domaine sont généralement indiqués en lettres
majuscules. Si vous utilisez Microsoft Active Directory, les noms de domaine doivent apparaître en majuscule.
Remarque : Les solutions du KDC disponibles ne prennent pas toutes en charge tous les types de chiffrement. Avant de choisir un type de chiffrement, vérifiez dans le manuel d'administration et
d'utilisation de Kerberos que le KDC prend en charge le type de chiffrement que vous souhaitez utiliser.
Assurez-vous de disposer d'un type de chiffrement
commun pour le fichier de configuration
Kerberos, le fichier de clés Kerberos, le SPN Kerberos et le client Kerberos. Par exemple, si le client
Kerberos utilise le type de chiffrement
RC4-HMAC, le serveur cible doit aussi prendre en
charge le type de chiffrement
RC4-HMAC et le fichier de configuration
Kerberos doit afficher RC4-HMAC en
premier dans les paramètres default_tgt_enctypes
et default_tkt_enctypes.
Pouf plus
d'informations et pour connaître les contenu requis de ce fichier,
voir
Creating a Kerberos configuration file.
- Vérifiez les fichiers de configuration et
les fichier de clés Kerberos.
Après la commande kinit, vous pouvez utiliser la commande klist pour afficher le ticket Kerberos. Si vous
obtenez le ticket Kerberos, le ficher de clés et le fichier de
configuration Kerberos sont valides.
- Configurez et activez l'authentification Web SPNEGO
sur le serveur Liberty.
Vous pouvez activer l'authentification Web SPNEGO en activant la fonction spnego-1.0 de Liberty.
- Ajoutez la fonction spnego-1.0 au fichier server.xml.
<featureManager>
<feature>spnego-1.0</feature>
<feature>appSecurity-2.0</feature>
...
</featuremanager>
L'ajout de la fonction
spnego-1.0 applique automatiquement une
configuration minimum. Il n'est pas nécessaire de spécifier un
élément <spnego> dans le fichier
server.xml. Sans la spécification d'un élément <spnego>,
la configuration ci-après est implicite.
<spnego
canonicalHostName="true"
disableFailOverToAppAuthType="true"
trimKerberosRealmNameFromPrincipal="true"
includeClientGSSCredentialInSubject="true" />
Remarque : L'environnement d'exécution forme le SPN par défaut au format suivant :
"HTTP/" + java.net.InetAddress.getLocalHost().getCanonicalHostName();
Si le SPN par défaut ne correspond pas à ce qui figure dans le fichier krb5.keytab, vous devez spécifier servicePrincipalNames,
par exemple :
<spnego id="mySpnego" servicePrincipalNames="HTTP/myLibertyMachine.example.com"/>
Remarque : Si la fonction spnego-1.0 est activée
et l'élément <spnego> est omis ou non configuré
avec un attribut authFilterRef, toutes les demandes
d'accès aux ressources protégées utilisent l'authentification SPNEGO.
Pour plus d'informations sur la configuration du filtre
d'authentification, voir
Filtres d'authentification.
Remarque : Lorsque
les valeurs des attributs krb5Config ou
krb5Keytab ne sont pas fournies, chaque fichier
respectif est supposé exister à son emplacement par défaut. Les emplacements par défaut des fichiers de configuration et des fichiers de clés Kerberos sur les différentes plateformes
sont cités plus haut dans cet exemple.
- Facultatif : indiquez des options de configuration
supplémentaires si besoin. Liberty prend en charge un grand nombre de configuration et de scénarios SPNEGO communs. Par exemple, vous pouvez filtrer les demandes HTTP afin d'exiger
l'authentification SPNEGO pour uniquement
certaines demandes, applications Web, certains hôtes ou agents
utilisateur. De plus, vous pouvez déplacer les fichiers de configuration et les
fichiers de clés
Kerberos de leurs emplacements par défaut respectifs. L'exemple de configuration suivant modifie les paramètres <spnego> par défaut :
<server>
<featureManager>
<feature>spnego-1.0</feature>
<feature>appSecurity-2.0</feature>
...
</featureManager>
...
<authFilter id="myAuthFilter">
<host id="myHost" name="example.com" matchType="contains" />
<webApp id="myWebApp" name="protectedApp" matchType="equals" />
</authFilter>
<spnego id="mySpnego"
includeClientGSSCredentialInSubject="false"
krb5Config="${server.config.dir}/resources/security/kerberos/krb5.conf"
krb5Keytab="${server.config.dir}/resources/security/kerberos/krb5.keytab"
servicePrincipalNames="HTTP/myLibertyMachine.example.com"
authFilterRef="myAuthFilter" />
</spnego>
...
</server>
Avec une telle configuration,
l'authentification SPNEGO est utilisée pour toutes les
demandes qui sont reçues et qui contiennent le nom d'hôte
example.com pour les
ressources au sein de l'application Web
protectedApp. En outre, les données d'identification GSS du client ne sont pas
ajoutées à l'objet utilisateur une fois l'authentification réussie. Enfin, des emplacements spécifiques au sein du répertoire de
configuration du serveur sont affectés aux fichiers de
configuration et aux fichiers de clés
Kerberos utilisés par le serveur à la place des emplacements par
défaut respectifs.
Pour plus d'options de configuration, voir
Mécanisme SPNEGO (Simple and Protected GSS-API Negotiation Mechanism).
Pour
plus d'informations sur le mappage des noms de principal Kerberos à des ID de registre d'utilisateurs
WebSphere, voir
Mapping of a client Kerberos principal name to the WebSphere user registry ID.
Dans
le cas rare où vous souhaiteriez utiliser des noms de principal Kerberos à des fins d'autorisation, voir
Utilisation d'un nom principal kerberos pour une autorisation avec l'authentification SPNEGO. Ces étapes
doivent être effectuées uniquement en cas d'absolue nécessité et par des utilisateurs qui choisissent spécifiquement de ne pas
utiliser le mappage par défaut ou le mappage de module de connexion personnalisé JAAS.
- Configurez l'application client sur la machine de cette
dernière (myClientMachine.example.com).
Les étapes ci-après doivent uniquement être effectuées sur le poste client. Si vous démarrez un navigateur
sur le poste Active Directory ou sur le poste du serveur Liberty, vous ne pouvez pas effectuer ces étapes.
Les étapes ci-après sont destinées aux utilisateur qui accèdent
aux ressources protégées par SPNEGO depuis un navigateur. Vous devez
disposer d'un navigateur prenant en charge l'authentification SPNEGO.
Microsoft Internet
Explorer :
- Depuis le bureau, connectez-vous au domaine
Windows Active Directory.
- Dans la fenêtre Internet Explorer, cliquez sur
. Dans la fenêtre qui s'affiche,
cliquez sur l'onglet Sécurité.
- Sélectionnez l'icône Intranet local, puis
cliquez sur Sites.
- Si vous utilisez Internet Explorer 9 ou une version antérieure, passez à l'étape suivante. Si vous utilisez Internet Explorer 10 ou une version ultérieure, cliquez sur
Avancé dans la fenêtre Intranet local.
- Dans la fenêtre Local intranet, renseignez la zone
Ajouter ce site Web à la zone à l'aide de
l'adresse Web du nom d'hôte de sorte que la connexion unique puisse
être activée pour la liste de sites Web affichée dans la zone
relative aux sites Web. Vous pouvez obtenir cette information auprès
du personnel du service informatique de votre entreprise. Fermez la deuxième fenêtre Intranet local et cliquez sur
OK pour terminer cette étape et fermer la
fenêtre Intranet local.
- Dans la fenêtre Options Internet,
cliquez sur Avancé et faites défiler la liste
pour accéder aux paramètres de sécurité. Assurez-vous que l'option
Activer l’authentification Windows intégrée
est sélectionnée.
- Cliquez sur OK. Redémarrez
Microsoft Internet
Explorer pour activer cette configuration.
Mozilla Firefox :
- Depuis le bureau, connectez-vous au domaine
Windows Active Directory.
- Dans la zone d'adresse de Firefox, entrez about:config.
- Dans la zone Filter/Search, entrez network.n.
- Cliquez deux fois sur
network.negotiate-auth.trusted-uris.
Cette
préférence répertorie les sites qui sont autorisées à
initier une authentification SPNEGO auprès du navigateur. Entrez une
liste de domaines ou d'URL de confiance, délimitées par des virgules.
Remarque : Vous devez définir la valeur pour
network.negotiate-auth.trusted-uris.
- Si la solution SPNEGO déployée utilise la fonction avancée
Kerberos de délégation d'accréditation, cliquez deux fois sur
network.negotiate-auth.delegation-uris.
Cette préférence répertorie les sites pour lesquels le navigateur
peut déléguer l'autorisation utilisateur au serveur. Entrez une liste
de domaines ou d'URL de confiance, délimitées par des virgules.
- Cliquez sur OK. La configuration reflète
les mises à jour.
- Redémarrez le navigateur Firefox pour activer cette configuration.
Remarque : L'utilisateur doit être connecté au contrôleur de domaine
que SPNEGO fonctionne. Comme illustré dans les exemples précédents,
un utilisateur doit se connecter au contrôleur de domaine dans
MYDOMAIN.EXAMPLE.COM\username pour que
l'authentification SPNEGO via le navigateur fonctionne.
Remarque : Si vous êtes invité plusieurs fois à entrer un ID utilisateur
et un mot de passe, vérifiez que vous avez activé la prise en charge
SPNEGO dans votre navigateur client à l'aide des
instructions fournies précédemment. Vous devez également vous assurer
que l'attribut disableFailOverToAppAuthType
dans la configuration <spnego> est
défini sur false.
Résultats
Votre navigateur Internet est à présent correctement configuré
pour
l'authentification SPNEGO. Vous pouvez utiliser des applications
comportant des ressources sécurisées qui sont déployées sur des
serveurs
Liberty sans être invité à fournir un ID utilisateur et un mot de passe.
Pour vérifier le fonctionnement de SPNEGO, vous pouvez
vous connecter au contrôleur de domaine et essayer d'accéder à des
ressources protégées sur le serveur Liberty. Comme vous
êtes connecté au contrôleur de domaine, vous n'êtes pas invité
à entrer des données d'identification. Si vous tentez d'accéder à une
ressource protégée alors que vous
n'êtes pas connecté au contrôleur de domaine, vous êtes invité à
entrer des données d'identification.