Single sign-on ActiveDirectory et Java EE

Question

Scénario:

1. Nous vendons Java EE (JBoss + SpringSecurity) logiciel aux grandes entreprises qui utilisent la plupart du temps ActiveDirectory
2. Notre logiciel Java EE (JBoss) peut être raccordé Pour ActiveDirectory, cependant, il faut ajouter des rôles dans ActiveDirectory, cn = esp_administrator, cn = rôles, o = société, o = com
3. Selon ce que je sais, JBoss aura besoin d'un compte pour "lier" à ActiveDirectory pour effectuer la recherche, par exemple cn = admin, cn = Utilisateurs, o = société, o = com
4. Utilisateurs encore n EED pour vous connecter à notre application Java EE manuellement (pas de connexion unique)
5. Say notre application Java EE http://javaee-webapp et un du portail de l'entreprise est à http://intranet-portal dire en utilisant Atlassian JIRA

Comment puis-je mettre en œuvre l'authentification unique avec cette configuration? Une chose vient à l'esprit est de lire les cookies de http://intranet-portal, mais cela ne fonctionne que si notre Java EE webapp est un sous-domaine de http://intranet-portal, à savoir http://intranet-portal/javaee-webapp

J'ai lu le QA suivant

Single Sign On for a Web App

Transparent user session over several sites (single sign-on + single sign-off)

Je ne pense pas que les clients veulent que nous installons Shibboleth IDProvider juste pour une authentification unique.

À part une option «Se souvenir de moi», quel autre choix ai-je?

Answer 1

Vous pourriez en effet utiliser Shibboleth (ou peut-être OpenSSO). Cela peut être assez complexe et devra être déployé pour tous les sites Web (Fournisseurs de services) qui seront sous la portée de cette SSO. Il est spécialement conçu pour l'authentification et l'autorisation SSO qui n'appartiennent pas nécessairement au même site. Si vos clients veulent un SSO dans un environnement pas trop couplé, ils auront besoin de ce type de technologie. (Notez que la partie la plus difficile de la mise en œuvre de Shibboleth n'est pas tant l'installation du logiciel SP ou IdP que la mise en place de politiques autour de la libération et de l'autorisation des attributs. Si les machines clientes à partir desquelles vos clients vont se connecter sont également sous leur contrôle (par exemple, s'il s'agit de tous les postes de travail Windows que l'entreprise peut configurer), vous pouvez consulter le SPNEGO. Cela peut être fait pour fonctionner à partir de clients Windows/Linux/OSX utilisant IE/Firefox (au moins), mais vous devez configurer les clients pour qu'ils pointent vers le serveur Active Directory (en tant que KDC Kerberos). Cela peut être déroutant si les utilisateurs doivent le faire sur leur propre machine. Alors que la solution SPNEGO peut être plus simple si vous pouvez contrôler la configuration des machines client, la solution Shibboleth/OpenSSO sera plus flexible à cet égard (et l'IdP de Shibboleth pourrait utiliser SPNEGO comme mécanisme d'authentification, si vous voulez tout).