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 le profil
Liberty WebSphere
Application
Server. 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 de profil 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 Kerberos Key Distribution Center (KDC) 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 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 de profil
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 de profil Liberty au
moyen d'un mécanisme d'authentification de serveur de profil
Liberty natif. Pour les besoins de cette rubrique, l'exemple d'hôte
de serveur de profil 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 de profil
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 de profil 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 de profil 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 de profil 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
principal de service (SPN) Kerberos
et un fichier de clés pour le serveur de profil Liberty. :
- Créez un compte utilisateur pour le serveur de profil Liberty.
Il s'agit du compte qui est utilisé pour mapper au nom principal de
service Kerberos. Sur les machines Active Directory,
il suffit généralement de sélectionner
, de
cliquer avec le bouton droit sur
Utilisateurs dans le panneau, puis de
sélectionner
. 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
au nom principal de service Kerberos. Ce compte utilisateur
représente le serveur de profil Liberty comme étant un service
Kerberos auprès de KDC. Voici un exemple de la 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.
Voici un exemple de la 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 nom principal de service en double
ne figure dans la forêt
Microsoft à l'aide de
l'une des commandes suivantes :
- Si votre version de commande
Microsoft
setspn prend en charge l'option
-X pour la recherche d'un nom principal de
service 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 nom principal de service 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 noms principaux de
service et de fichiers de clés sur différents
systèmes KDC, voir
Creating a Kerberos service principal name and keytab
file.
- Sur la machine du serveur de profil 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 de profil 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 les informations de configuration
du client,
notamment les emplacements des services 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 au sein des domaines
Kerberos. Pour les serveurs de profil 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 sont obligatoirement en majuscules.
Remarque : Les solutions KDC disponibles ne prennent pas toutes en charge
tous les types de chiffrement. Avant de choisir un type de
chiffrement, assurez-vous que la solution KDC prend en charge
le type de chiffrement que vous voulez utiliser. Pour ce
faire, consultez le manuel Kerberos Administrator's and
User's Guide.
Assurez-vous de disposer d'un type de chiffrement
commun pour le fichier de configuration
Kerberos, le fichier de clés Kerberos, le nom principal de
service 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.
Une fois la commande kinit exécutée, 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 de profil
Liberty.
Vous pouvez activer l'authentification Web SPNEGO en activant la
fonction spnego-1.0 du
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'exécution
forme le nom principal de service au format
suivant :
"HTTP/" + java.net.InetAddress.getLocalHost().getCanonicalHostName();
Si le nom principal de service par défaut ne correspond pas à
ce qui figure dans le fichier krb5.keytab,
vous devez indiquer servicePrincipalNames,
par exemple :
<spnego id="mySpnego" servicePrincipalNames="HTTP/myLibertyMachine.example.com"/>
Remarque : Lorsque la fonction spnego-1.0 est activée
et que
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 pour les fichiers de configuration et les
fichiers de clés Kerberos sur les différentes plateformes sont
fournis plus haut dans cette rubrique.
- Facultatif : indiquez des options de configuration
supplémentaires si besoin.
Le profil Liberty prend en charge de nombreux scénarios
et configurations 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. Voici un
exemple de sample
configuration qui 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" />
...
</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
des cas très rares où vous souhaitez utiliser des noms de principal
kerberos pour l'autorisation,
voir 
Utilisation d'un nom principal kerberos pour une autorisation avec l'authentification SPNEGO. Ces
étapes ne doivent être effectuées qu'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 de profil Liberty, vous ne pourrez 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 version 9 ou
suivante, passez à l'étape suivante. Si vous utilisez
Internet
Explorer version 10 ou suivante, 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 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
de profil 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 de profil 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.