IBM Security Verify Access Intégration
Verify Access SSO pour Apache Tomcat
IBM Security Verify Access peut être utilisé pour intégrer des registres d'utilisateurs sur site (par exemple LDAP, Active Directory) avec des applications fonctionnant sur Apache Tomcat. Le composant proxy inverse web est utilisé pour fournir et faire appliquer l'accès aux serveurs en aval jonctionnés par WebSEAL. Les informations d'identité fournies par Verify Access sont ensuite consommées par la valve JWT qui transmet l'identité aux applications web java. Des politiques d'accès personnalisées ou complexes peuvent être implémentées en utilisant le composant Advanced Access Control de Verify Access.
Connaissances supposées
Ce guide d'intégration suppose que vous êtes familier avec un certain nombre d'options de configuration d'IBM Security Verify Access. Au minimum, vous devriez être capable de :
- Créer des instances et jonctions WebSEAL
- Modifier le fichier de configuration WebSEAL
- Gérer la base de données SSL du serveur d'exécution
Prérequis
Ce guide suppose que vous avez Verify Access (matériel, machine virtuelle ou conteneurs) déployé et le serveur d'exécution et le registre d'utilisateurs configurés. Une configuration supplémentaire peut être requise si un registre d'utilisateurs fédéré (par exemple Active Directory) ou une identité fédérée (par exemple OIDC ou SAML) sont utilisés.
Vous devriez également avoir un serveur Tomcat déployé et configuré pour utiliser une valve JWT. Les instructions pour configurer Tomcat sont détaillées dans ce guide. L'identité est fournie via un JSON Web Token (JWT) construit à partir des attributs utilisateur disponibles. Ce guide suppose que vous êtes familier avec l'ICP associée nécessaire pour vérifier et (si requis) déchiffrer les JWT.
Configurer la vérification SSL
Dans la mesure du possible, il est recommandé de sécuriser la jonction WebSEAL vers le serveur Tomcat en aval en utilisant SSL. Par défaut, les instances WebSEAL utilisent la base de données de certificats SSL pdsrv. Pour activer la communication SSL, un certificat qui fait partie de la chaîne de confiance X509 de la poignée de main SSL tomcat doit être importé dans la base de données de certificats SSL utilisée par votre instance WebSEAL.
Pour activer la vérification mutuelle, un certificat qui fait partie de la chaîne de confiance X509 de la poignée de main WebSEAL doit être importé dans le magasin de clés SSL Tomcat.
Configuration du proxy inverse WebSEAL
Une instance WebSEAL est utilisée pour fournir et faire appliquer les exigences d'authentification. Au minimum, vous devrez créer/modifier une instance WebSEAL avec une jonction vers le serveur tomcat cible et ajouter la strophe de configuration JWT configurée pour correspondre aux revendications configurées pour la valve JWT.
Créer la jonction WebSEAL vers Tomcat
Créez une jonction mutuelle vers le serveur Tomcat. Ce guide utilise une jonction standard, cependant une jonction transparente peut être utilisée si le serveur en aval doit être capable de rediriger en utilisant des chemins relatifs. La jonction devrait être configurée pour utiliser des connexions SSL sans autre configuration supplémentaire requise.
Ceci peut également être fait en utilisant l'outil CLI pdadmin :
[user@workstation ~]$ ssh [email protected]
Warning: Permanently added '192.168.42.101' (ED25519) to the list of known hosts.
([email protected]) Password:
Welcome to the IBM Security Verify Access appliance
Enter "help" for a list of available commands
my.isva.appliance> isam admin
pdadmin> server task <instance_name>-webseald-<host_name_or_address> create –t mutual -h target.integration.server -p 9080 -P 9443 /tomcat-sso-demo
Created junction at /tomcat-sso-demo
Configurer WebSEAL pour fournir un JWT
Pour configurer WebSEAL pour fournir un JWT, une strophe [jwt:<nom de jonction>] est ajoutée au fichier de configuration WebSEAL. Cette strophe contient le mappage d'attributs à utiliser ainsi que toute configuration cryptographique requise. L'intégration de démonstration utilise le certificat auto-signé créé dans le magasin de clés pdsrv (magasin de clés par défaut WebSEAL) pour signer les JWT. Dans un environnement de production, ceci devrait être remplacé par une ICP appropriée. L'en-tête HTTP utilisé doit être de la forme Authorization: Bearer %TOKEN% car la fonctionnalité tomcat ne permet pas que ceci soit changé.
Un extrait de fichier de configuration WebSEAL d'exemple est fourni qui démontre la configuration requise :
[jwt:/tomcatsso]
key-label = WebSEAL-Test-Only
claim = attr::AZN_CRED_PRINCIPAL_NAME::sub
claim = text::webseal.ibm.com::iss
claim = text::demo.integration.server::aud
claim = attr::AZN_*
hdr-name = Authorization
hdr-format = Bearer %TOKEN%
lifetime = 0
renewal-window = 15
Optionnel : Configurer un contrôle d'accès supplémentaire des ressources web
Toutes listes de contrôle d'accès (ACL) et politiques d'objets protégés (POP) supplémentaires requises pour la ressource jonctionnée devraient également être créées ici. Les ACL et POP sont utilisées pour définir la logique métier supplémentaire requise pour faire appliquer des exigences de sécurité supplémentaires pour accéder aux ressources web. L'authentification par étapes prête à l'emploi, fournie par le module Advanced Access Control, est un exemple simple à utiliser de l'authentification supplémentaire qui peut être implémentée en utilisant IBM Security Verify Access.
Updated about 1 month ago