Alternatives OpenSSO/OpenAM
Attention! Je suis un peu en voyage de pêche ici et je ne suis même pas sûr que les questions que je pose soient tout à fait logiques. S'il vous plaît soyez gentil avec vos réponses! :)
J'ai récemment repris un projet actuellement basé sur Java + Linux + Tomcat + MySQL. À l’heure actuelle, le système n’est fondamentalement qu’un site Web avec quelques tâches cron dans l’arrière-plan pour transférer des données, etc. En travaillant avec le chef de produit pour développer un arriéré hiérarchisé, il est clair besoin de commencer à développer une architecture orientée services (SOA <- buzz Word warning!), et je vais me retrouver avec un mélange de serveurs Web et de serveurs d’applications. Remarque: j’envisage fortement de passer à Glassfish v3.
Actuellement, les authentifications et les autorisations sont gérées dans le code Java, les informations utilisateur étant stockées dans la base de données MySQL. Au minimum, il me semble que je devrai le scinder en un service d'authentification distinct (sinon, nous aurons un tas de codes dupliqués partout pour gérer l'authentification et les autorisations de l'utilisateur).
J'ai étudié des solutions d'authentification unique (SSO) type et effectué des recherches. D'après ce que je peux comprendre, OpenSSO a été officiellement abandonné par Oracle, mais repris par ForgeRock et s'appelle maintenant OpenAM. Cela semble être très proche de ce que je veux, mais comme j'ai déjà un système basé sur MySQL, je préférerais avoir quelque chose qui le supporte (ou un autre type de SGBDR). J'ai trouvé ceci sur Stack Overflow et cela semble indiquer qu'il s'agit essentiellement de LDAP ou de rien.
Mes questions sont:
Quelles sont les autres options disponibles pour OpenSSO/OpenAM? LDAP est la voie à suivre? Remarque: faire une recherche google “OpenAM vs” ne rapporte pas grand chose. Les gens ont-ils tendance à «rouler seuls»?
Toutes les pensées/suggestions/liens sur ce sujet qui aideront à m'éduquer seront grandement appréciés. Merci d'avance pour votre patience et votre aide.
Intégrez-vous des applications existantes ou souhaitez-vous simplement prendre en charge vos propres applications?
Recherchez-vous une authentification unique unique ou simplement des informations d'identification partagées? SSO se connecte à une seule application et transmet ses informations d'identification à une autre application (comme une connexion à Gmail et une connexion automatique à Blogger). Informations d'identification partagées: vous pouvez utiliser le même nom d'utilisateur et le même mot de passe pour toutes les applications, mais les informations d'identification elles-mêmes ne sont pas automatiquement propagées.
LDAP est un système commun utilisé pour gérer un identifiant partagé. De nombreux systèmes vous permettent de pointer leur magasin d'authentification sur un serveur LDAP existant.
Par exemple, si plusieurs applications sont déployées dans un conteneur Java EE, ainsi qu'un serveur de messagerie et un client de messagerie Web, toutes ces applications peuvent être dirigées vers le même serveur LDAP et vos utilisateurs disposeront d'un seul identifiant de connexion. et mot de passe pour tous les systèmes différents, tous écrits dans des langues différentes, tous déployés sur des machines différentes. LDAP est un cas d’usage simple à utiliser, et pratiquement tous les systèmes peuvent le gérer immédiatement. Glassfish et Tomcat peuvent tous deux facilement valider sur un serveur LDAP. Apache (serveur Web), Postgres (base de données), Postfix (courrier électronique), etc.
Donc, si vous voulez simplement un identifiant partagé, vous l’obtenez "gratuitement", dès maintenant, en installant un serveur LDAP. LDAP est un peu une bête différente de quelque chose comme un SGBD, mais une fois que vous l'étudiez un peu et "l'obtenez", c'est vraiment très agréable. OpenLDAP est un serveur LDAP populaire, mais je suis un partisan d'ApacheDS.
Pour configurer cela dans un conteneur Java EE, vous devez configurer un "royaume". GF et Tomcat ont tous deux des domaines LDAP prêts à l'emploi, j'imagine que le reste le fait. Mais le problème est que vous devez utiliser la sécurité Java EE pour tirer parti du royaume.
Vous voyez, le détail d'un royaume Java EE est qu'il s'agit d'un aspect du conteneur, pas de l'application. Tout comme un pool de connexions, une ressource conteneur exploitée par votre application. La plupart des gens veulent que la sécurité fasse partie de leur application, où ils sentent qu'ils ont plus de contrôle.
C’est très bien jusqu’à ce que vous obteniez un ensemble d’applications différentes et que tout le monde soit configuré différemment et dispose de listes d’utilisateurs, de stratégies de mot de passe, etc., séparées.
LDAP peut résoudre beaucoup de problèmes, car vous les configurez tous pour utiliser le même magasin d'informations d'identification.
Le domaine remplit ce besoin sur un serveur Java EE. Votre application est configurée pour utiliser un royaume fourni par le conteneur. Si vous avez plusieurs applications et un seul domaine, elles peuvent toutes partager les informations d'identification au sein de ce domaine (quel que soit le type de domaine).
Les royaumes peuvent être n'importe quoi: basés sur les fichiers, sur la base de données, LDAP, etc. Les royaumes sont également en cluster si les clusters de conteneurs (ce qui peut être pratique).
Le côté obscur de la sécurité Java EE et la plupart des applications l’évitent, c’est que, puisque le royaume fait partie du conteneur, et non de l’application, il peut être un peu disgracieux à utiliser et peut-être ne pas offrir les fonctionnalités comme en termes de gestion des utilisateurs, stratégies de mot 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 facilement exploiter les informations d’identification dans votre code. Une personne se connecte au site Web. Cette information d'identification peut être utilisée dans l'application Web ou automatiquement renvoyée au niveau EJB (toujours un niveau EJB distant). Les informations sont toujours utiles.
Vous pouvez diriger vos applications Web vers un royaume, vos EJB, vos services Web. Ils exploitent tous les mêmes pièces.
Pour obtenir le meilleur des deux mondes, il faut exploiter des mécanismes spécifiques aux conteneurs pour accéder à la sécurité des conteneurs. C'est l'autre côté sombre de la sécurité Java EE.
Des éléments tels que Realms et l'accès direct à la sécurité des conteneurs ne sont pas portables entre les conteneurs. GF a un comportement différent de celui de Tomcat et de WebLogic. Tout est très proche, mais les détails diffèrent pour que votre code ne soit pas transféré de manière transparente.
Le bon côté des applications est celui des applications internes: la plupart des gens utilisent simplement le conteneur dont ils disposent, mettent une abstraction raisonnable autour du code dépendant du conteneur et appellent la journée en précisant que, si, ils devront le porter si et quand ils passent à un autre récipient. Mais en pratique. un peu comme une base de données, une fois la plate-forme de conteneur choisie, les gens ont tendance à se blottir contre eux et à s'y tenir.
Enfin, Servlet 3.0 (dans GF3 et Tomcat 7) normalise un plus grand nombre de problèmes de connexion par programme afin de les rendre plus portables entre les conteneurs, mais les concepts sous-jacents sont les mêmes.
Maintenant, SSO.SSO est une bête différente. Mais, hors du portail, GF et Tomcat prennent en charge l'authentification unique pour les applications Web. Cela vous permet de vous connecter à une application Web et d’être en mesure d’accéder facilement aux autres sans devoir vous connecter. Toutefois, la connexion unique est un peu limitée car elle repose davantage sur la sécurité du conteneur et son cycle de vie que sur une stratégie plus flexible sous le contrôle de l’application. Remarquez, pas seulement sur Realms (c'est une donnée), mais sur le login de formulaire réel basé sur un conteneur, plutôt que sur un login de programmation personnalisé. Le login FORM n'est pas spectaculaire, mais il est fonctionnel et fonctionne. Implémentez un royaume, déployez vos applications sur une seule instance de Tomcat ou de GF (ou d'un cluster dans GF 3.1), et obtenez SSO gratuitement, donc si c'est important, c'est plutôt sympa. Sa convivialité convient parfaitement aux applications de back-office, mais peut-être pas à l'Internet public.
Si vous souhaitez une solution SSO plus sophistiquée, vous devez examiner les implémentations personnalisées. OpenSSO fait partie de ceux-ci et repose sur SAML et le profil Web SAML. Cependant, il y en a d'autres. Il y a aussi CAS, Atlassian Cloud, Kerberos et OAuth. Ceux-ci utilisent tous des protocoles différents de SAML. Si vous souhaitez vous en tenir à SAML, vous pouvez également consulter Shibboleth, ou même SimpleSAML (SimpleSAML est un serveur PHP qui joue notamment le rôle de fournisseur d'identité SAML, mais vous avez toujours besoin d'un fournisseur de service dans vos applications). .
Quel que soit le protocole choisi, le processus est fondamentalement identique (détaillé ici - Connexion à plusieurs domaines - Comment connecter automatiquement un utilisateur lors du transfert d’un domaine à un autre ).
Mais le diable est dans les détails. Et, mon garçon, y a-t-il des démons?.
Tous ces systèmes sont compliqués. SSO est compliqué. Par exemple, maintenant que vous avez l'authentification unique, qu'en est-il de la déconnexion unique? Qu'en est-il de Single Time Out? Qu'en est-il des modifications des informations d'identification lorsque 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ée similaire pour les services Web.).
SAML vous présente un grand nombre de nouveaux vocabulaires et de nombreuses configurations. Ce n'est pas facile à comprendre, car la documentation n'est pas excellente et repose beaucoup sur des documents de normes qui traitent d'un niveau plus élevé d'éléments génériques, et non pas spécifiquement de votre application.
Si vous n'avez pas vraiment besoin de l'authentification unique, vous vous contenterez probablement de quelque chose comme un magasin LDAP central.
Cela dit, nos applications prennent en charge à la fois les bases de données DB et LDAP. Ils utilisent la sécurité Glassfish et Java EE. Nous contrôlons complètement l'expérience utilisateur. Nous prenons également en charge l'authentification unique via SAML (nous avons écrit nos propres fournisseurs d'identité et de services) et nous partageons les informations d'identification via LDAP et l'authentification unique via Java et d'autres applications, à l'aide de notre code et du code tiers. Le bon côté est que tout est basé sur les normes. Le côté obscur est que les normes sont communiquées en anglais, l’anglais étant sujet à interprétation.
Je dis cela simplement pour dire que cela peut être fait. J'ai également écrit ad hoc, au dos des implémentations SSO de Napkin, le même domaine et le même domaine (le même domaine est simple avec un cookie partagé) à l'aide de filtres de servlet simples. Stratégies de mot de passe, récupération de mot de passe, minuteries persistantes, délai d'expiration de plusieurs fenêtres et gestion de session (c'est un hoot), rôles, privilèges, etc., etc.
De plus, je m'en voudrais de ne pas mentionner Spring and Spring Security, qui propose tout cela en plus du printemps. Je ne l'ai pas utilisée (je ne suis pas une personne de Spring), mais ces personnes savent ce qu'elles font et il est donc intéressant de regarder.
Also, I would be remiss to not mention Spring and Spring Security which offers all of this on top of Spring. I have not used it (I'm not a Spring person), but those folks do know what they are doing so it's worth looking at.
Veuillez noter que " Y a-t-il un moyen de faire en sorte qu'OpenSSO/OpenAM parle à Database pour son authentification et son autorisation? " est mal formulé. Les détails de la question et les réponses ne traitent que de l'aspect autorisation. OpenAM fonctionne très bien avec une base de données MySQL d’utilisateurs et de mots de passe (authentication), et peut utiliser son serveur LDAP caché/incorporé pour stocker des stratégies et d’autres paramètres.
Il semble que vous ayez encore besoin d’étoffer votre modèle de sécurité, mais vous constaterez probablement que vous n’avez absolument pas besoin d’OpenAM, et que vous pouvez simplement utiliser la sécurité fournie par le conteneur/cadre.
J'ai réussi à créer un référentiel d'utilisateurs personnalisé pour OpenAm. Étant donné que cette question n’est pas active depuis un moment et qu’il serait trop long de décrire en détail la procédure à suivre, je vais donner quelques conseils. Si vous avez besoin d'aide sur des détails spécifiques, n'hésitez pas à me demander.
- Votre point d'entrée de base doit s'étendre à com.Sun.identity.idm.IdRepo.
- Vous devez enregistrer votre référentiel personnalisé à l'aide de ssoadm.jsp? Cmd = add-sub-schema.
À partir de ce moment, votre type de référentiel sera répertorié parmi les autres types lorsque vous créez un magasin de données pour un domaine.
Bonne chance !
Vous pouvez utiliser OpenAm avec des RDBM. J'utilise un magasin d'utilisateurs basé sur JBDC dans OpenAm
OpenAM a deux magasins distincts, un magasin d'utilisateurs, où sont stockés les utilisateurs et toutes les propriétés associées, et un magasin de configurations, qui contient la configuration. Il existe une base de données User Store, disponible dans OpenAM, mais je ne l'ai jamais essayée. La question SO à laquelle vous faisiez référence se référait principalement au magasin de configuration qui, bien que LDAP uniquement, soit intégré à OpenAM (ne nécessite donc pas de gestion directe).
Personnellement, je suis un fan de Tomcat over Glassfish, car il s’agit d’un conteneur Servlet rapide et léger, sans tous les effets indésirables associés à un conteneur J2EE complet.
OpenAM semble avoir la possibilité de brancher votre propre module d'authentification .
Vraisemblablement, vous pouvez effectuer vos appels de base de données depuis votre extension du module AMLoginModule.
Cette liste pourrait constituer un bon point de départ:
http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
avec JOSSO et Shibboleth jaillissant à l’esprit.