Autorisation transparente pour une application sur Oracle Weblogic Server

Dans cet article, je vais vous expliquer comment nous sommes passés de l'autorisation NTLM à l'autorisation Kerberos pour les applications sur Oracle Weblogic Server, simplifiant ainsi la connexion des utilisateurs en supprimant la nécessité de saisir un mot de passe. Tous les utilisateurs, ainsi que le serveur d'applications, sont dans le même domaine; l'autorisation de domaine pour les applications du serveur Weblogic a également été précédemment configurée. Toutes les configurations ont été vérifiées sur WLS 12.1.2.

Tout d'abord, un peu de théorie, très brièvement pour une meilleure compréhension du processus d'interaction.

Qu'est-ce que l'authentification unique?

La connexion unique (SSO) est un mécanisme par lequel une action d'authentification d'un seul utilisateur permet à un utilisateur d'accéder à tous les ordinateurs et systèmes auxquels il est autorisé à accéder sans avoir à saisir plusieurs mots de passe. Les informations d'identification précédemment saisies seront réutilisées de manière transparente par divers composants.

Qu'est-ce que Kerberos?

Kerberos est un protocole d'authentification réseau qui a été développé pour la première fois par le Massachusetts Institute of Technology. Kerberos est une méthode sécurisée d'authentification d'une demande de service sur le réseau et est conçue pour fournir une authentification forte pour les applications client-serveur utilisant la cryptographie avec une clé secrète.

Qu'est-ce que SPNEGO?

SPNEGO est un moteur de négociation GSSAPI simple et sécurisé. Il s'agit d'une interface normalisée pour l'authentification (par exemple JNDI pour les recherches dans l'annuaire), l'implémentation par défaut de SPNEGO sur Windows est Kerberos (par exemple LDAP pour JNDI). La terminologie Microsoft utilise «Authentification Windows intégrée» comme synonyme de SPNEGO. Dans l'authentification intégrée Windows, les protocoles Kerberos ou NTLM peuvent être négociés.

Lorsqu'un serveur reçoit une demande d'Internet Explorer (IE 6.1 ou supérieur), il peut demander au navigateur d'utiliser le protocole SPNEGO pour l'authentification. Ce protocole effectue l'authentification Kerberos sur HTTP et permet à Internet Explorer de déléguer des pouvoirs délégués afin que l'application Web puisse se connecter aux services Kerberized ultérieurs au nom de l'utilisateur.

Lorsque le serveur HTTP souhaite exécuter SPNEGO, il renvoie une réponse «401 Unauthorized» à la demande HTTP avec le titre «WWW-Authorization: Negotiate». Internet Explorer contacte ensuite le Ticket Service (TGS) pour obtenir un ticket. Il choisit le nom spécial du participant au service pour demander un ticket, par exemple:

HTTP/webserver@<DOMAIN NAME> 

Le ticket retourné est ensuite enveloppé dans un jeton SPNEGO, qui est codé et renvoyé au serveur à l'aide d'une requête HTTP. Le jeton se déroule et le ticket s'authentifie.

Avantages de Kerberos

L'utilisation de Kerberos permet aux administrateurs de désactiver l'authentification NTLM dès que tous les clients du réseau peuvent authentifier Kerberos. Kerberos est plus flexible et efficace que NTLM et plus sécurisé.

Configurer l'authentification unique basée sur Kerberos dans un environnement de serveur d'applications Weblogic

Schéma d'interaction:

1. Lorsqu'un utilisateur enregistré (PC) demande une ressource à Oracle WebLogic Server (WLS), il envoie la requête HTTP GET d'origine.
2. Le serveur Oracle WebLogic Server (WLS) exécutant le code de jeton SPNEGO nécessite une authentification et émet une réponse 401 Access Denied, WWWAuthenticate: Negotiate.
3. Un client (navigateur sur PC) demande un ticket de session à TGS / KDC (AD).
4. TGS / KDC (AD) fournit au client le ticket Kerberos nécessaire (à condition que le client soit autorisé), enveloppé dans le jeton SPNEGO.
5. Le client renvoie la requête HTTP GET + Négociez le jeton SPNEGO dans l'en-tête d'autorisation: Négociez base64 (jeton).
6. La vérification de l'authentification Web SPNEGO sur le serveur Weblogic affiche un en-tête HTTP avec le jeton SPNEGO. SPNEGO vérifie le jeton SPNEGO et obtient les informations utilisateur.
7. Une fois que Weblogic a reçu les informations utilisateur, il valide l'utilisateur dans Microsoft Active Directory / KDC. Une fois le processus d'authentification terminé, Weblogic exécute le code Java correspondant (servlets, JSP, EJB, etc.) et vérifie l'autorisation.
8. Le code du gestionnaire de jeton Oracle WebLogic Server accepte et traite le jeton via l'API GSS, authentifie l'utilisateur et répond avec l'URL demandée.

Passons maintenant à la pratique

1. Nous effectuons les réglages côté serveur du domaine du contrôleur sur lequel les services TGS / KDC sont configurés.

• Créer un utilisateur dans Active Directory (le mot de passe ne doit pas expirer)
• Définissez le SPN approprié pour le nom du serveur WLS

Effectuer la vérification établie par SPN

 setspn –l HTTP_weblogic 

devrait renvoyer deux enregistrements
Générer un fichier Keytab

 ktpass -princ HTTP_weblogic@mycompany.com -pass PASSWORD -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -kvno 0 -out c:\krb5.keytab 

Copiez ce fichier sur le serveur WLS

2. Configuration du serveur WLS

• Vous devez créer le fichier krb5.ini dans le dossier% windir%: C: \ Windows. Ce fichier contient des paramètres de configuration pour les clients, par exemple, où se trouve le KDC. Le fichier ressemblera à ceci:

 [libdefaults] default_realm = <DOMAIN NAME> ticket_lifetime = 600 [realms] <DOMAIN NAME> = { kdc = <HOSTNAME OF AD/KDC> admin_server = <HOSTNAME OF AD/KDC> default_domain = <DOMAIN NAME> } [domain_realm] . <DOMAIN NAME>= <DOMAIN NAME> [appdefaults] autologin = true forward = true forwardable = true encrypt = true 

• Créez le fichier de configuration krb5Login.conf:

 com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; }; 

Veuillez noter que le nom de domaine doit être en majuscule . Pour les versions antérieures, utilisez com.sun.security.jgss.initiate dans la configuration précédente au lieu de com.sun.security.jgss.krb5.initiate.

• Les fichiers krb5Login.conf et krb5.keytab doivent être situés à la racine du répertoire de domaine du serveur WLS.

• Modification du fichier setDomainEnv

Trouvez l'ensemble de lignes JAVA_OPTIONS =% JAVA_OPTIONS% et ajoutez à la fin

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

• Dans ce cas, nous n'envisageons pas de configurer l'autorisation WLS dans AD, nous pensons que cela fonctionne, si vous avez besoin de peindre cet élément, écrivez dans les commentaires.
• Configuration de SPNEGO dans WLS
  Pour ce faire, accédez à la console d'administration de WebLogic Server
  Accédez à la section Security Realms> myrealm> Providers et cliquez sur le bouton Ajouter
  Sélectionnez le type de «WebLogic Negotiate Identity Assertion provider»
  Vérifiez que les deux paramètres sont sélectionnés.
  
  
  
  Nous appuyons sur le bouton Réorganiser et contrôlons les flèches pour définir la séquence des types d'autorisation. En premier lieu doit être installé WebLogic Negotiate Identity Assertion Provider en deuxième lieu Fournisseur qui effectue l'authentification LDAP (autorisation de domaine)
  
  

• Redémarrez le serveur

• Ensuite, vous devez indiquer à l'application la méthode d'autorisation CLIENT-CERT, ces modifications sont appliquées dans le fichier web.xml de l'application

 <security-constraint> <display-name>Security Constraint for SSO </display-name> <web-resource-collection> <web-resource-name>My webapp</web-resource-name> <description>Group of Users</description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <description>Role description</description> <role-name>valid-users</role-name> </security-role> 

Le rôle doit être préinstallé dans le système. Dans notre cas, le rôle intégré pour ADF (utilisateurs valides) est utilisé et, en fonction des groupes de domaines, des autorisations sont accordées.

• Déboguer

Pour identifier les problèmes d'autorisation, vous devez activer le débogage. Pour ce faire, accédez à la section.

Environnement -> Serveurs, sélectionnez notre serveur -> Débogage -> weblogic (développer) -> Sécurité -> atn, cochez la case et activez-le.



Pour activer et désactiver le débogage, un redémarrage n'est pas nécessaire.

• Nous redémarrons le serveur pour appliquer les modifications de configuration.
• Déployer l'application avec une méthode d'autorisation modifiée (nouveau web.xml)
• Pour désactiver ce type d'autorisation pour la console d'administration, apportez les modifications suivantes% Ora_Home% \ wlserver \ server \ lib \ consoleapp \ webapp \ WEB-INF \ web.xml.
  
  Changer la ligne
  
  

    <auth-method>CLIENT-CERT,FORM</auth-method>  <auth-method>FORM</auth-method> 

Connectez-vous à la machine du domaine, cliquez sur le lien de l'application et connectez-vous sans entrer de mot de passe. Il convient de noter que le bouton Quitter de l'application ne fonctionnera pas dans cette configuration.