Das BrandShelter-Portal unterstützt SSO, sodass es möglich ist, Ihren Identity Provider (IdP) mit dem Single Sign-on von BrandShelter zu verbinden (z. B. Microsoft Entra ID (Azure AD) oder Okta).
Zur Einrichtung Ihres IdP finden Sie die folgende Dokumentation BrandShelter_SSO_Implementation_Guide_DE.pdf sowie die unten aufgeführten Attribute, die Ihnen die Implementierung des IdP ermöglichen.
Wichtiger Hinweis vorab: Die Verbindung muss über das BrandShelter-Portal gestartet werden.
Wir unterstützen keinen IdP-initiierten Login und Sie können aus diesem Grund keine Funktionen wie den von Okta bereitgestellten „Embed Link“ verwenden. Der Login muss über das BrandShelter-Portal gestartet werden.
Es ist zudem zwingend erforderlich, sich über die in Ihrer SSO-Konfiguration angegebene BrandShelter-Verbindungs-URL zu verbinden.
- Wenn Sie "
https://home.safebrands.com" in Ihren Föderationsdaten eingeben, muss die SSO-Verbindung von dieser URL gestartet werden.
- Wenn Sie "
https://secure.brandshelter.com" in Ihren Föderationsdaten eingeben, muss die SSO-Verbindung von dieser URL gestartet werden.
MFA-2FA: Wenn sich ein Benutzer über SSO anmeldet, fordert BrandShelter keine MFA (TAN) an, selbst wenn eine TAN-Methode bereits in den Benutzerberechtigungen eingerichtet ist. Ob MFA verwendet wird (optional oder verpflichtend), liegt in diesem Fall mit aktiviertem SSO in der Kontrolle Ihres Identity Providers (IdP).
Erforderliche Einrichtung beim IdP
Microsoft Entra ID (ehemals Azure AD)
Folgende Daten müssen in Azure AD konfiguriert werden:
- Identifier (Client-ID) (obligatorisch)
- Reply URL (obligatorisch)
- Sign on URL (obligatorisch)
- Relay State (optional)
• Für Microsoft Azure AD:
Für die BrandShelter-Produktionsumgebung
secure.brandshelter.com
- Client-ID:
urn:amazon:cognito:sp:eu-central-1_FmcrLjcuB - Reply URL:
https://bs-live-auth.auth.eu-central-1.amazoncognito.com/saml2/idpresponse - Sign on URL:
https://secure.brandshelter.com/users/sign_in - Relay State (optional):
https://secure.brandshelter.com/
• Für Okta (SAML):
Für die BrandShelter-Produktionsumgebung
secure.brandshelter.com
- Single Sign On URL:
https://bs-live-auth.auth.eu-central-1.amazoncognito.com/saml2/idpresponse - Audience restriction:
urn:amazon:cognito:sp:eu-central-1_FmcrLjcuB - Default Relay State: leer lassen
- In Sicherheit/API/Trusted Origins fügen Sie
https://bs-live-auth.auth.eu-central-1.amazoncognito.comals erlaubte „Redirect“-URL hinzu
• Für Okta (OpenID Connect):
Für die BrandShelter-Produktionsumgebung
secure.brandshelter.com
- Single Sign On URL:
https://bs-live-auth.auth.eu-central-1.amazoncognito.com/oauth2/idpresponse - In Sicherheit/API/Trusted Origins fügen Sie
https://bs-live-auth.auth.eu-central-1.amazoncognito.comals erlaubte „Redirect“-URL hinzu
Attributzuordnung
Standardmäßig verarbeiten wir die folgenden Assertions, um Benutzer einzubinden:
- Für SAML:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddresshttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/givennamehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/surnamehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/workphone
- Scopes und Attribute OIDC:
„profile“-Scope für
given_nameundfamily_name„email“-Scope für
email„phone“-Scope für
phone_number
Wir verwenden das Namensformat „URI Reference“; und weisen user.email sowohl den Attributen „name“ als auch „emailaddress“ zu, aber andere Zuordnungen können ebenfalls funktionieren.
Beispiel:
Andere Attribute können auf Anfrage zugeordnet werden.
WICHTIG:
Die oben genannten Attribute sind erforderlich, und wir können diese Anforderungen nicht ändern, ohne den Benutzerpool neu zu erstellen und alle bestehenden Föderationen zu unterbrechen.
Zusätzlich erfordert Cognito Telefonnummern in einem sehr spezifischen Format:
„Telefonnummern müssen folgende Formatregeln einhalten: Eine Telefonnummer muss mit einem Pluszeichen (+) beginnen, gefolgt unmittelbar vom Ländercode. Eine Telefonnummer darf nur das Pluszeichen und Ziffern enthalten. Entfernen Sie vor der Übermittlung an den Dienst alle anderen Zeichen aus der Telefonnummer, wie Klammern, Leerzeichen oder Bindestriche (-). Zum Beispiel muss eine Telefonnummer aus den Vereinigten Staaten folgendes Format haben: +14325551212.“
Wenn Sie dieses Format nicht bereitstellen können, empfehlen wir, ein leeres Attribut zuzuordnen, damit Benutzer diese Information während des Onboarding-Prozesses eingeben können. Zum Beispiel kann ein Administrator in Okta einfach den leeren String dem Attribut phone_number für ihre BrandShelter-Anwendung zuordnen:
Bereitstellung der Föderationsdaten an BrandShelter
Sie müssen uns eine Metadata-URL oder ein Dokument (XML-Datei) sowie die von Ihren Benutzern für die Anmeldung verwendeten Mail-Domains bereitstellen.
Und geben Sie das für die SSO-Föderation verwendete Protokoll an, also SAML oder OIDC.
WICHTIG: Sie können zwischen 2 möglichen Konfigurationen für den Zugang zum BrandShelter-Portal nach der SSO-Aktivierung wählen.
1) Standardkonfiguration 1 - BrandShelter + SSO-Verbindung
Die 2 Verbindungsarten koexistieren, Direktverbindung und SSO:
- Sie können sich mit dem direkten BrandShelter-Login (Benutzername + Passwort) anmelden
- oder über den SSO-Login, bei dem nur Ihre E-Mail-Adresse (oder SSO-Benutzername) im Feld „Benutzername“ eingegeben wird und dann auf „Login“ geklickt wird, ohne das Passwort einzugeben, um zum SSO-Formular weitergeleitet zu werden.
Diese Konfiguration soll die Hinzufügung und Anmeldung von Benutzern ermöglichen, die keine E-Mail-Adresse mit SSO verknüpft haben und daher eine direkte Verbindung zum Portal benötigen, um auf Ihr Konto zuzugreifen.
2) Konfiguration 2, die auf Anfrage aktiviert wird - SSO Single Sign-on
Wir deaktivieren die direkte BrandShelter-Verbindung (Benutzername + Passwort) und nur die SSO-Methode ist möglich.
Dies macht die SSO-Verbindung für alle Benutzer des Kontos ohne Ausnahme verpflichtend und unvermeidlich.
Hinweis 1: Jeder Benutzer mit einem Benutzernamen, der einem dieser Hosts entspricht, muss sich über Single Sign-On (SSO) authentifizieren (Konfiguration 2). Jeder Benutzer dieses Kontos mit einem Benutzernamen, der keinem dieser Hosts entspricht, benötigt seine normalen lokalen Zugangsdaten und verwendet kein SSO (Standardkonfiguration 1). Zum Beispiel entspricht der Hostname example.com Benutzernamen wie name@example.com.
Hinweis 2: Bitte beachten Sie, dass BrandShelter keinen IdP-initiierten Login unterstützt. Das bedeutet, dass bestimmte Funktionen, wie der von Okta bereitgestellte „Embed Link“, nicht für Login-Zwecke oder über andere Authentifizierungsplattformen, z. B. das Azure „My Applications“-Portal, verwendet werden können. Alle Logins müssen über das BrandShelter-Portal initiiert werden, um eine ordnungsgemäße Authentifizierung und den Zugang sicherzustellen.
Bitte stellen Sie daher sicher, dass die Benutzer den Login-Versuch immer über unser Portal starten.
Hinweis 3: Ein neuer Benutzer wird weiterhin zur BrandShelter-Kontoerstellungsseite weitergeleitet, um alle vom IdP nicht bereitgestellten Informationen auszufüllen. Zudem ist es wichtig zu beachten, dass ein bestehender Portalbenutzer zur Kontoerstellungsseite bei BrandShelter weitergeleitet wird, um alle vom IdP nicht bereitgestellten Informationen auszufüllen und/oder zu aktualisieren.
Benutzererlebnis nach Aktivierung von SSO:
Ein Benutzer besucht das BrandShelter-Portal. Wenn er bereits mit seinem Unternehmens-Identity Provider authentifiziert ist, wird er sofort bei BrandShelter angemeldet und der Prozess endet hier.
Wenn er noch nicht authentifiziert ist, gibt der Benutzer seinen Anmeldenamen (SSO-Benutzername oder @example.com) im BrandShelter-Anmeldeformular ein. Der Benutzer wird zum Anmeldeformular seines Unternehmens weitergeleitet, dies könnte beispielsweise das Microsoft-Anmeldeformular sein. Nach Eingabe seiner Zugangsdaten wird der Benutzer zurück zum BrandShelter-Portal geleitet und dort angemeldet.
Link zu weiteren Informationen:
Häufige Fehler
„Required String parameter 'RelayState' is not present“ auf der von Cognito gehosteten Seite
Warten Sie einige Minuten nach Eingabe der Informationen. Wir konnten den Fehler reproduzieren, indem wir die Anwendung in AAD geändert und sofort eine Anmeldung initiiert haben, jedoch ohne eine verlässliche Reproduktion.
„An error was encountered with the requested page.“ (keine weiteren Informationen) auf der von Cognito gehosteten Seite
Dies kann auftreten, wenn versucht wird, einen IdP-initiierten Login zu verwenden, z. B. über den „Test sign in“-Button im Azure Portal oder das „My Application“-Portal. BrandShelter unterstützt dies derzeit nicht, arbeitet aber daran.
Bitte stellen Sie vorerst sicher, dass Sie die Anmeldung über das BrandShelter-Portal starten oder die korrekte Anmelde-URL verwenden, wie im Hinweis am Anfang der Seite angegeben, damit der IdP die Benutzer zu unserem Portal weiterleitet.
„Invalid relayState from identity provider“ oder „Invalid samlResponse or relayState from identity provider“ auf der von Cognito gehosteten Seite
Dies ist eine weitere Reaktion auf einen IdP-initiierten Login, beobachtet beim Versuch, den Okta Embed Link zu verwenden.
„Invalid saml response received: client is not enabled for oauth2.0 flows“ auf der von BrandShelter gehosteten Login-Seite
Dies weist auf eine falsche Reply URL hin. Stellen Sie sicher, dass Sie die am Seitenanfang angegebenen URLs verwenden.
Dies kann auch dadurch verursacht werden, dass im Cognito-Client die Option AllowedOAuthFlowsUserPoolClient fehlt, was ein Problem in älteren Versionen der automatisierten Setup-Skripte war. Um dies zu beheben, kann ein Entwickler einfach die Bearbeitungsseite des Anwendungsklienten öffnen und ohne Änderungen speichern.
„Could not authenticate you from OpenIDConnect because “invalid ‘state’ parameter“ auf der von BrandShelter gehosteten Login-Seite
Stellen Sie sicher, dass der Benutzer die Anmeldung auf demselben Host initiiert, zu dem er letztendlich weitergeleitet wird (und der in Ihren SSO-Einstellungen angegeben ist). Ein Benutzer in einem Konto, das z. B. home.safebrands.com verwendet, kann sich nicht bei secure.brandshelter.com anmelden. Wir arbeiten daran, dass dies keinen Einfluss mehr hat und die Verbindung von beiden URLs initiiert werden kann.
„Your single sign-on user <email> is not assigned to any <brand> account“
Stellen Sie sicher, dass der betreffende Benutzer der entsprechenden Gruppe für den Anwendungsklienten in Cognito zugewiesen ist.
„Could not authenticate you from OpenIDConnect because "Invalid SAML response received: invalid phone number format.“
Beziehen Sie sich auf die oben auf dieser Seite gelb hervorgehobene Warnung und überprüfen Sie Ihre SSO-Konfiguration: Diese Meldung weist auf einen Fehler in der Attributzuordnung Ihrer SSO-Konfiguration hin, speziell im Format der Telefonnummer.
„Could not authenticate you from OpenIDConnect because "Bad id token issuer https://companyname.okta.com" ”
Die Fehlermeldung „Bad ID token issuer“ tritt typischerweise auf, wenn der Aussteller des ID-Tokens nicht mit dem erwarteten Aussteller übereinstimmt, der in Ihrer Anwendung konfiguriert ist. Dies ist ein häufiges Problem bei OpenID Connect (OIDC)-Implementierungen.
Ursache
Der Fehler zeigt an, dass der vom OIDC-Prozess zurückgegebene Aussteller nicht mit dem in Ihrer Anwendung konfigurierten übereinstimmt. Diese Abweichung kann auftreten, wenn der Identity Provider (IdP) eine andere Aussteller-URL sendet als von Ihrer Anwendung erwartet.
Lösung
Um dieses Problem zu beheben, müssen Sie die Aussteller-URL in der Konfiguration Ihrer Anwendung aktualisieren, sodass sie mit der vom IdP gesendeten übereinstimmt. Wenn z. B. der unerwartete Aussteller "https://companyname.okta.com" ist, sollten Sie Ihre Anwendung so konfigurieren, dass diese URL als Aussteller akzeptiert wird.
Wenn weiterhin Probleme auftreten, stellen Sie sicher, dass alle anderen OIDC-Konfigurationen, wie Client-ID und Audience, korrekt eingerichtet sind und mit den Einstellungen des IdP übereinstimmen.