LDAP vs SAML Authorization

Question

Ich untersuche derzeit das Verschieben eines Asset-Tracking-Systems von LDAP zu SAML. Es gibt zwei Hauptbereiche, in denen unsere Software derzeit LDAP verwendet. Der erste ist die Authentifizierung. Um heute auf das System zugreifen zu können, müssen Sie sich erfolgreich mit LDAP authentifizieren und Mitglied einer bestimmten LDAP-Gruppe sein. Dieser Teil ist relativ einfach zu SAML zu verschieben. Wir haben eine Bibliothek verwendet, um den größten Teil der schmutzigen Arbeit zu erledigen. Und auf dem IDP können wir einen Anspruch hinzufügen, um den Benutzer zu autorisieren. Aber unsere zweite Verwendung von LDAP wirft mich auf eine Schleife.

Heute kann jedes Asset, das wir verwalten, mit einem Benutzernamen verknüpft werden. Zum Beispiel kann ein bestimmter Drucker zu 'someuser' gehören. Eine der Optionen, die unsere Software dem Administrator bietet, ist das Anzeigen/Interagieren mit Assets basierend auf LDAP-Benutzergruppen. Als Administrator möchte ich möglicherweise alle Drucker aktualisieren, die Personen in einer bestimmten Abteilung gehören. Um dies zu erreichen, würde der Administrator eine Regel für die LDAP-Gruppe "departmentInQuestion" erstellen. Unsere Software würde dann ein Dienstkonto verwenden, um sich mit LDAP zu verbinden, eine Abfrage erstellen, um zu sehen, welche Benutzer von unserem System in 'departmentInQuestion' sind, diese ausführen und die Ergebnisse verwenden, um festzustellen, welche Elemente das Update erhalten sollen.

So weit von meiner Suche habe ich keinen SAML-Workflow analog zu diesem gefunden. Es scheint die einzige Möglichkeit zu sein, die wir als "someuser" bewerten müssen, wenn sie sich authentifizieren und wir Zugang zu ihren Ansprüchen erhalten. In unserem Workflow kann sich 'someuser' jedoch niemals mit uns authentifizieren. Es ist fast so, als würden wir einen Benutzer im Namen des Dienstkontos autorisieren. Gibt es einen bestehenden Workflow, den ich während meiner Erkundung übersehen habe? Gibt es andere Technologien, die die Autorisierung auf diese Weise unterstützen?

Danke für jede Eingabe!

Answer 1

SAML ist wie ein Reisepass oder ein Visum. Es gibt (vertrauenswürdige) Informationen über Sie, die dazu verwendet werden können, Sie kennen zu lernen (z. B. Ihr Name, DOB), und daraus abzuleiten, auf was Sie zugreifen können (z. B. Zugang zu einem Land). Sie können Eigenschaften im Token verwenden, um andere Systeme nach zusätzlichen Informationen abzufragen, die Ihnen möglicherweise zugeordnet sind (z. B. Ihr Kontoauszug).

Analog dazu wird SAML normalerweise verwendet, um Benutzer für ein System zu authentifizieren (sobald Sie seiner Herkunft vertrauen), aber es gibt keine Bestimmungen für die Verwaltung von Benutzerprofilen oder "Ressourcen".

Die Autorisierungsentscheidungen werden, wenn überhaupt, häufig basierend auf den Attributen getroffen, die dem Benutzer zugeordnet sind (z. B. der Gruppe, der er angehört), und in Ansprüchen in dem Sicherheitstoken übermittelt.

Vielleicht ist die erste Frage zu beantworten, warum Sie weg von LDAP und über SAML denken möchten. Liegt es daran, dass Sie Benutzer akzeptieren, die sich mit ihren eigenen Anmeldeinformationen anmelden? Ist es, weil Sie den LDAP-Server insgesamt loswerden möchten

Sie könnten Ihren LDAP-Server perfekt für die Verwaltung von resources associated with users verwalten und Benutzer woanders authentifizieren. Das hast du jetzt. Sie würden Benutzer "außerhalb" und "innerhalb" über ein gemeinsames Attribut (z. B. einen Benutzernamen oder eine ID) korrelieren.

Wenn Sie LDAP alle zusammen loswerden möchten, benötigen Sie eine andere Stelle zum Speichern dieser Informationen (z. B. Ihre App-Datenbank).

Answer 2

Aufbauend auf Eugenio Pace ‚s Antwort, und insbesondere nach diesem Absatz:

So analog ist SAML typischerweise auf ein System zur Authentifizierung von Benutzern verwendet (wenn man seinen Ursprung vertrauen), aber es ist keine Vorkehrungen für die Verwaltung von Benutzerprofilen oder "Ressourcen".

Die Autorisierungsentscheidungen werden, wenn überhaupt, häufig basierend auf den Attributen getroffen, die dem Benutzer zugeordnet sind (z. B. der Gruppe, der er angehört), und in Ansprüchen in dem Sicherheitstoken übermittelt.

Worauf sich Eugenio hier bezieht, ist ABAC - attributbasierte Zugriffskontrolle. SAML macht das nicht. Um ABAC zu erreichen, benötigen Sie XACML. SAML und XACML sind Standards, die von OASIS definiert werden und interoperieren. Mit XACML können Sie attributbasierte Regeln definieren. Zum Beispiel könnten wir Ihrem Beispiel überdenken und eine Regel wie folgt schreiben:

• Ein Benutzer mit der Rolle == Administrator kann tun, um die Aktion == Update auf einer Ressource von Typ == Drucker wenn und nur wenn die Abteilung des Benutzers == die Abteilung des Druckers.

Sie können mehr über XACML auf ABAC an diesen Referenzstellen lesen:

• NISTs site auf ABAC.
• OASIS XACML Technical Committee