Alternatives OpenSSO / OpenAM

intégrez-vous des applications existantes, ou voulez-vous simplement prendre en charge vos propres applications?

êtes-vous à la recherche de justificatifs d'identité réels ou simplement partagés? SSO se connecte à une seule application, et avoir ce justificatif se propage à une autre application (comme se connecter à Gmail et être automatiquement connecté à Blogger). Le justificatif d'identité partagé est vous pouvez utiliser le même nom de connexion et mot de passe à travers les applications, mais le justificatif d'identité lui-même n'est pas automatiquement propagées.

LDAP est un système commun utilisé pour gérer un justificatif d'identité partagé. De nombreux systèmes vous permettent de pointer leur mémoire d'authentification vers un serveur LDAP existant.

par exemple, si vous aviez plusieurs applications déployées dans un conteneur Java EE, et aussi, disons, un serveur de courrier électronique et un client de courrier électronique basé sur le web, toutes ces applications diverses pourraient être pointées vers le même serveur LDAP et vos utilisateurs auraient un seul login et mot de passe pour tous les les différents systèmes, tous écrits en différentes langues, tous déployés sur des machines différentes. Il s'agit d'un cas d'utilisation de pain et de beurre de LDAP, et à peu près tous les systèmes peuvent gérer cela hors de la boîte. Glassfish et Tomcat peuvent facilement être validés par un serveur LDAP. Ainsi Apache (serveur Web), Postgres (base de données), Postfix (courriel), etc. etc.

donc si vous voulez simplement un justificatif d'identité partagé, vous obtenez ce" gratuitement", dès maintenant, en installant un serveur LDAP. LDAP est un peu d'une autre bête que quelque chose comme un SGBD, mais une fois que vous l'étudiez un peu et "get it", il est vraiment très agréable. OpenLDAP est un serveur LDAP populaire, mais J'ai un faible pour ApacheDS.

la façon de configurer cela dans un conteneur Java EE est de configurer un"domaine". GF et Tomcat ont tous les deux des Royaumes LDAP hors de la boîte, j'imagine que les autres le font. Mais le problème est que vous devez utiliser la sécurité Java EE pour tirer parti du Royaume.

voir, le détail avec un Java EE Le domaine est que c'est un aspect du conteneur, pas l'application. Tout comme un pool de connexion est une ressource de conteneur que votre application exploite. La plupart des gens veulent que la sécurité fasse partie de leur application, où ils sentent qu'ils ont plus de contrôle sur elle.

tout cela est bien et bon jusqu'à ce que vous commencez à obtenir un tas d'applications différentes et tout le monde est configuré différemment et a des listes d'utilisateurs distinctes, et des politiques de mot de passe, etc. etc.

LDAP peut corriger beaucoup de cela, puisque vous les configurez tous pour utiliser le même magasin de justificatifs d'identité.

le domaine comble ce besoin sur un serveur Java EE. Votre application est configuré pour utiliser un Domaine fourni par le conteneur. Si vous avez plusieurs applications, et un seul domaine, alors ils tous obtiennent de partager les justificatifs d'identité dans ce domaine (quel que soit le type de domaine).

les Royaumes peuvent être n'importe quoi: basé sur des fichiers, db, LDAP, etc. Domaines aussi cluster si le conteneur clusters (qui peut être pratique).

le côté obscur de la sécurité Java EE, et pourquoi la plupart des applications l'évitent, est que, puisque, encore une fois, le domaine fait partie du conteneur, et non l'application, il peut être un peu ungainly à utiliser, et peut-être pas offrir les fonctionnalités que vous aimez en termes de gestion des utilisateurs, les politiques de mots de passe, etc.

mais le bon côté de la sécurité Java EE est qu'une fois que vous êtes sous son parapluie, vous pouvez justificatifs d'identité partout dans votre code facilement. Une personne se connecte au site web, et ce justificatif peut être utilisé dans l'application web, ou automatiquement propagé de nouveau au niveau EJB (jamais un niveau EJB distant), et l'information est toujours pratique.

vous pouvez pointer vos applications web vers un domaine, vous EJBs, vos services web. Ils ont tous l'effet de levier les mêmes morceaux.

pour obtenir sorte du meilleur des deux mondes est de tirer parti des mécanismes spécifiques de conteneur à l'accès aux conteneurs de sécurité. C'est l'autre côté sombre de la sécurité Java EE.

les choses comme les royaumes, et l'accès direct à la sécurité des conteneurs ne sont pas portables à travers les conteneurs. GF le fait différemment de Tomcat et WebLogic. Tout est très proche, mais diffère dans les détails afin que votre code ne soit pas porté de façon transparente.

le bon côté est pour les applications maison, la plupart des gens simplement tirer parti du conteneur qu'ils ont, mettre une abstraction raisonnable autour du code dépendant du conteneur, et l'appeler le jour en notant que oui, ils devront porter ce si et quand ils se déplacent à un conteneur différent. Mais, dans la pratique. tout comme une base de données, une fois qu'une plate-forme de conteneur est choisi, les gens ont tendance à se blottir dans serré et coller avec elle.

enfin, Servlet 3.0 (dans GF3 et Tomcat 7) standardise davantage les problèmes de login programmatiques pour les rendre plus mobiles à travers les conteneurs, mais les concepts sous-jacents sont les mêmes.

maintenant, SSO.

SSO est une bête différente. Mais gf et Tomcat prennent en charge SSO pour les applications web. Cela vous permet de vous connecter à une application web et être en mesure d'accéder facilement à d'autres sans avoir à se connecter à eux. Mais le SSO est un peu limité car il s'appuie davantage sur la sécurité du conteneur et son cycle de vie, plutôt que sur une plus grande flexibilité sous le contrôle de l'application. L'esprit, et pas seulement sur les Royaumes (c'est donné), mais sur le réel forme basée sur le conteneur login, plutôt qu'un login programmatique personnalisé. FORMULAIRE de connexion n'est pas spectaculaire, mais il est fonctionnel et il fonctionne. Implémenter un domaine, déployer vos applications sur une seule instance de Tomcat ou GF (ou un cluster dans GF 3.1), et vous obtenez SSO gratuitement, donc si c'est important, c'est plutôt sympa. Il est utilisable est très bien pour les applications de back office, mais peut-être pas l'internet public.

si vous voulez une solution SSO plus sophistiquée, alors vous devez regarder sur mesure application. OpenSSO en fait partie, et s'appuie sur SAML et le profil web SAML. Cependant, il en existe d'autres. Il y a CAS, Atlassian Cloud, Kerberos, et OAuth aussi. Ils utilisent tous des protocoles différents de SAML. Si vous voulez rester avec SAML, vous pouvez aussi regarder Shibboleth, ou même SimpleSAML (SimpleSAML est un serveur PHP qui agit comme un fournisseur D'identité SAML, entre autres, mais vous avez encore besoin d'un fournisseur de services dans vos applications).

peu importe le protocole que vous choisissez, le processus est essentiellement le même (détaillé ici -- Cross Domain Login - comment se connecter à un utilisateur automatiquement lors d'un transfert d'un domaine à un autre ).

Mais le diable est dans les détails. Et, garçon, il y a des diables.

Tous ces systèmes sont complexes. Le SSO est compliqué. Par exemple, maintenant que vous N'avez Qu'une seule affiche, qu'en est-il de L'affichage unique? Qu'en Seule Fois? Ce sujet identification des changements, tandis que les utilisateurs sont connectés? Qu'en est-il D'un STS (Secure Token Service) pour vos Services Web? (STS offre un mécanisme d'authentification délégué similaire pour les services web.)

SAML vous présente beaucoup de nouveau vocabulaire, et beaucoup de configuration. Il n'est pas facile de le relever puisque la documentation n'est pas stellaire et repose beaucoup sur des documents de normes qui parlent à un niveau plus élevé de choses génériques, et pas à vous et à votre application en particulier.

si vous n'avez pas besoin vraiment besoin de SSO, alors vous serez probablement content avec quelque chose comme un magasin LDAP central et aller de là.

tout cela dit, à titre d'exemple, nos applications prennent en charge à la fois un backend DB et LDAP. Ils utilisent du poisson de verre, et la sécurité Java EE. Nous contrôlons entièrement l'expérience utilisateur. Nous soutenons également SSO via SAML( nous avons écrit notre propre identité et fournisseurs de services), et nous avons tous les deux des justificatifs d'identité partagés via LDAP et SSO à travers Java et d'autres applications, en utilisant notre code et le code tiers. Le bon côté, c'est que tout est basé sur des normes. Le côté obscur est que les normes sont communiquées en anglais, et l'anglais est sujet à interprétation.

je dis cela simplement pour dire que cela peut être fait. J'ai aussi écrit ad hoc, back of the napkin SSO implémentations, à la fois le même domaine et le domaine croisé (le même domaine est simple avec un cookie partagé) en utilisant des filtres Servlet simples. Politiques de mot de passe, récupération de mot de passe, garder vivante des minuteurs, des fenêtres multiples de délai d'attente et de gestion de session (c'est marrant), les rôles, les privilèges, etc. etc. Été là, fait cela.

aussi, je manquerais à mon devoir de ne pas mentionner la sécurité des ressorts et des ressorts qui offre tout cela en plus du ressort. Je ne l'ai pas utilisé (Je ne suis pas une personne de printemps), mais ces gens savent ce qu'ils font donc il est intéressant de regarder.