Fallstricke bei der Integration von Atlassian Access vermeiden

Atlassian Access integrieren

Eine von vielen Möglichkeiten, das Beste aus euren Atlassian-Tools herauszuholen, ist die Integration eures Jira-Benutzerverzeichnisses mit eurem lokalen Organisationsverzeichnis. Eine zentrale „Single Source of Truth“ für eure Benutzer und deren Attribute bietet viele Vorteile. Unabhängig davon, welchen Identity Provider ihr normalerweise nutzt, wird alles über Atlassian Access verwaltet.

So funktionieren Atlassian-Konten

Zu den vielen Vorteilen gehören SAML Single Sign-on (SSO), die automatische Benutzerbereitstellung und die Durchsetzung der Zwei-Faktor-Authentifizierung (2FA).

Gut zu wissen: Für Bitbucket benötigt ihr Premium, um 2FA durchzusetzen. Auch die Synchronisierung von Gruppen und Benutzern wird nicht unterstützt. Dasselbe gilt für Trello, das dennoch aufgeführt ist, weil SSO funktioniert.

Bevor wir vorgreifen, müssen die Systeme zunächst miteinander kommunizieren. Damit kommen wir zum ersten Hindernis: eine Domain über Atlassian beanspruchen.

Eine Domain beanspruchen, um Atlassian Access zu aktivieren

Bevor ihr Atlassian Access aktiviert, müsst ihr die gewünschte Domain beanspruchen. Im Wesentlichen teilt ihr Atlassian damit mit, dass euch die Domain gehört, zum Beispiel „@firmenname.com“, und dass ihr die zugehörigen Atlassian-Konten verwalten möchtet.

Tipp: Ihr benötigt Zugriff auf die Domain (Web-URL, Verifizierungsdatei oder DNS-Eintrag).

Konten können in mehreren Atlassian-Produkten verwendet werden, und die Eigentümerschaft liegt irgendwo zwischen Benutzern und Atlassian. Organisationen können hier nicht viel beeinflussen. Durch das Beanspruchen von Konten könnt ihr sie jedoch verwalten und anpassen, indem ihr beispielsweise neue Attribute festlegt oder bei Bedarf andere Änderungen vornehmt.

Der Nachteil ist, dass dies nur durch eine einzige Organisation erfolgen kann. Dieselbe Domain kann nicht von mehreren Organisationen beansprucht werden. Häufig erleben wir, dass Organisationen ihre Domain beanspruchen möchten und dann feststellen, dass eine Schwesterabteilung dies bereits getan hat.

In solchen Fällen empfehlen wir, den Austausch mit den Jira-Administratoren eurer Schwesterorganisation und Atlassian zu suchen. So könnt ihr klären, ob es sinnvoll ist, alles in einer einzigen Organisation zusammenzuführen, damit ihr euren Identity Provider zentral verwalten könnt.

Atlassian Access wird abgerechnet, wenn ein verwaltetes Konto eines der folgenden unterstützten Produkte nutzt:

• Jira Software

• Jira Work Management

• Jira Service Management (Agents)

• Confluence

• Bitbucket (keine Lizenzbereitstellung)

• Trello (keine Lizenzbereitstellung)

Wichtig: Trello gilt als aktive Nutzung von Atlassian-Produkten, selbst wenn ihr die kostenlose Version verwendet. Das kann verwirrend sein.

Wie bereits erwähnt, unterstützen Trello und Bitbucket nur den SSO-Teil von Access. Ihr könnt Benutzern daher keine Lizenzen bereitstellen, wie es bei anderen Produkten möglich ist.

Eine Organisation kann ein einziges Access-Setup nutzen, auch wenn sie mehrere Sites hat. Pro aktivem Atlassian-Benutzer wird nur eine Access-Lizenz verbraucht – unabhängig davon, wie viele Produkte oder Sites er nutzt.

Gut zu wissen: Wenn ihr für Jira Software die Enterprise-Lizenzstufe nutzt, funktioniert es ähnlich: Eine Lizenz deckt alle Instanzen in der Organisation ab.

Nachfolgend seht ihr ein Beispiel dafür, wie sich Enterprise- und Trello-Lizenzen auf Atlassian Access auswirken können.

Hier sehen wir, dass 8.000 Benutzer bereits über eine Enterprise-Lizenz verfügen, die Access einschließt. Daher müssen die Lizenzen für die 2.000 Trello-Benutzer bezahlt werden, die noch keine Enterprise-Lizenz haben.

SAML Single Sign-on (SSO) einrichten und durchsetzen

In der Regel wäre der nächste Schritt, SSO einzurichten. Wenn ihr das nicht benötigt, könnt ihr direkt mit der Nutzerbereitstellung fortfahren. Dennoch ist es sinnvoll zu verstehen, was das bedeutet.

Viele verwechseln die Durchsetzung der SSO-Verifizierung über Access und ihren Identity Provider mit der Möglichkeit, sich beispielsweise schnell über Microsoft oder Google anzumelden, wenn sie bereits bei Jira angemeldet sind.

Wahrscheinlich ist euch aufgefallen, dass ihr auch ohne Access die Möglichkeit habt, euch über eines der oben genannten Portale anzumelden. Das entscheidende Wort lautet hier: „Möglichkeit“.

Ein Account ohne konfiguriertes Atlassian Access – denkt an die Authentifizierungsrichtlinien – muss sich nicht über einen Identity Provider verifizieren und kann sich mit E-Mail-Adresse bzw. Benutzername und Passwort direkt bei Jira anmelden. Sobald SSO eingerichtet und durchgesetzt ist, werdet ihr immer auf die Anmeldeseite eures Identity Providers weitergeleitet.

Testet dies unbedingt zunächst mit einer kleinen Anzahl von Nutzern, bevor ihr alle aus dem System aussperrt. Seid außerdem besonders vorsichtig mit Richtlinien, die Admin-Accounts sowie eure eigenen Accounts betreffen.

Atlassian-Access-Nutzer richtig bereitstellen

Atlassian-Produkte mit Access sollten über euren Identity Provider automatisiert werden. Nach der Erstkonfiguration kann Access gemeinsam mit eurem internen System sowohl das Onboarding als auch das Offboarding von Nutzern übernehmen.

Auch Gruppenmitgliedschaften lassen sich auf diese Weise verwalten. Beachtet jedoch, dass verschachtelte Gruppen auf Atlassian-Seite aufgelöst werden. Klärt intern, welche Auswirkungen das hat.

Da Nutzergruppen die Nutzung von Anwendungen und Lizenzen festlegen, könnt ihr die Lizenzierung für Jira und Confluence direkt über euren Identity Provider steuern, indem ihr einfach die entsprechenden Gruppen synchronisiert. Bedenkt, dass einige Gruppen eures internen Systems in eurer Atlassian-Organisation, etwa Site-Admins, nicht auf diese Weise synchronisiert werden können.

Denkt daran: Eine Gruppensynchronisierung, die Zugriff und Lizenzen für Bitbucket/Trello bereitstellt, ist nicht möglich.

Das Löschen von Nutzern in Atlassian Access Cloud kann zeitaufwendig sein. Achtet daher genau darauf, welche Gruppen und Nutzer ihr zum Verzeichnis hinzufügt, das ihr synchronisieren möchtet. Wenn ihr zu viele Gruppen oder Nutzer synchronisiert, empfehlen wir, diese mit der App BulkOps oder einer Alternative wie der REST API zu bereinigen.

Erzwungene Zwei-Faktor-Authentifizierung mit Atlassian Access

Nach der Einrichtung von Access könnt ihr 2FA aktivieren. Das funktioniert für Jira und Confluence, wie bereits erwähnt jedoch nicht für Bitbucket. Wenn ihr SSO bereits durchsetzt, ist es in der Regel am einfachsten, dies auf Ebene des Identity Providers außerhalb von Atlassian zu tun. Das funktioniert auch mit Bitbucket, da die Durchsetzung beim Login erfolgt. So bleibt das Anmeldeerlebnis über alle Systeme hinweg konsistent und Nutzer können leichter nachvollziehen, wie sie sich authentifizieren.

Wenn ihr SSO durchsetzt, habt ihr die Kontrolle über euren Identity Provider. Dort könnt ihr bedingte Zugriffsrichtlinien aktivieren, ein lokales Netzwerk bzw. einen IP-Bereich erzwingen und mehr.

Auch ohne Access könnt ihr eine einzelne Authentifizierungsrichtlinie einrichten, mit der ihr 2FA, die Passwortstärke und die Dauer inaktiver Sitzungen erzwingen könnt. Außerdem könnt ihr Domains beanspruchen und Accounts verwalten, da hierfür kein Access erforderlich ist.

Attributzuordnung und euer Identity Provider

Stellt beim Zuordnen von Attributen sicher, dass die Werte in eurem Identity Provider korrekt und aktuell sind und ihr die richtigen Felder zuordnet.

Folgende Attribute können zugeordnet werden:

• Anzeigename

• E-Mail-Adresse

• Organisation

• Jobtitel

• Zeitzone

• Abteilung

• Bevorzugte Sprache

Gut zu wissen: Der Anzeigename setzt sich aus Vor- und Nachnamen des Benutzers zusammen. Wenn ihr ihn aktualisiert, werden Attribute überschrieben.

Ein bemerkenswerter Fallstrick betrifft eine Organisation mit Atlassian-Benutzern aus aller Welt. Nicht alle wollten in Jira ihren Vornamen anzeigen, wenn sie normalerweise ihren Familiennamen oder Ähnliches verwendeten.

Unter solchen Umständen müsst ihr möglicherweise mehrere Verbindungen mit eurem Identity Provider einrichten, jeweils mit eigenem Attribut-Mapping. Dafür benötigt ihr Atlassian Cloud Enterprise, da ihr ansonsten nur eine einzige Konfiguration für den Identity Provider verwenden könnt. Das kann sehr kostspielig sein, bietet aber neue Funktionen und ist für Organisationen, die global wachsen, meist ein wichtiger Schritt.

Erste Schritte mit Atlassian Access

Access, SSO, die Benutzerbereitstellung usw. zum ersten Mal einzurichten, kann herausfordernd sein. Nachdem ihr eure Domain verifiziert habt, kann ein Klick auf die Schaltfläche „Konten beanspruchen“ wie eine weitreichende Entscheidung wirken, hat aber nur geringe Auswirkungen auf eure Benutzer.

Die Konfiguration von Atlassian Access dauert bei uns in der Regel einen halben Tag. Mehr braucht ihr auch nicht, wenn ihr euren Identity Provider und die gewünschte Synchronisierung bzw. Bereitstellung von Benutzern richtig versteht.

Wir sehen viele Organisationen, die die Access-Integration mit einem eigenen Onboarding-Portal oder einer Plattform erweitern. Ziel ist es, einen zentralen Ort zu schaffen, an dem ihr Zugriff auf Produkte und Elemente innerhalb eurer Organisation gewähren und den gesamten Prozess automatisieren könnt.

Stellt sicher, dass ihr über das nötige Wissen, die Ressourcen und die Zeit verfügt, bevor ihr eine solche Aufgabe angeht. Wenn ihr die Kultur eurer Organisation versteht, könnt ihr besser erkennen, wie euer Portal bzw. eure Plattform aussehen und funktionieren sollte.

Atlassian fügt täglich neue Optionen und Möglichkeiten hinzu. Vielleicht ist es eine Kleinigkeit, die für eure Organisation den entscheidenden Unterschied macht. Legt los und habt keine Angst vor Fehlern!

Mehr über Atlassian Access erfahrt ihr in unserem Blogbeitrag.