SSO SAML SP - Wie viele Websites unter einem SP abdecken?

Question

Ich versuche, einen SAML-Dienstanbieter zu implementieren, aber ich bin mir nicht sicher, welche Ebene des Systems mit einem einzelnen SP abgedeckt werden soll.

Welches Architekturniveau pro SP gilt als bewährte Methode? Sollten wir eines für unsere gesamte Abteilung, pro Server, pro Domain, pro Anwendungspool oder sogar für jede Site haben?

Unsere Organisation hat einen Shibboleth IDP und ich benutze kentor authservices. Es funktioniert für eine Site, aber die SP ist Teil dieser Site. Angenommen, es gibt keine Praxis pro Website, wenn jemand einen Hinweis darauf hat, wie man sich am besten an eine generische Version (d. H. Eine Entitäten-ID für mehrere Sites) annähern könnte.

Answer 1

Irgendwie müssen Sie die Anmeldeinformationen in jede Site/Anwendung erhalten. Entweder Sie verwenden einen SP pro Site (dies ist der Ansatz von Kentor.AuthServices) oder Sie richten einen Shibboleth SP-Proxy vor den Web-Apps ein. Letzteres bedeutet, dass Sie jeder Site Code hinzufügen müssen, um die HTTP-Header zu analysieren, die Shibboleth liefert. Ich mag diesen Ansatz nicht - deshalb habe ich das Kentor.AuthServices-Projekt gestartet.

Also meine Präferenz ist es, jede Site zu einem geeigneten SP durch ein Modul zu machen, das so nativ wie möglich für das Web Application Framework ist. Relevante Module sind Kentor.AuthServices (.NET), SimpleSamlPhp, Spring (Java), saml2-js (Knoten).

Für den Fall, dass Ihre Organisation mehrere Standorte/Anwendungen hat, die Sie mit mehreren Upstream-Identitätsanbietern verbinden möchten, erhalten Sie NxM-Konfigurationspaare, die nicht skalierbar sind. Eine Option in diesem Fall ist das Einfügen eines SAML2 Proxys, der als Idp für Ihre internen Anwendungen und als SP für die externen Idps fungiert. Neue Sites/Anwendungen müssen nur im Proxy konfiguriert werden und neue externe Ids müssen nur im Proxy konfiguriert werden.