Le portail BrandShelter prend en charge le SSO, et il est donc possible de fédérer votre fournisseur d’identité à l’authentification unique de BrandShelter (Microsoft Azure AD ou Okta).

Pour cela, vous trouverez la documentation suivante 240802_EN_SSO user guide.pdf et les éléments ci-dessous qui vous permettront d'implémenter le IdP (Identity Provider).

Préambule important : La connexion doit toujours être démarrée via le portail BrandShelter.

Nous ne prenons pas en charge la connexion initiée par le IdP et vous ne pouvez pas utiliser certaines fonctionnalités telles que le « lien d’intégration » fourni par Okta pour cette raison. La connexion doit être démarrée via le portail BrandShelter.

Il sera également impératif de vous connecter depuis l'URL de connexion BrandShelter renseignée dans votre configuration SSO.

• Si vous renseignez "https://home.safebrands.com" dans vos données de fédération, la connexion SSO devra être démarrée impérativement depuis cette URL.
  
  
• Si vous renseignez "https://secure.brandshelter.com" dans vos données de fédération, la connexion SSO devra être démarrée impérativement depuis cette URL.

Configuration requise au niveau de l’IdP

Microsoft Entra ID (formerly Azure AD)

The following data needs to be configured on Azure AD:

• Identifier (Client ID) (mandatory)
• Reply URL (mandatory)
• Sign on URL (mandatory)
• Relay State (optional)

• Pour Microsoft Entra ID (anciennement Microsoft Azure AD) :

For the BrandShelter production environment

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

• Pour Okta (SAML) :

For the BrandShelter production environment

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: leave blank
• In Security/API/Trusted Origins, add https://bs-live-auth.auth.eu-central-1.amazoncognito.com as a permitted “redirect”

• Pour Okta (OpenID Connect) :

For the BrandShelter production environment

secure.brandshelter.com

• Single Sign On URL: https://bs-live-auth.auth.eu-central-1.amazoncognito.com/oauth2/idpresponse
• In Security/API/Trusted Origins, add https://bs-live-auth.auth.eu-central-1.amazoncognito.com as a permitted “redirect”

Mapping d’attributs

Par défaut, nous traitons les éléments suivants pour intégrer les utilisateurs :

• Pour SAML :

• • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/workphone

• Champs et attributs OIDC :

• • “profile” champ pour given_name and family_name

  • “email” champ pour email

  • “phone” champ pour phone_number

Nous utilisons le format de nom « URI Reference » ; et nous attribuons user.email aux attributs « name » et « emailaddress », mais d'autres mapping peuvent fonctionner également.

Exemple : 

D’autres attributs peuvent être mappés sur demande.

Avertissement

IMPORTANT :
Les attributs ci-dessus sont obligatoires, et nous ne pouvons pas modifier ces exigences sans recréer le groupe d’utilisateurs et casser toutes les fédérations existantes.

Par ailleurs, Amazon Cognito requiert que les numéros de téléphone soient indiqués dans un format très spécifique :
“Les numéros de téléphone doivent impérativement respecter les règles de format suivantes : un numéro de téléphone doit commencer par un signe plus (+), suivi immédiatement de l’indicatif du pays. Un numéro de téléphone ne peut contenir que le signe + et des chiffres. Supprimez tous les autres caractères dans un numéro de téléphone, tels que les parenthèses, les espaces ou les tirets (-) avant d’envoyer la valeur au service. Par exemple, un numéro de téléphone basé aux États-Unis doit suivre le format suivant : +14325551212.”

Si vous n’êtes pas en mesure de fournir ce format, nous vous conseillons de mapper un attribut vide afin que les utilisateurs puissent saisir ces informations lors du processus d’intégration. Par exemple, dans Okta, un administrateur peut simplement mapper la chaîne vide à l’attribut / fonction phone_number pour son application BrandShelter :

Fournir les données de fédération à BrandShelter

Il faudra impérativement nous fournir une URL de métadonnées (Metadata URL) ou un document de métadonnées (fichier XML), et les domaines de messagerie (@exemple.com) utilisés par vos utilisateurs pour la connexion.

Et nous indiquer le protocole de fédération SSO : SAML ou OIDC.

IMPORTANT : vous avez le choix entre 2 configurations possibles pour l'accès au portail BrandShelter après activation du SSO.

1) Configuration 1 par défaut - connexion BrandShelter + SSO

Les 2 méthodes de connexion cohabitent, connexion directe et SSO :

• vous pouvez vous connecter en utilisant la connexion directe BrandShelter (nom d'utilisateur + mot de passe)
• ou en utilisant la connexion SSO qui nécessite de saisir uniquement votre adresse email (ou nom d'utilisateur SSO) dans le champ "Nom d'utilisateur", puis de cliquer sur "Connexion" sans saisir le mot de passe pour être redirigé vers le formulaire SSO.

Cette configuration est prévue pour permettre l'ajout et la connexion d'utilisateurs qui n'auraient pas une adresse email liée au SSO et qui aurait donc besoin d'une connexion directe au portail pour accéder à votre compte.

2) Configuration 2 à activer sur demande - connexion unique SSO

Nous désactivons la connexion directe BrandShelter (nom d'utilisateur + mot de passe) et seule la méthode SSO est possible.

Cela rend donc obligatoire et incontournable la connexion par votre SSO pour tous les utilisateurs du compte sans exception.

Note 1 : Chaque utilisateur dont l'adresse email de connexion correspond à l’un de ces domaines de messagerie devra s’authentifier via l’authentification unique (SSO) (configuration 2). Tout utilisateur de ce compte avec un nom d’utilisateur qui ne correspond pas à l’un de ces domaines aura besoin de ses informations d’identification locales habituelles (configuration 1 par défaut). Par exemple, le domaine de messagerie example.com correspondra aux noms de connexion comme nom@example.com.

Note 2 : Nous ne prenons pas en charge la connexion initiée par l’IdP, et il n'est pas possible d'utiliser certaines fonctionnalités telles que le « lien d’intégration » fourni par Okta pour cette raison, ou via d'autres plateformes d’authentification, par exemple, depuis le portail « Mes applications » de Microsoft Azure. La connexion doit être démarrée via le portail BrandShelter.

Veuillez donc vous assurer que les utilisateurs initient toujours la connexion sur notre portail.

Note 3 : Un nouvel utilisateur se retrouvera toujours sur la page de création de compte de BrandShelter pour remplir toutes les informations non fournies par son IdP. De même, il est important de noter qu'un utilisateur existant du portail pourra être redirigé sur la page de création de compte dans BrandShelter pour remplir et.ou mettre à jour toutes les informations non fournies par son IdP.

Expérience utilisateur après activation du SSO :

L'utilisateur visite le portail BrandShelter. S’il est déjà authentifié auprès de son fournisseur d’identité d’entreprise, il est immédiatement connecté à l'application BrandShelter et le processus s’arrête ici.

S'il n'est pas encore authentifié, l’utilisateur saisit son nom de connexion (SSO username ou @example.com) dans le formulaire de connexion BrandShelter. L’utilisateur est alors redirigé vers le formulaire de connexion de son entreprise, il peut s’agir par exemple du formulaire de connexion Microsoft. Après avoir saisi ses informations d’identification, l’utilisateur est redirigé vers le portail BrandShelter et y est connecté.

Autres liens utiles : 

FAQ d'Amazon Cognito

Erreurs fréquentes

“Required String parameter 'RelayState' is not present” on the Cognito-hosted page

Patientez quelques minutes après avoir saisi les informations. Nous avons réussi à reproduire l’erreur en changeant l’application dans AAD et en lançant immédiatement une connexion, mais nous n’avons pas obtenu une reproduction solide.

“An error was encountered with the requested page.” (no further info) on the Cognito-hosted page

Cela peut se produire lorsque vous tentez d’utiliser la connexion initiée par l’IdP, par exemple via le bouton « Tester la connexion » dans le portail Azure ou le portail « Mon application ». BrandShelter ne prend pas en charge cela pour le moment, mais nous y travaillons.

Pour l’instant, assurez-vous de lancer la connexion via le portail BrandShelter et depuis l'URL de connexion renseignée dans votre configuration SSO, comme indiqué dans le préambule en haut de page, pour que l’IdP redirige les utilisateurs vers notre portail.

“Invalid relayState from identity provider” or “Invalid samlResponse or relayState from identity provider” on the Cognito-hosted page

Il s’agit d’une autre réaction à la connexion initiée par l’IdP, observée lors de la tentative d’utilisation d’Okta Embed Link.

“Invalid saml response received: client is not enabled for oauth2.0 flows “ on the BrandShelter hosted login page

Cela indique que l’URL de réponse est incorrecte. Assurez-vous d’utiliser les URL indiquées en haut de la page.

Cela peut également être dû au fait que le client Cognito n’a pas l’indicateur AllowedOAuthFlowsUserPoolClient dans le client d’application, ce qui était un problème dans les anciennes versions des scripts d’installation automatique. Pour résoudre ce problème, un développeur peut simplement entrer dans la page d’édition du client de l’application et l’enregistrer sans modification.

“Could not authenticate you from OpenIDConnect because “invalid ‘state’ parameter” on the BrandShelter hosted login page

Assurez-vous que l’utilisateur initie bien la connexion depuis le même hôte vers lequel il sera finalement transféré (et renseigné dans votre configuration SSO). Un utilisateur associé à une configuration SSO utilisant, par exemple, home.safebrands.com ne peut pas initier la connexion depuis secure.brandshelter.com. Nous travaillons pour que cela n'ait plus d'impact et que la connexion puisse être initiée depuis les 2 URL.

“Your single sign-on user <email> is not assigned to any <brand> account”

Assurez-vous que l’utilisateur en question est bien affecté au groupe approprié pour le client d’application dans Cognito.

“Could not authenticate you from OpenIDConnect because "Invalid SAML response received: invalid phone number format.”

Reportez-vous à l'avertissement surligné en jaune ci-dessus dans notre documentation et vérifiez votre configuration SSO : ce message indique une erreur dans le mapping d’attributs de votre configuration SSO, précisément sur le format du numéro de téléphone.