Présentation

Cet article présente la configuration pas à pas mais également une section troubleshooting où j’évoque les façons de débuguer les différentes étapes du SSO.

Le SSO est la technique consistant à ne saisir qu’un seul mot de passe durant toute une session utilisateur même si celle-ce s’étend sur plusieurs serveurs ou plusieurs domaines. Plus concrètement dans notre cas, il s’agit de récupérer l’identité d’un utilisateur d’un domaine windows lorsqu’il se connecte sur un serveur d’application J2EE weblogic sans qu’il n’ait besoin de saisir un quelconque login ou mot de passe sur le serveur. Ce fonctionnement reposant sur l’utilisation du protocole Kerberos proposé par le MIT. Il consiste à utiliser un tiers de confiance pour réaliser les phases d’identification d’une personne (l’intranaute) pour un service (l’accès à une ressource weblogic).

Voici l’enchaînement des interactions entrant en jeux durant la phase d’authentification :

1. IE -> Weblogic : L’utilisateur demande une ressource web, par exemple une servlet dans une web-app déployée sur le serveur. Toutefois l’accès à cette servlet est configuré pour nécessiter une authentification de type SSO.
2. Weblogic -> IE : Le serveur weblogic répond à IE qu’il veut un ticket Kerberos en bonne et due forme.
3. IE -> Kerberos sur AD : IE après avoir vérifié que la ressource qui lui demande le ticket est bien dans sa zone de confiance, s’adresse à son contrôleur de domaine principal et lui demande un ticket pour la ressource HTTP hébergée par le serveur weblogic en question (l’adresse réseau ainsi que le type de service étant décrit dans la demande).
4. Kerberos sur AD -> IE : Kerberos après avoir vérifié que la ressource existe bien lui répond en lui retournant un ticket dont seul le service HTTP weblogic sera à même de décrypter. Le ticket n’étant valide que durant un court laps de temps afin de s’assurer que personne ne puisse le décrypter et le réutiliser (le temps de décryption étant de toutefaçon supérieur à la durée de vie du ticket).
5. IE -> Weblogic : IE reçoit le ticket du KDC et le forward automatiquement à Weblogic.
6. Weblogic -> Kerberos sur AD : Weblogic vérifie auprès du serveur Kerberos que celui-ci en est bien l’émetteur. Il décrypte ensuite le ticket et obtient le login de l’utilisateur du domaine Active Directory qui lui rend visite.

Environnement de référence

Afin d’être le plus clair possible voici les données de références utilisées durant toute cette documentation :

• Domaine Active Directory : SDACLIN.FR
• Nom réseau du serveur Active Directory : serverad
• IP du serveur Active Directory : 192.168.1.2
• Port du service kerberos : 88
• Nom réseau du serveur weblogic : serverweblo
• IP du serveur weblogic : 192.168.1.3
• Login et MDP console du server weblogic : weblogic:weblogic
• Nom de l’utilisateur à créer sur Active Directory : weblogicsrv
• SPN à utiliser par weblogic pour contacter le KDC : weblogicsrv@SDACLIN.FR
• SPN qu’un utilisateur IE va utiliser pour référencer le server weblo HTTP/serverweblo.sdaclin.fr@SDACLIN.FR
• Adresse sur laquelle est déployée la webapp “Kerberos” de test http://serverweblo:7001/Kerberos
• Nom réseau du poste client du domaine SDACLIN.FR : laptopsdaclin
• Le poste client utilise une version IE 6 SP2
• Le serverAd est de type windows server 2003
• Le server weblogic est en version weblogic 8.1 SP6, il utilise une JVM jdk142_11 fournie par BEA et tourne sur un windows XP SP2
  

Configuration

La configuration se déroule en 4 étapes :

1. Etape 1 – Création d’un utilisateur dédié au SSO dans AD qui représentera le service weblogic.
2. Etape 2 – Ajout d’un mapping entre l’utilisateur créé dans AD et un nouveau compte de service compatible Kerberos qui sera utilisé par weblogic. Ce mapping sera ensuite exporté sous forme d’un fichier .keytab sur le serveur weblogic.
3. Etape 3 – Configuration du serveur weblogic pour l’utilisation du SSO
4. Etape 4 – Création d’une web-app de test à déployer sur weblogic

Etape 1 – Création d’un utilisateur sur l’AD (sur serverad)

1. Création d’un utilisateur pour le serveur weblogic (cet utilisateur permettra d’utiliser le KDC pour décoder les jetons kerberos et vérifier l’identité de l’utilisateur connecté).
   1. Lancer Programs/Administrative Tools/Active Directory Users and Computers tool.
   2. Clic droit sur  le noeud Users et sélectionner New/User (Ne pas créer une machine).
   3. Saisir dans les champs “Full Name” et dans “Logon Name” la valeur weblogicsrv.
   4. Cliquer sur Next et entrer le mot de passe weblogicsrv.
   5. S’assurer qu’aucune option de mot de passe n’est sélectionnée et cliquer sur Next.
   6. Cliquer sur Finish.
2. Modification des propriétés de l’utilisateur AD :
   1. Repérer le nouvel utilisateur weblogicsrv
   2. Clic droit sur l’utilisateur et sélectionner Propriétés
   3. Cliquer sur l’onglet Account
   4. Cocher la case Use DES encryption types for this account.
   5. Vérifier qu’aucune autre option n’est cochée
   6. Cliquer sur OK
3. Cliquer avec le bouton droit de la souris sur l’utilisateur et re-saisir son mot de passe weblogicsrv car il peut avoir été corrompu par le changement d’encodying vers DES.

Précision : j’utilise le compte weblogicsrv car le login weblogic tout court peut interférer avec le login interne weblogic configuré à la création du domaine. De plus les documentations de mise en place du SSO proposent de nommer l’utilisateur avec le nom réseau de la machine (ici il s’agirait de serverweblo) cependant il pourrait y avoir confusion entre le nom Active directory de l’utilisateur (CN=Users) et le nom de la machine (CN=computers). Le nom weblogicsrv quant à lui est totalement neutre.

Etape 2 – Création d’un SPN Kerberos et génération d’un fichier .keytab (sur serverad)

Le SPN (Service Provider Name) est un nom de service Kerberos, il est définit en complément du login créé à l’étape 1 dans Active Directory car celui-ci n’est pas compatible Kerberos.
La démarche correspond à créer un nom de service qui pourra identifier le service weblogic quand un utilisateur voudra y faire référence auprès du KDC. Ce nom de service Kerberos devra être associé à l’utilisateur Active Directory créé à l’étape précédente sans quoi Kerberos ne pourra faire un lien entre les deux entités.

Le nom de service Kerberos (syn de SPN) que l’on va créer est HTTP/serverweblo.sdaclin.fr.
HTTP représentant le type de service, en l’occurrence une demande d’authentification pour un service Web. Ce nom n’est pas choisi au hasard, il est défini par weblogic lorsqu’il demande au client un jeton kerberos. IE devra donc trouver cette clef dans le domaine auquel il appartient.
Le nom de service Kerberos totalement qualifié sera HTTP/serverweblo.sdaclin.fr@SDACLIN.FR. ATTENTION la case est significative. Le suffixe avec le arobase représente le Realm Kerberos dans lequel le SPN est déclaré.

Création du lien entre l’utilisateur AD et le SPN que weblogic demandera.

c:\setspn.exe -A HTTP/serverweblo.sdaclin.fr weblogicsrv

Génération d’un keytab avec ktab.exe [l’outil ktab.exe est disponible dans le répertoire bin d’une JRE java 1.4.2.]

C:\program files\j2re1.4.2_16\bin\>ktab -k c:\weblogicsrv.keytab -a weblogicsrv@SDACLIN.FR

Saisir le mot de passe weblogicsrv.

ATTENTION ktab n’étant pas un outil natif windows, il faut spécifier un fichier de conf kerberos dans le répertoire c:\winnt pour que ktab connaisse l’environnement kerberos sur lequel il va se baser pour générer le fichier keytab. –> voir la section ci-dessous : Configurer le fichier krb5.ini pour ce faire.

Le fichier keytab ainsi produit se trouve dans c:\ (ATTENTION il faut vérifier que vous ayez bien le droit d’écrire dans ce répertoire au préalable).

N.B. Il est possible de s’affranchir de l’utilisation de setspn et de ktab pour n’utiliser que l’outil ktpass qui va en une seule commande créer le spn et générer le fichier keytab résultat, mais je ne détaillerai pas cette utilisation dans cette documentation.

Etape 3 – Configuration du server weblogic (sur serverweblo)

Copier le fichier weblogicsrv.keytab à la racine de votre domaine weblogic

Le fichier weblogicsrv.keytab produit à l’étape 2 doit être copié sur le serveur serverweblo dans le domaine weblogic qui en fera usage.

Le fichier est donc copié par exemple à l’emplacement : c:\bea\user_projects\domain\mykerberosdomain\weblogicsrv.keytab

Configurer le fichier krb5.ini

Création du fichier de configuration c:/winnt/krb5.ini

[libdefaults]
default_realm = SDACLIN.FR
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
ticket_lifetime = 600

[realms]
SDACLIN.FR = {
kdc = 192.168.1.2:88
admin_server = serverad
default_domain = SDACLIN.FR
}

[domain_realm]
.sdaclin.fr = SDACLIN.FR

[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true

N.B. : Sur la machine weblogic Win XP SP2, le dossier winnt n’existant pas il a été créé en plus du dossier “windows” existant.
N.B. : Ce fichier est à créer dans /etc/krb5/krb5.conf sur un serveur Unix (ce path peut varier selon la distrib, sur RHEL il s’agit de /etc/krb5.conf).

Configurer le serveur weblogic

Créer le fichier krb5login.conf à la racine de votre domaine weblo (exemple : c:\bea\user_projects\domain\mykerberosdomain\krb5Login.conf)

com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
principal=”weblogicsrv@SDACLIN.FR” useKeyTab=true
keyTab=weblogicsrv.keytab storeKey=true debug=true;
};

com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule Required
principal=” weblogicsrv@SDACLIN.FR” useKeyTab=true
keyTab=weblogicsrv.keytab storeKey=true debug=true;
};

Modifier la commande de lancement du server startWeblogic.cmd qui se trouve à la racine de votre demaine en y ajoutant les paramètres suivantes :

-Djava.security.auth.login.config=krb5Login.conf
-Djavax.security.auth.useSubjectCredsOnly=false
-Dweblogic.security.enableNegotiate=true

Configurer le REALM weblogic

Lancer le serveur et modifier dans la console weblogic les paramètres du REALM comme suit pour configurer l’identity asserter :

1. Ouvrir la partie Sécurité –> Realms.
2. Choisir le realm courant.
3. Ouvrir le noeud de l’arbre Providers –> Authentication Providers.
4. Sur l’onglet “Authenticators”  cliquer sur “Configure a new Single Pass Identity Asserter”.
5. Donner un nom et spécifier le option « Authorization » comme Active Type Chosen et laisser cocher l’option Base 64.
6. Cliquer sur appliquer pour activer les changements.

Etape 4 – Créer une Application weblogic de test

Nos serveurs serverweblo et serverad étant en phase l’un l’autre pour le SSO, il ne nous reste plus qu’à mettre en place une application de test.

Le fichier web.xml

Dans celui-ci vous devez ajouter une partie security-contraint qui décrit via un url-pattern les éléments dont l’accès sera restreint ainsi que le type de protection CLIENT-CERT qui fait référence au certificat client produit pas le SSO.

<security-constraint>
<display-name>Security Constraint for SSO </display-name>
<web-resource-collection>
<web-resource-name>Kerberos</web-resource-name>
<description>Group of Users</description>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>SSOrole</role-name>
</auth-constraint>
</security-constraint>

<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
<security-role>
<description>Role description</description>
<role-name>SSOrole</role-name>
</security-role>

Le fichier weblogic.xml

Dans ce fichier on va faire le mapping entre un rôle de sécurité et un rôle du realm weblogic ou un principal (au sens nom d’utilisateur weblogic) ou encore un group (toujours au sens group d’utilisateur weblogic).

Dans ce cas on map explicitement le rôle avec l’utilisateur weblogic nommé “sdaclin”. Cet utilisateur n’existe évidemment pas par défaut mais il est possible de le créer et le renseigner via la console en tant qu’utilisateur définit dans l’annuaire LDAP intégré à weblogic.

<security-role-assignment>
<role-name>SSOrole</role-name>
<principal-name>sdaclin</principal-name>
</security-role-assignment>

Ce deuxième exemple plus proche d’une réalité professionnelle fait correspondre le rôle avec le rôle du même nom dans le REALM en utilisant la balise externally-defined. Il faudra donc qu’un rôle SSOrole soit définit dans la console pour votre REALM.

<security-role-assignment>
<role-name>SSOrole</role-name>
<externally-defined>
</security-role-assignment>

Une JSP de test doit ensuite être créée qui doit comporter le tag suivant qui affichera le nom de l’utilisateur connecté :

<%=request.getRemoteUser()%>

Pour ma part, j’ai utilisé une servlet qui faisait appel au principal (voir la documentation de JAAS) et dont le code est le suivant :

String intranauteName = request.getUserPrincipal().getName();

Le support de BEA propose une application d’exemple sous forme d’un WAR à l’adresse suivante :

https://support.bea.com/application_content/product_portlets/support_patterns/wls/ssotestwebapp.zip

Troubleshooting

Si malgré toutes ces explications, vous rencontrez toujours des problèmes, voici quelques pistes pour débuguer tout ça.

Vérification de l’unité de temps des acteurs du SSO

Le protocole kerberos tient compte de l’intégrité temporelle de chacun des acteurs afin de s’assurer que l’un des acteurs n’a pas pris le temps de craquer par brute force un ticket avant de le transmettre. Il est impératif de vérifier que tous les OS ont bien la même heure.

Activation du mode debug dans le server weblogic pour le SSO

Ajouter dans la commande de démarrage du serveur les options suivantes afin de voir apparaître les traces de débug dans la console au fur et à mesure :

-DDebugSecurityAdjudicator=”true”
-Dweblogic.debug.DebugSecurityAtn=”true”
-Dsun.security.krb5.debug=true
-Dweblogic.StdoutDebugEnabled=true

Vérification de la bonne création du lien entre l’utilisateur weblogicsrv et le SPN

Sur le server serverad effectuer la commande suivante :

c:\setspn -l weblogicsrv

La résultat devrait ressembler à ça :

Registered ServicePrincipalNames for CN=weblogicsrv,CN=Users,DC=sdaclin,DC=fr :

HTTP/serverweblo.sdaclin.fr

Vérification du bon fonctionnement du fichier .keytab

Pour vérifier le bon fonctionnement du fichier keytab, vous pouvez sur le serveur serverweblo utiliser l’outil kinit.exe (présent dans une JVM java) en lançant (il faut bien entendu au préalable copier le temp du test le fichier keytab dans le répertoire bin de la JVM) :

c:\bea\jdk142_11>kinit.exe -k -t weblogicsrv.keytab weblogicsrv@SDACLIN.FR

Le résultat suivant devrait apparaître :

New ticket is stored in cache in file : c:\Documents and[...]

Si tel n’est pas le cas, votre fichier keytab ne fonctionne pas.

Vérification de la configuration du client IE

Par défaut si personne n’a modifié les options de sécurité de votre client IE, il devrait autoriser l’envoi de ticket kerberos à tous les membres de son domaine. De ce fait le client IE étant dans le même domaine que le serveur serverweblo, tout fonctionnera nativement.

Cependant, une check list est dispo afin de s’assurer de la bonne configuration d’IE à l’adresse suivante :

http://edocs.bea.com/wls/docs81/secmanage/sso.html#1101398

Vérification des tickets kerberos stockés sur les différents acteurs du SSO

Chaque ticket kerberos peut être mis en cache plus ou moins longtemps sur les différents intervenants du SSO, il est donc recommandé en cas de problèmes de télécharger l’application kerbtray.exe qui permet de visualiser les tickets en cache mais également de les purger.

Cet outil est particulièrement util pour vérifier l’encodage des tickets en cache, en effet java n’utilise pas le cryptage natif microsoft RC4-HMAC, du coup il faut s’assurer en cas de problème que les tickets fournis par le KDC sont bien dans un format compatible notamment des-cbc-crc.

Autre point primodial : les tickets sont mis en cache ce qui signifie que si vous faites plusieurs tests il faut purger les caches sans quoi les tickets ne seraient pas redemandés et tout effort serait infructueux.

Section troubleshooting de sun

Cette page présente les pistes de débuguage Kerberos proposées par sun.

http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/tutorials/Troubleshooting.html

Vérification des trames réseau durant le SSO

Si malgré tout ça vous n’arrivez toujours pas à obtenir un SSO fonctionnel il ne vous reste plus qu’à lancer wireshark sur le poste IE et le server weblo et voir comment s’enchaînent les trames http et les requêtes sur le KDC.

Je vous recommande d’utiliser le capture filter suivant :

host ipDeLaMachine and (port 7001 or port 88)

Ce filtre vous permettra de voir l’échange HTTP (car weblo tourne sur le port 7001) et l’échange kerberos (car 88 c’est le port par défaut de Kerberos).

Références

Documentation officielle de la mise en place du SSO pour weblogic 8.1 :

http://edocs.bea.com/wls/docs81/secmanage/sso.html

Adresse de la web-app de test fournie par le support bea pour tester une application dont l’accès est protégé par certificat

https://support.bea.com/application_content/product_portlets/support_patterns/wls/ssotestwebapp.zip