AWS Single Sign-On mit Azure Active Directory

Zuletzt aktualisiert am 10. Januar 2024

Wie viele unserer Kunden, nutzen auch wir Azure Active Directory (AAD) für die Identitäts- und Zugriffsverwaltung. Durch die Nutzung von Microsoft 365 hat jeder Kollege automatisch  einen Account. Da wir aber auch Services auf Amazon Webservices (AWS) betreiben, wäre es natürlich naheliegend, das AAD auch für die Zugriffsverwaltung in AWS zu nutzen. 

Überblick

• Vorteile einer zentralen Identitätsverwaltung 
• Gibt es da nicht auch eine Lösung von AWS? 
• Und so richtest Du deinen Single Sign-On ein 
• Vorbereitung auf AWS Seite 
• So konfigurierst Du deinen Service Provider in AWS 
• Erstellung der Enterprise Application in Azure 
• So schließt Du die Konfiguration in AWS ab 
• Automatische Benutzerprovisionierung 
• Vorbereitung in AWS 
• Provisionierung in Azure aktivieren 
• Zuweisung der Rechte in AWS 
• Zugang testen 
• Nutzung über die AWS CLI 

Vorteile einer zentralen Identitätsverwaltung 

Die Nutzung einer zentralen firmenweiten Identitätsverwaltung bringt einige Vorteile mit sich. So müssen nicht an vielen verschiedenen Stellen die Passwortrichtlinien gepflegt werden. Wenn ein neuer Kollege eintritt, erstellen wir nur an einer Stelle den Benutzer und weisen entsprechende Gruppen zu.  

Sollte uns ein Kollege verlassen, gibt es keine langen Listen an Diensten oder Programmen, in denen Zugriffe gesperrt oder Nutzer gelöscht werden müssen.  

Auch für unsere Kollegen wird die tägliche Arbeit erleichtert. Wir müssen uns keine Passwörter für alle möglichen Dienste merken oder fortlaufend die Passwörter an vielen Stellen ändern. 

Natürlich muss dieser eine Account dann aber auch entsprechend gesichert werden. Ein sicheres Passwort und die Aktivierung von Multi-Faktor-Authentifizierung ist definitiv ratsam. Auch machen wir uns sehr genau Gedanken, welche Rechte der jeweilige Kollege haben sollte.  

Es versteht sich zum Beispiel von selbst, dass der Kollege aus der HR keine administrativen Zugänge auf alle unsere Google Cloud Platform Ressourcen haben sollte. 

Gibt es da nicht auch eine Lösung von AWS? 

AWS Single Sign-On (SSO) ist ein Dienst mit dem der Zugriff auf AWS Konten oder Dienste wie G Suite, Atlassian, GitHub oder Microsoft 365 verwaltet werden kann.  

Das ist ja nun in gewisser Weise genau das, was wir nun vorhaben. Jedoch wollen wir die bestehenden Benutzer aus unserem AAD nutzen und nicht eine weitere Benutzerverwaltung einführen.  

Wir können glücklicherweise bei der Konfiguration von AWS SSO auch eine vorhandene Identitätsquelle nutzen. 

AWS SSO kann in AWS Organizations integriert werden. Das heißt, die Identitätsquelle kann in allen zugeordneten Accounts und den darin betriebenen Applikationen genutzt werden. 

Und so richtest Du deinen Single Sign-On ein 

Vorbereitung auf AWS Seite 

Wenn AWS Organizations im Einsatz ist, musst Du zuerst prüfen, ob alle Features aktiviert sind.  

Hierzu loggst du dich in den Root AWS Account ein und siehst in den Einstellungen der AWS Organizations unter dem Punkt „Feature set“ nach, ob alle Funktionen aktiviert sind oder lediglich die konsolidierte Fakturierung.  

Falls nicht alle Funktionen aktiviert sind, gibt es hier den entsprechenden Beitrag im AWS Benutzerhandbuch. 

In den Einstellungen kannst du weiter unten auch direkt AWS SSO für die gesamte Organisation und alle verbundenen Accounts aktivieren. 

So konfigurierst Du deinen Service Provider in AWS 

Nun kannst Du mit der Konfiguration von AWS SSO in AWS beginnen. 

AWS Single Sign-On ist kein globaler Service, wie man erwarten würde. Wenn die Region, in der ein Dienst betrieben wird, für dich auschlaggebend ist, muss an der Stelle darauf geachtet werden, dass die richtige Region ausgewählt ist. Es kann pro Organisation nur einmal AWS SSO konfiguriert und die Region später nicht angepasst werden. Ob es den Dienst in deiner Region gibt, kannst du HIER überprüfen.

Nachdem AWS SSO aktiviert ist, kannst Du im ersten Schritt die sogenannte „User Portal URL“ anpassen. Die Einstellungen befinden sich alle im Abschnitt „Settings“.  

Natürlich kann man die vorgegebene URL nutzen, da wir diese in unserem Fall aber auch unter anderem an Kunden kommunizieren, haben wir sie in diesem Beispiel angepasst. 

Als nächstes wird die Wahl des Identitätsproviders getroffen.  

Dafür klickst Du auf den Punkt „Change“ neben der „Identity source“ und wählst „External identity provider“.  

Du kannst nun über den Link „Download metadata file“ eine XML Datei mit allen benötigten Konfigurationsparametern für das AAD herunterladen. 

• AWS SSO Sign-in URL 
• AWS SSO ACS URL 
• AWS SSO issuer URL 

Die einzelnen Werte können natürlich auch manuell übertragen werden. Um die „IdP SAML metadata“ hochladen und mit dem nächsten Schritt beginnen zu können, musst Du erst einmal in das Azure Portal wechseln. 

Erstellung der Enterprise Application in Azure 

Mit der XML Datei kannst Du nun im Azure Portal eine neue „Enterprise Application“ erstellen.  

Hierzu öffnest Du die Verwaltung der „Enterprise Applications“, was am bequemsten über die Suchleiste in der Titelleiste des Azure Portals funktioniert. 

Dort klickst Du jetzt auf „New Application“ und wählst „Non-gallery application“. 

Es gibt zwar eine vorbereitete Applikation in der Galerie, diese ließ sich aber nicht anpassen, um die automatische Provisionierung der Accounts zu konfigurieren. 

Nun wählst Du einen sinnvollen Namen und erstellst die Applikation mit einem Klick auf „Add“. In der Übersicht der neu erstellten Applikation musst Du im nächsten Schritt Single Sign On konfigurieren – „2. Set up single sign on“. 

Anschließend wählst Du SAML aus und lädst über die Schaltfläche „Upload metadata file“ die XML Datei von AWS hoch.  

Das manuelle Ausfüllen der Felder funktioniert an der Stelle aber besser, da sowieso nur drei Felder ausgefüllt werden müssen: 

Azure Portal	AWS
Identifier (Entity ID)	AWS SSO issuer URL
Reply URL (Assertion Consumer Service URL)	AWS SSO ACS URL
Sign on URL (optional)	AWS SSO Sign-in URL

Die Applikation kann in diesem Schritt noch nicht getestet werden! 

Unter Abschnitt 4 lädtst Du dann die „Federation Metadata XML“ herunter, die Du für den nächsten Schritt bei AWS brauchst. 

Außerdem muss die Zuweisung der Benutzerattribute für die SAML Antwort angepasst werden. Die bestehenden Zuweisungen unter „User Attributes & Claims“ müssen erweitert werden und sollten danach wie folgt aussehen: 

Name	Namespace	Quelle	Quellattribut
Unique User Identifier	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	Attribut	user.userprincipalname
Emailaddress	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	Attribut	user.mail
Givenname	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	Attribut	user.givenname
Name	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	Attribut	user.userprincipalname
Surname	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	Attribut	user.surname
Role	https://aws.amazon.com/SAML/Attributes	Attribut	user.assignedroles
RoleSessionName	https://aws.amazon.com/SAML/Attributes	Attribut	user.userprincipalname
SessionDuration	https://aws.amazon.com/SAML/Attributes	Attribut	900

So schließt Du die Konfiguration in AWS ab 

Die XML Datei aus dem Azure Portal wird in AWS hochgeladen. 

Mit einem Klick auf „Next: Review“, sowie der Bestätigung mit „CONFIRM“ im zweiten Schritt, schließt Du die Konfiguration ab. 

Im zweiten Schritt wird darauf hingewiesen, dass alle eventuell bestehenden Benutzer in AWS SSO gelöscht werden.  

Sollte AWS SSO schon vorher konfiguriert gewesen sein, muss Du die Benutzer entsprechend exportieren und im AAD nachpflegen. 

Automatische Benutzerprovisionierung 

Vorbereitung in AWS 

Als nächstes richtest Du die automatische Benutzerprovisionierung ein.  

Da Du ja vorhast, die Benutzer NICHT an mehreren Orten zu pflegen, ist eine automatische Provisionierung mittels System for Cross-domain Identity Management – SCIM ratsam. 

Änderungen werden synchronisiert, neue Benutzer erstellt, gelöschte entfernt und auch Gruppen können übernommen werden. 

Um die Provisionierung einzurichten, klickst Du nun auf „Enable automatic provisioning“. 

Im nachfolgenden Fenster musst Du dir die URL des „SCIM endpoints“ und den „Access token“ notieren. Der Token wird nicht noch einmal angezeigt.  

Wenn alles notiert ist, kannst Du das Fenster mit einem Klick auf „Close“ schließen. 

Provisionierung in Azure aktivieren 

Nun wechselst Du wieder zu Azure.  

In der Übersicht deiner neuen Applikation im Azure Portal, navigierst Du zur Benutzerprovisionierung – „3. Provision User Accounts“ und beginnst die Einrichtung mit einem Klick auf „Get Started“. 

Nachdem der Bereitstellungsmodus auf „Automatic“ gestellt wurde, kannst Du die „SCIM Endpoint URL“ als „Tenant URL“, sowie den „Access Token“ als „Secret Token“ eintragen. 

Die Konfiguration einer Emailadresse als „Notification Email“, sowie das Setzen des Hakens zum Senden von Emails bei Fehlern ist sehr ratsam.

Nach dem Speichern und einem erneuten Öffnen der Einstellungen kann die Benutzerprovisierung noch genauer angepasst werden.  

Unter dem Punkt „Mappings“ kann die Synchronisierung der Gruppen deaktiviert werden oder die zu synchronisierenden Attribute angepasst werden.  

Wir haben die Synchronisierung der Gruppen in unserem Fall nicht deaktiviert, da wir die Gruppen auch in AWS für verschiedene Dinge nutzen.  

Außerdem sollte der „Provisioning Status“ noch auf „On“ gestellt werden. Du möchtest ja schließlich Benutzer in AWS sehen.  

Die Einstellung des „Scopes“, nur zugewiesene Benutzer und Gruppen zu synchronisieren, hat sich ebenfalls als sinnvoll erwiesen. 

Abschließend muss die Applikation natürlich noch Benutzern zugewiesen werden. Das geht am sinnvollsten mit Gruppen. 

Die Zuweisung findest Du unter dem Punkt „Users and groups“. Damit sind die Arbeiten im Azure Portal abgeschlossen und Du kannst mit den Berechtigungen in AWS fortfahren.  

(Auf weitere Einstellungsmöglichkeiten der Enterprise Applikation gehen wir an der Stelle nicht ein.) 

Wenn die Standardeinstellungen der Provisionierung nicht geändert wurden, sollten nach circa 40 Minuten alle Benutzer und Gruppen synchronisiert sein. Es müssen der Applikation natürlich auch Benutzer und Gruppen zugeordnet sein, da nur diese synchronisiert werden. 

Zuweisung der Rechte in AWS 

In den Einstellungen der AWS SSO nimmst Du die Zuordnung von Rechten zu Gruppen oder Benutzern unter dem Punkt „AWS Accounts“ vor. 

Jetzt möchtest Du einer Gruppe von Benutzern Zugriff auf AWS Billing and Cost Management geben. Dazu muss der entsprechende Account markiert und auf die Schaltfläche „Assign users“ geklickt werden. 

Im nächsten Schritt markierst Du den entsprechenden Benutzer oder die Gruppe und bestätigst die Auswahl mit „Next: Permission sets“. Danach erstellst Du das entsprechende „Permission Set“ mittels „Create new permission set“. 

Der Einfachheit halber wählst Du jetzt die vorgefertigte Regel „Billing“ und beendest die Erstellung mittels „Create“. Nun kann das neue „Permission Set“ „Billing“ ausgewählt werden und mit einem Klick auf „Finish“ die Zuweisung beenden. 

Zugang testen 

Jetzt kannst Du den Zugang endlich testen.  

Es gibt zwei verschiedene Wege, um auf das AWS Billing and Cost Management zuzugreifen.  

Am einfachsten ist die Nutzung der Unternehmensanwendung, die Du im Zuge der Einrichtung erstellt hast.  

Da auch wir viele Businessapplikationen mit dem AAD verbunden haben, ist dieser Weg bei uns intern ebenfalls sehr vertraut.  

Unter http://myapps.microsoft.com findest Du nach erfolgreicher Anmeldung nun die eben erstellte Applikation. Über die Applikation gelangst Du dann zur Portalseite von AWS SSO. 

Alternativ kannst Du auch die „User Portal URL“ aus dem ersten Schritt nutzen und direkt auf das Portal gehen. 

Über die entsprechenden Links im Portal, kannst Du dann auf die AWS Management Konsole zugreifen. 

Nutzung über die AWS CLI 

Normalerweise nutzen wir aber die Management Konsole ungern.  

Vielleicht zum Erstellen von Screenshots wie für diesen Blogbeitrag.  

Mit der AWS CLI gab es in der Version 1 nur die Möglichkeit per „Access Key“ und „Secret Access Key“ auf einen AWS Account zuzugreifen. 

Entweder hat man diese temporär als Umgebungsvariablen in der Konsole gesetzt oder doch Benutzer mit entsprechenden Rechten erstellt.  

Mit der Version 2 gibt es aber jetzt die Möglichkeit, sich aus der AWS CLI direkt an AWS SSO anzumelden.  

Die Konfiguration ist einfach mit 

aws configure sso  

erledigt. Du brauchst hier wieder die „User Portal URL“ aus dem ersten Konfigurationsschritt.  

Wenn Du auf Ressourcen in AWS zugreifen will, kannst Du dich mit 

aws sso login --profile profile_name 

anmelden.  

Weiterführende Informationen gibt es im AWS Benutzerhandbuch. 

Noch ein wichtiger Punkt, wenn es um Cloud und On Demand Payment geht:  

Stand heute ist die Nutzung von AWS Single Sign-On kostenlos. Es fallen natürlich Kosten für den Identity Provider an. 

Wir wünschen dir viel Erfolg beim Einrichten deines AWS Single Sign-On mit Azure Active Directory.