Geben Sie das Zugriffsergebnis an, nicht nur ein SSO-Kontrollkästchen
Eine Anforderung, dass eine Authentifizierungsplattform SAML Single Sign-On unterstützen muss, ist unvollständig, es sei denn, sie erklärt, wer welchen Mandanten mit welchen Berechtigungen betreten soll und was passiert, wenn sich seine Rolle oder Beschäftigung ändert. Durch eine erfolgreiche Authentifizierung wird eine Identitätszusicherung im Rahmen einer vereinbarten Föderationsbeziehung erstellt. Es autorisiert nicht automatisch jede Domäne, jeden Kunden, jeden Bericht oder jede Verwaltungsaktion in der Anwendung. Beschaffungs- und Implementierungsprüfungen sollten daher das Zugriffsergebnis testen, anstatt eine erfolgreiche Anmeldung als gesamte Anforderung zu akzeptieren.
Bei diesem Artikel handelt es sich um einen vorgeschlagenen Anforderungsrahmen. Es wird nicht behauptet, dass EmailAuth SAML, Just-in-Time-Bereitstellung, bestimmte Rollen oder eine Sitzungskontrollfunktion implementiert. Es wurde kein Identitätsanbieter konfiguriert, keine Behauptung übermittelt oder kein Zugriff gewährt. Dokumentation zum SAML-Protokoll von Microsoft bietet eine konkrete offizielle Beschreibung eines von Entra unterstützten Austauschs, während die vorgeschlagenen Akzeptanzkriterien noch einer Bestätigung gegenüber der tatsächlichen Plattform und dem Identitätsanbieter bedürfen.
Binden Sie den Verbund an die vorgesehene Anwendung und den Mandanten
Dokumentieren Sie den Identitätsanbieter, den Dienstanbieter, den vorgesehenen Mandanten, den genehmigten Verbundadministrator und den Konfigurationseigentümer. Erfassen Sie die Anwendungskennung und den Assertion-Consumer-Endpunkt aus genehmigten Konfigurationsnachweisen, ohne Anmeldeinformationen zu kopieren oder vertrauliche Assertionen in ein allgemeines Arbeitsblatt zu vervollständigen. In der Entra-Dokumentation werden Emittenten-, Zielgruppen-, Antwortkorrelations- und Subjektbestätigungselemente beschrieben. Hierbei handelt es sich nicht um austauschbare Bezeichnungen: Eine Aussage, die für eine Anwendung bestimmt ist, sollte nicht allein deshalb zur Autorität für eine andere Anwendung werden, weil sie über eine gültige Signatur verfügt.
Fordern Sie die tatsächliche Implementierung auf, die Protokollelemente zu validieren, die für den unterstützten Ablauf geeignet sind, einschließlich Vertrauen in den Aussteller und das Signaturmaterial, die beabsichtigte Zielgruppe und den Empfänger, Gültigkeitsbedingungen und Anforderungskorrelation, sofern zutreffend. Erfinden Sie kein einziges Validierungsrezept, das jeden initiierten Flow oder jede initiierte Bibliothek abdeckt. Bitten Sie den Lieferanten, seine unterstützten Abläufe und Sicherheitsprüfungen zu dokumentieren und diese dann in einer autorisierten isolierten Umgebung zu überprüfen. Eine Beispiel-XML-Antwort in der Dokumentation ist kein Beweis dafür, dass die Zielplattform diese Prüfungen erzwingt.
Halten Sie Authentifizierung und Autorisierung getrennt
Leitfaden zur mehrinstanzenfähigen Identität von Azure unterscheidet zwischen rollenbasierter und ressourcenbasierter Autorisierung und warnt vor Fehlkonfigurationen des Verbunds, die unbeabsichtigten Mandanten Zugriff gewähren. Verwenden Sie diese Unterscheidung beim Schreiben von Anforderungen. Ein vom Identitätsanbieter eines Kunden authentifizierter Benutzer benötigt weiterhin eine autorisierte Beziehung zum richtigen Anwendungsmandanten und den richtigen Ressourcen. Ein E-Mail-Adresssuffix allein sollte ohne eine dokumentierte genehmigte Zuordnung nicht als vollständige Miet- oder Rollenentscheidung behandelt werden.
Geben Sie die zulässigen Rollen und den Ressourcenumfang unabhängig von der Anmeldemethode an. Ein Berichtsbetrachter liest möglicherweise ausgewählte Domänen, exportiert jedoch nicht alle Kunden. Ein Mandantenadministrator kann Mitglieder verwalten, ohne die Einstellungen eines anderen Mandanten zu ändern. Legen Sie fest, wer diese Zuordnungen erstellen oder ändern darf und wie Änderungen überprüft werden. Wenn Gruppen- oder Rollenattribute verwendet werden, dokumentieren Sie deren Quelle, akzeptierte Werte und Verhalten, wenn Attribute fehlen oder unerwartet sind. Hierbei handelt es sich um vorgeschlagene Kontrollen und nicht um Behauptungen über das Vorbild eines bestimmten Produkts.
Definieren Sie das Beitritts- und Rollenwechselverhalten
Geben Sie für einen neuen Benutzer an, ob das Konto im Voraus bereitgestellt werden muss oder ob unterstütztes Just-in-Time-Verhalten zulässig ist. Dokumentieren Sie, wie der vorgesehene Mieter ausgewählt wird und ob eine Genehmigung erforderlich ist, bevor die erste Sitzung auf Daten zugreifen kann. Schließen Sie die automatische Bereitstellung nicht aus der Verfügbarkeit der SAML-Authentifizierung ab. Der Lieferant muss sein tatsächlich unterstütztes Lebenszyklusverhalten und alle Unterschiede zwischen administrativem, interaktivem und API-Zugriff identifizieren.
Geben Sie bei Rollenänderungen an, wann neue Berechtigungen wirksam werden sollen und wie mit bestehenden Sitzungen umgegangen wird. Eine Anforderung sollte zwischen der Entfernung einer Rolle und der Deaktivierung eines Kontos unterscheiden. Es sollte auch angegeben werden, ob zwischengespeicherte Autorisierungsentscheidungen aktualisiert werden und wie das beobachtete Ergebnis überprüft wird. Gehen Sie nicht davon aus, dass eine neue Behauptung bei der nächsten Anmeldung jede bereits aktive Sitzung aktualisiert. Bewahren Sie nach einer Änderung tatsächliche Beweise für zulässige und verweigerte Aktionen auf, wenn der autorisierte Test schließlich durchgeführt wird.
Machen Sie die Deaktivierung und Sitzungsbehandlung explizit
Abhängig vom Verhalten der Anwendung kann das Identitätsanbieterkonto eines Mitarbeiters deaktiviert werden, während eine Dienstanbietersitzung aktiv bleibt. Die Anforderungen müssen fragen, wie bestehende Sitzungen, gespeicherte Geräte, lokale Fallback-Konten und nicht interaktive Anmeldeinformationen behandelt werden. Die SSO-Verfügbarkeit stellt an sich keine universelle Abmelde- oder Widerrufsgarantie dar. Fordern Sie den Lieferanten auf, die unterstützten Widerrufsmechanismen, die erwarteten Einschränkungen und die zu deren Überprüfung erforderlichen Nachweise zu beschreiben.
Trennen Sie routinemäßiges Offboarding von der Notfalleindämmung. Routineänderungen können auf die geplante Lebenszyklussynchronisierung folgen; Bei einem Vorfall kann es erforderlich sein, dass ein autorisierter Administrator den Zugriff umgehend über einen anderen unterstützten Pfad widerruft. In diesem Artikel werden diese Sicherheitsänderungen weder durchgeführt noch genehmigt. Es wird vorgeschlagen, dass ihre Eigentums- und Verifizierungskriterien vor der Einführung dokumentiert werden und nicht erst bei einem Vorfall entdeckt werden, wenn das Team davon ausgeht, dass die Deaktivierung des Identitätsanbieterkontos ausreichend war.
Ein SSO-Akzeptanzarbeitsblatt
Erstellen Sie ein Arbeitsblatt mit der Identitätsanbieter-Konfigurationsreferenz, dem Dienstanbieter-Mandanten, der Benutzertestidentität, der beabsichtigten Rolle, dem Ressourcenbereich, dem unterstützten Ablauf und dem erwarteten Ergebnis. Fügen Sie Zeilen für Beitritt, Rollenerhöhung, Rollenreduzierung, Deaktivierung, Verhalten bei aktiven Sitzungen und alle genehmigten lokalen Wiederherstellungspfade hinzu. Notieren Sie, wer jeden Test autorisiert und welche Umgebung die Vorrichtungen enthält. Fügen Sie keine echten Passwörter, Sitzungscookies, privaten Signaturschlüssel oder vollständigen Produktionszusicherungen in das Arbeitsblatt ein.
Schließen Sie negative Fälle ein, die Grenzen aufzeigen: Eine für einen anderen Mieter bestimmte Identität darf keinen Zugriff erhalten, ein Betrachter darf keine Administratorrechte erhalten und eine entfernte Rolle darf nicht stillschweigend über das dokumentierte Verhalten hinaus wirksam bleiben. Formulieren Sie diese als Akzeptanzkriterien, bis tatsächliche Ergebnisse vorliegen. Ein fehlgeschlagener Test sollte die Aktion und die beobachtete Reaktion aufzeichnen, ohne davon auszugehen, dass der Fehler nur deshalb sicher durchgesetzt wurde, weil die Schnittstelle eine Schaltfläche versteckte. Für die serverseitige Autorisierung sind eigene Nachweise erforderlich.
Fiktive Diagnose: Die Anmeldung ist erfolgreich, der Gültigkeitsbereich ist jedoch falsch
Eine fiktive Organisation evaluiert eine Plattform für zwei Kundenteams. Beide verwenden denselben Corporate-Identity-Anbieter, ihre Anwendungsmandanten müssen jedoch getrennt bleiben. Eine erste Demonstration zeigt erfolgreiches SSO und ein Berichts-Dashboard. Dem Prüfer fällt auf, dass bei der Demonstration nie festgestellt wurde, an welchen Mandanten der Testbenutzer gebunden war oder ob eine vorhandene Sitzung nach dem Entfernen eine Rolle behalten würde.
Das vorgeschlagene Follow-up ist ein autorisierter Fixture-basierter Test, der Mandantenbindung, Rollenreduzierung und Deaktivierung separat prüft. Eine erfolgreiche Anmeldung zählt nur für den Authentifizierungsteil der Anforderung. Hier wurde kein solcher Test durchgeführt, und die fiktive Plattform stellt keine Behauptung über EmailAuth oder einen anderen benannten Dienst dar. Das Beispiel erklärt, warum eine scheinbar vollständige SSO-Demonstration dazu führen kann, dass Fragen zum Materialzugriff unbeantwortet bleiben.
Verlangen Sie Nachweise, bevor Sie die Fähigkeit annehmen
Eine nützliche Lieferantenantwort identifiziert unterstützte Protokollabläufe, Lebenszyklusintegrationen, Rollenzuordnung, Sitzungsverhalten, Fallback-Zugriff und Prüfnachweise. Es gibt auch klare Einschränkungen an. Wandeln Sie eine Roadmap-Erklärung oder einen Screenshot nicht in einen Implementierungsnachweis um. Behalten Sie die Produktversion und den Konfigurationskontext bei, damit das Akzeptanzergebnis nach einem Anbieterwechsel interpretierbar bleibt.
Der Katalog erfordert das Testen von Beitritt, Rollenwechsel, Deaktivierung und Handhabung aktiver Sitzungen mit aktueller Plattformunterstützung. Der ursprüngliche Beweis bleibt offen. Dieser Entwurf enthält vorgeschlagene Anforderungen und eine fiktive Übung, keine Testergebnisse. Die Prüfung durch menschliche Spezialisten, die Anwendbarkeit der Quelle, die Produktionswege, die Zugänglichkeit und die Freigabe durch den Eigentümer sind ebenfalls offen. Für die Veröffentlichung und jeden Leistungsanspruch sind autorisierte Beobachtungen der tatsächlichen Plattform erforderlich und nicht allein Rückschlüsse aus der SAML-Dokumentation.