Autorisation LDAP vs SAML
Je suis en train d'étudier la possibilité de déplacer un système de suivi des actifs de LDAP vers SAML. Actuellement, notre logiciel utilise LDAP dans deux domaines principaux. Le premier est l'authentification. Pour pouvoir accéder au système aujourd'hui, vous devez vous authentifier avec LDAP et être membre d'un groupe LDAP spécifié. Cette partie est assez simple pour passer à SAML. Nous avons utilisé une bibliothèque pour gérer la majeure partie du sale boulot. Et sur l'IDP, nous pouvons ajouter une revendication pour autoriser l'utilisateur. Mais notre deuxième utilisation de LDAP me lance pour une boucle.
Aujourd'hui, chaque actif que nous maintenons peut être associé à un nom d'utilisateur. Par exemple, une imprimante particulière peut appartenir à "someuser". L’une des options que notre logiciel offre à l’administrateur est de visualiser/d’interagir avec les actifs en fonction des groupes d’utilisateurs LDAP. Par conséquent, en tant qu'administrateur, je souhaiterais peut-être mettre à jour toutes les imprimantes appartenant à des personnes appartenant à un département donné. Pour ce faire, l'administrateur crée une règle étendue au groupe LDAP 'departmentInQuestion'. Notre logiciel utiliserait ensuite un compte de service pour se connecter à LDAP, créerait une requête pour savoir quels utilisateurs de notre système se trouvaient dans 'departmentInQuestion', l'exécuterait et utiliserait les résultats pour déterminer les actifs devant obtenir la mise à jour.
Si loin de mes recherches, je n’ai pas pu trouver un flux de travail SAML analogue à celui-ci. Il semble que la seule opportunité que nous ayons pour évaluer le «someuser», c’est lorsqu’ils s’authentifient et que nous avons accès à leurs revendications. Mais dans notre flux de travail, "someuser" peut ne jamais s'authentifier auprès de nous. C'est presque comme si nous utilisions l'autorisation d'un utilisateur pour le compte du compte de service. Y a-t-il un flux de travail existant que j'ai négligé pendant mon exploration? Existe-t-il d'autres technologies prenant en charge l'autorisation de cette manière?
Merci pour toute contribution!
SAML est comme un passeport ou un visa. Il contient des informations (fiables) sur vous qui peuvent être utilisées pour vous connaître (par exemple, votre nom, la date de naissance) et en déduire ce à quoi vous pouvez accéder (par exemple, l'entrée dans un pays). Vous pouvez utiliser les propriétés du jeton pour interroger d'autres systèmes sur des informations supplémentaires auxquelles vous pourriez être associé (par exemple, votre relevé bancaire).
Ainsi, de manière analogue, SAML est généralement utilisé pour authentifier les utilisateurs sur un système (une fois que vous avez confiance en son origine), mais il n’existe aucune disposition relative à la gestion des profils utilisateur, ou «ressources».
Les décisions d’autorisation, le cas échéant, sont souvent prises en fonction des attributs associés à l’utilisateur (par exemple, le groupe auquel il appartient) et sont transmises aux revendications dans le jeton de sécurité.
La première question à laquelle vous devez peut-être répondre est la raison pour laquelle vous souhaitez vous éloigner de LDAP et penser à SAML. Est-ce parce que vous voulez accepter que les utilisateurs se connectent avec leurs propres informations d'identification? Est-ce parce que vous voulez vous débarrasser complètement du serveur LDAP?
Vous pourriez parfaitement conserver votre serveur LDAP pour gérer resources associated with users et authentifier les utilisateurs ailleurs. C'est ce que vous avez maintenant. Vous mettriez en corrélation les utilisateurs "extérieur" et "intérieur" via un attribut commun (par exemple un nom d'utilisateur ou un identifiant).
Si vous souhaitez vous débarrasser de LDAP tous ensemble, vous aurez besoin d'un autre endroit pour stocker ces informations (par exemple, votre base de données d'applications).
S'appuyant sur la réponse de Eugenio Pace , et en particulier à la suite de ce paragraphe:
Ainsi, de manière analogue, SAML est généralement utilisé pour authentifier les utilisateurs sur un système (une fois que vous avez confiance en son origine), mais il n’existe aucune disposition relative à la gestion des profils utilisateur, ou «ressources».
Les décisions d’autorisation, le cas échéant, sont souvent prises en fonction des attributs associés à l’utilisateur (par exemple, le groupe auquel il appartient) et sont transmises aux revendications dans le jeton de sécurité.
Eugenio se réfère ici à ABAC - le contrôle d'accès par attribut. SAML ne fait pas ça. Pour atteindre ABAC, vous avez besoin de XACML. SAML et XACML sont des normes définies par OASIS et interopérables. Avec XACML, vous pouvez définir des règles basées sur des attributs. Par exemple, nous pourrions revenir sur votre exemple et écrire une règle comme suit:
- Un utilisateur avec rôle == administrateur peut effectuer le action == update sur une ressource de type == imprimante si et seulement si le département de l'utilisateur == département de l'imprimante.
Vous pouvez en savoir plus sur XACML sur ABAC sur ces sites de référence:
- NIST's site sur ABAC.
- Comité technique OASIS XACML