Blog | WeScale

Fédérer ses utilisateurs locaux avec ADFS et AWS via SSO

Rédigé par Sophnel Merzier | 06/04/2022

 

Dans cet article, nous allons voir comment fédérer ADFS (Active Directory Federation Services) et AWS pour un environnement de type SSO (Single Sign-On).
Dans la suite de l'article nous considérons les pré-requis suivants :

  • Windows serveur avec un AD (Active Directory) qui fonctionne
  • ADFS
  • AWS (free tiers est OK)
  • Un certificat SSL (auto-signé est OK pour la démo)

Une vue haut niveau de l'intégration d'ADFS avec AWS

Schéma de la relation entre ADFS et AWS

  1. L'utilisateur se connectera à son portail ADFS
  2. L'ADFS vérifie l'accès de l'utilisateur et s'authentifie par rapport à l'Active Directory.
  3. Une réponse est reçue sous la forme d'une assertion SAML contenant des informations sur l'appartenance à un groupe.
  4. Les ARN sont construits dynamiquement à l'aide des informations d'appartenance à un groupe AD pour les rôles IAM, tandis que les attributs d'utilisateur (distinguishedName, mail, sAMAccountName) sont utilisés pour les ID de compte AWS. ADFS envoie une assertion signée à AWS STS (Security Token Service).
  5. Les informations d'identification temporaires sont données par STS AssumeRoleWithSAML.
  6. L'utilisateur est authentifié et donne accès à la console de gestion AWS.

Dans la suite de ce tutoriel, nous allons rendre ce flow possible en connectant ADFS à AWS et inversement.
Configurer la fédération en local avec ADFS
Notre environnement SSO passe d’abord par la configuration de l’Active Directory et de l’ADFS.

  1. Créons plusieurs groupes AD avec un nommage spécifique en respectant les majuscules ou minisucule (AWS- -<ROLE/SERVICE>). Ils représentent les services/rôles qu’on peut typiquement voir dans une entreprise.Vous pouvez avoir une nomenclature différente, il faudra alors changer les valeurs dans les étapes suivantes.

Groupes AD

  1. Les utilisateurs seront mis dans ces groupes pour donner les accès avec les droits correspondant sur AWS. Un utilisateur, Laurent Kurosaki, a été ajouté dans ces groupes.
  2. Un compte de service a été spécialement créé pour l’ADFS que nous nommons adfsaws.

Notre prochaine étape est la configuration du rôle ADFS. Partons du principe que nous n’avons pas d’ADFS de configuré :

  1. Sélectionner l’option comme ci dessous

Adfs configuration

  1. Le certificat ici est auto-signé en utilisant IIS (à noter qu’un tel certificat ne doit pas s’utiliser dans le cadre d’un environnement de production)

Adfs configuration

Adfs configuration

  1. Sélectionner votre préférence pour la base de données. Cliquez sur “Next”.
  2. Le warning SPN (Service Principal Name) est résolu en lançant la commande
setspn -a host/localhost adfsaws

en administrateur PowerShell, adfsaws étant le compte de service créé au début.

Adfs configuration

ADFS en tant que fournisseur d’identités AWS

Pour que AWS reconnaisse notre fournisseur d’identité local (ADFS) il sera configuré de la manière suivante :

  1. Dans IAM, on crée un nouveau fournisseur d’identité en choisissant le type SAML. Ensuite, depuis notre serveur Active Directory on récupère le .XML ADFS en allant à https:// /FederationMetadata/2007-06/FederationMetadata.xml

Fournisseur d’identité dans IAM

  1. Dans la partie Rôles d’IAM, on en crée 2 avec des noms identiques à nos groupes AD

Fournisseur d’identité IAM

Le résultat final ressemble à ceci :

Les Rôles

Dans cette partie nous avons donné l'autorisation à notre (ADFS) fournisseur d'identité de communiquer et d'être utilisé dans AWS. Nous avons créé deux rôles à partir desquels nos futurs utilisateurs obtiendront leurs permissions, qui sont liés aux groupes AD.

Définir AWS en tant que cible de confiance d'ADFS

Nous allons maintenant faire en sorte que ADFS fasse confiance à AWS.

  1. Dans la console ADFS, clic droit sur relying party trusts, mettre l’adresse https://signin.aws.amazon.com/static/saml-metadata.xml

Cliquons sur suivant en choisissant les options qui nous conviennent.

  1. Faire un clic droit sur le relying party trusts qu’on vient de créer pour l’éditer

Modification des claims

On va créer plusieurs règles qui sont les suivantes :

  1. Choisir Transform an Incoming Claim pour le template, Ensuite ajouter les informations suivantes pour la règle NameID :

Règle NameID

  1. La règle RoleSessionName est créé en sélectionnant Send LDAP Attributes as Claims et en ajoutant les informations suivantes :

Pour E-mail-Adresses c’est https://aws.amazon.com/SAML/Attributes/RoleSessionName

Règle RoleSessionName

Les deux prochaines règles sont un peu différentes des autres, car elles sont faites sur mesure.
La première règle récupère tous les groupes de l'utilisateur authentifié (lors de l'authentification sur la page ADFS). La seconde effectue la transformation des rôles en faisant correspondre les noms des rôles sur AWS et dans l’AD.

  1. Refaire la même manipulation que pour les autres règles, mais cette fois-ci en choisissant le template Send Claims Using a Custom Rule, Ensuite on met ce script et comme nom Get AD Groups :
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

Règle Get AD Groups

  1. Enfin Choisir le même template que précédemment, ajouter le nom Roles et ce script :
c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"] => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::123456789012:saml-provider/wescale,arn:aws:iam::123456789012:role/AWS-"));

Le premier ARN (en jaune) est celui de l’identity provider dans IAM.

Le second est le début du ARN d’un des rôles créé dans IAM (voir capture d’écran ci-dessous)

Règle Roles

Explications : Ce script récupère tous les groupes dans lesquels l’utilisateur est authentifié, ensuite il compare les groupes (rôles) créés sur AWS commençant par AWS, donc si vous aviez choisi une règle de nommage différente, il faut également la modifier.

Résultat Final

Aller à l’adresse https://<nomseveurcomplet>/adfs/ls/IdpInitiatedSignOn.aspx ou https://localhost/adfs/ls/IdpInitiatedSignOn.aspx

Si vous obtenez une erreur en accédant à cette page, il y a de fortes chances que cela soit dû à la désactivation de l’option EnableIdpInitiatedSignOnPage.

On lance en administrateur la commande PowerShell suivante :

Set-Adfsproperties -enableIdPInitiatedSignonPage $true

Ensuite on redémarre le service ADFS avec la commande Restart-Service adfssrv

Voici à quoi ressemble la page de connexion après des modifications sur le design.

On clique sur notre site configuré, ensuite sur connexion avec les informations de connexion d’un des utilisateurs dans les groupes AD précédemment . Par exemple Laurent Kurosaki.

On arrive sur cette page qui nous permet de choisir le rôle avec les droits et autorisations qu’on va attribuer à  cet utilisateur sur AWS.
Ici, cet utilisateur est dans les groupes ADMIN et DEV de notre AD, on n'aura pas cette page si l’authentifié appartenait à un seul groupe parce qu’il aurait pris par défaut.

On arrive finalement sur AWS avec un utilisateur de notre AD avec des droits spécifiques :

 

Debugging

  • Erreur n° 1 → Specified provider doesn't exist [...] AuthSamlManifestNotFound.

Solution → On vérifie les informations du provider sur AWS et ADFS.

  • Erreur n°2 → RoleSessionName is required in AuthnResponse

Solution → Un problème de l’utilisateur dans l’AD manquant des attributs essentiels comme :

  • distinguishedName
  • Mail
  • sAMAccountName
  • userPrincipalName

On vérifie pour chacun de ses attributs.
PS : Il faut activer les advanced features pour avoir l’option Attribute Editor

  • Erreur n° 3 → Not authorized to perform sts:AssumeRoleWithSAML

Solution → On vérifie le nom des groupes dans l’AD, le nom des rôles sur AWS qui doivent être identique et surtout le préfix dans le dernier script (si vous avez suivi à la lettre ma règle de nommage) comme ci-dessous :

Ce préfix nous indique que les noms des rôles commencent par AWS.

Conclusion

Dans cet article, nous avons vu comment proposer la fédération dans votre entreprise.
ADFS et AWS vont fonctionner en tandem pour proposer un moyen efficace et sécurisé pour donner des autorisations temporaires, avec des permissions contrôlées à vos utilisateurs.
On a d’abord créé une relation de confiance entre les deux entités, ensuite configurer les règles et claims pour permettre à AWS de récupérer les informations nécessaires dans notre AD.

L’intérêt c’est la création d’un environnement SSO (Single Sign-On), un seul compte qui fonctionne en toute transparence sur les deux entités qui sont notre infrastructure locale et AWS.
Voir l'article complet