Wer externe Nutzer – Partner, Dienstleister, Berater – in seine Atlassian-Cloud-Umgebung einbinden will, kennt das Problem: Accounts anlegen, Gruppen zuweisen, Berechtigungen konfigurieren, Einladungen verschicken. Alles manuell, alles fehleranfällig, alles langsam.
Wir haben für einen Kunden aus dem öffentlichen Sektor einen Prototyp gebaut, der diesen Prozess vollständig automatisiert – von der Anfrage bis zum ersten Login. Die Basis: Microsoft Entra ID (ehemals Azure AD) als Identity Provider, SCIM-Provisioning für die Synchronisation und Jira Service Management als Self-Service-Portal.
The Problem: Too Many Hands in the Process
Das typische Onboarding eines externen Nutzers sieht in vielen Organisationen so aus:
- Manager schreibt eine E-Mail oder ein Ticket
- Admin legt den Account manuell an
- Admin weist Gruppen und Berechtigungen zu
- Admin verschickt eine Einladung
- Nutzer wartet, Admin wartet, alle warten
Jeder dieser Schritte ist eine potenzielle Fehlerquelle – und ein Zeitfresser. Bei Organisationen mit hunderten externen Nutzern skaliert das nicht.
The Solution: Self-Service + Automation
Der neue Prozess reduziert die Beteiligung auf zwei Personen: den Manager, der den Zugang anfordert, und den Nutzer, der sich einloggt. Dazwischen passiert alles automatisch.
1. Manager erstellt JSM-Request
Der zuständige Manager öffnet im Jira Service Management Portal eine Anfrage: „Neuen externen Nutzer einrichten". Einzige Eingabe: die E-Mail-Adresse des neuen Nutzers.
2. Automation ĂĽbernimmt
Eine Custom-Applikation – im Kundencluster gehostet – greift die JSM-Anfrage ab und führt zwei Aktionen aus:
- Einladung als Entra ID Guest User: Der Nutzer wird automatisch als Gast in den Entra-ID-Tenant eingeladen.
- Gruppenzuweisung: Der Nutzer wird den passenden Sicherheitsgruppen zugeordnet – z.B. einer Gruppe, die Zugang zu Confluence und bestimmten Spaces gewährt.
3. SCIM synchronisiert zu Atlassian
Microsoft Entra ID ist per SCIM (System for Cross-domain Identity Management) mit der Atlassian-Site verbunden. Nutzer und Gruppen werden automatisch synchronisiert – der neue Guest User taucht in Atlassian auf, inklusive aller Gruppenmitgliedschaften.
4. Custom-Einladung wird versandt
Statt der generischen Microsoft- oder Atlassian-Einladung erhält der Nutzer eine maßgeschneiderte Nachricht mit einem direkten Link zur Atlassian-Umgebung.
5. Nutzer loggt sich ein
Der Nutzer klickt den Link, authentifiziert sich über seinen bestehenden Identity Provider (z.B. Google), durchläuft eine zweite Authentifizierung gegen den Entra-ID-Tenant – und ist drin. Confluence-Zugang, Space-Berechtigungen, alles da.
What Happens Under the Hood
FĂĽr die technische Umsetzung sind drei Komponenten in Entra ID erforderlich:
App Registration
Ein logisches Objekt in Entra ID, das der Automation die nötigen API-Berechtigungen gibt: Guest User einladen, Gruppen lesen und zuweisen, Nutzerdaten abrufen. Die Berechtigungen laufen auf Application-Ebene – kein interaktiver Login nötig.
Enterprise Application
Die BrĂĽcke zwischen Entra ID und Atlassian Cloud. Zwei Funktionen:
- SCIM Provisioning: Automatische Synchronisation von Nutzern und Gruppen von Entra ID nach Atlassian.
- Identity Provider: Entra ID fungiert als zweiter Authentifizierungsfaktor fĂĽr den Zugang zur Atlassian-Site.
Sicherheitsgruppen
Gruppen werden in Entra ID angelegt, der Enterprise Application zugewiesen und per SCIM nach Atlassian synchronisiert. In Atlassian erhalten sie dann die passenden Produkt- und Space-Berechtigungen.
Group Management: That Can Be Automated Too
Ein häufiger Einwand: „Schön, dass der User automatisch in eine Gruppe kommt – aber die Gruppe muss ich ja trotzdem manuell anlegen."
Stimmt – deshalb ist auch das automatisierbar. Über einen weiteren JSM-Request-Typ („Neue Gruppe erstellen") kann ein Manager eine Entra-ID-Gruppe anlegen lassen, ohne den IT-Admin zu bemühen. Die Automation erstellt die Gruppe, sie wird per SCIM synchronisiert und steht in Atlassian zur Verfügung.
Langfristig lassen sich diese Gruppen in Jira Assets als Profile organisieren – ein Nutzer bekommt dann nicht einzelne Gruppen, sondern ein Rollenprofil zugewiesen, das alle nötigen Berechtigungen bündelt.
Known Limitations
Transparenz gehört dazu – es gibt drei Einschränkungen, die man kennen sollte:
40-Minute Sync Interval
Entra ID synchronisiert Nutzer und Gruppen per SCIM in einem festen Intervall von 40 Minuten. Dieser Wert ist nicht konfigurierbar – er ist von Microsoft fix vorgegeben. Für Entwicklung und Tests gibt es „Provision on Demand", das aber auf maximal 5 Nutzer gleichzeitig begrenzt ist. In Produktion heißt es: Bis zu 40 Minuten warten, bis der neue Nutzer in Atlassian erscheint.
No Nested Groups
Nested Groups – also Gruppen innerhalb von Gruppen – werden von Microsoft für die SCIM-Synchronisation nicht unterstützt. Gruppenstrukturen müssen flach bleiben.
Group Renaming Doesn't Work
Wird eine Gruppe in Entra ID umbenannt, wird die Änderung nicht nach Atlassian übertragen. Das ist eine Atlassian-seitige Limitierung – Gruppen behalten in Atlassian ihren ursprünglichen Namen.
Why This Matters
Für Organisationen mit hohem externem Nutzeraufkommen – öffentliche Verwaltung, Beratungsunternehmen, Konzerne mit vielen Partnern – ist automatisiertes Onboarding kein Nice-to-have. Es ist die Voraussetzung dafür, dass Collaboration-Tools wie Confluence tatsächlich genutzt werden, statt an der IT-Abteilung als Bottleneck zu scheitern.
Die Kombination aus Jira Service Management als Self-Service-Frontend, Microsoft Entra ID als Identity Layer und SCIM als Synchronisationsprotokoll bietet eine solide, standardbasierte Grundlage – ohne exotische Abhängigkeiten.
Der beste Onboarding-Prozess ist der, den niemand bemerkt – weil er einfach funktioniert.
Identity Management for Atlassian Cloud?
At XALT, we integrate Atlassian Cloud with enterprise identity solutions – from Entra ID to Keycloak to SAML/SSO.
Schedule a Conversation →