Undvik fallgropar vid integrering av Atlassian Access

Integrera Atlassian Access

Ett av många sätt att få ut mesta möjliga av dina Atlassian-verktyg är att integrera Jiras användarkatalog med organisationens lokala katalog. Det finns många fördelar med att ha en enda ”källa till sanningen” för användare och deras attribut. Oavsett vilken identitetsleverantör du vanligtvis använder hanteras allt via Atlassian Access.

Så fungerar Atlassian-konton

Bland de många fördelarna finns SAML-baserad single sign-on (SSO), automatisk användarprovisionering och krav på tvåfaktorsautentisering (2FA).

Bra att veta: För Bitbucket behöver du Premium för att kunna kräva 2FA. Synkronisering av grupper och användare stöds inte heller, och detsamma gäller Trello. Trello listas ändå eftersom SSO fungerar.

Innan vi går händelserna i förväg behöver vi få systemen att kommunicera med varandra. Det leder oss till vårt första hinder – att göra anspråk på en domän via Atlassian.

Gör anspråk på en domän för att aktivera Atlassian Access

Innan du aktiverar Atlassian Access behöver du göra anspråk på önskad domän. I praktiken innebär det att du berättar för Atlassian att du äger domänen, till exempel ”@företagsnamn.com”, och att du vill hantera tillhörande Atlassian-konton.

Tips: Du behöver tillgång till domänen (webbadress, verifieringsfil eller DNS-post).

Konton kan användas i flera Atlassian-produkter, och ägandet ligger någonstans mellan användarna och Atlassian. Organisationer kan inte göra så mycket här, men genom att göra anspråk på konton kan du hantera och ändra dem, till exempel genom att ange nya attribut för kontona eller göra andra ändringar efter behov.

Nackdelen är att detta bara kan göras av en enda organisation. Du kan inte göra anspråk på samma domän i flera organisationer. Vi ser ofta organisationer som försöker göra anspråk på sin domän, bara för att upptäcka att en systeravdelning redan har gjort det.

I sådana fall rekommenderar vi att du inleder en dialog med Jira-administratörerna i systerorganisationen och Atlassian för att bekräfta att det är rimligt att flytta allt till en och samma organisation, så att du kan hantera din identitetsleverantör från ett och samma ställe.

Atlassian Access faktureras när ett hanterat konto har någon av följande produkter som stöds:

• Jira Software

• Jira Work Management

• Jira Service Management (agenter)

• Confluence

• Bitbucket (ingen licensprovisionering)

• Trello (ingen licensprovisionering)

Det är viktigt att notera att Trello räknas som aktiv användning av Atlassian-produkter även om du använder gratisversionen, vilket kan vara förvirrande.

Som tidigare nämnts stöder både Trello och Bitbucket endast SSO-delen av Access. Du kan därför inte provisionera licenser till användare på samma sätt som för andra produkter.

En organisation kan använda en enda Access-konfiguration även om den har flera webbplatser. Endast en Access-licens används per aktiv Atlassian-användare, oavsett hur många produkter eller webbplatser användaren har.

Bra att veta: Om du har Enterprise-licensnivån för Jira Software fungerar den på ungefär samma sätt, där en licens täcker alla instanser i organisationen.

Nedan visas ett exempel på hur Enterprise- och Trello-licenser kan påverka Atlassian Access.

Här ser vi att 8 000 användare redan har en Enterprise-licens, som inkluderar Access. Det innebär att licenserna för de 2 000 Trello-användare som inte redan har en Enterprise-licens behöver betalas.

Konfigurera och tillämpa SAML single sign-on (SSO)

Vanligtvis skulle nästa steg vara att konfigurera SSO. Om du inte behöver det kan du gå direkt till användarprovisionering, men det är ändå bra att förstå vad det innebär.

Många blandar ihop kravet på att verifiera SSO via Access och sin identitetsleverantör med möjligheten att snabbt logga in via exempelvis Microsoft eller Google, om de redan är inloggade i Jira.

Du har säkert märkt att du även utan Access kan välja att logga in via någon av de ovan nämnda portalerna. Nyckelordet här är ”välja”.

Ett konto utan konfigurerad Atlassian Access – kom ihåg autentiseringsprinciperna – måste inte verifieras via en identitetsleverantör och kan logga in direkt i Jira med kontots e-postadress/användarnamn och lösenord. När SSO har konfigurerats och tillämpats omdirigeras du alltid till din identitetsleverantörs inloggningssida.

Se till att testa detta med ett litet antal användare innan du låser ute alla från systemet. Var också extra försiktig med principer som påverkar administratörskonton, inklusive ditt eget.

Provisionera Atlassian Access-användare på rätt sätt

Atlassian-produkter med Access bör automatiseras via din identitetsleverantör. När du har gjort den inledande konfigurationen kan Access hantera både onboarding och offboarding av användare tillsammans med ditt interna system.

Gruppmedlemskap kan också hanteras på samma sätt, men observera att kapslade grupper plattas ut på Atlassian-sidan. Kontrollera internt vad detta påverkar.

Eftersom användargrupper definierar användning av applikationer och licenser kan du styra licensiering för Jira och Confluence direkt från din identitetsleverantör genom att synkronisera motsvarande grupper. Tänk på att vissa interna systemgrupper i din Atlassian-organisation, till exempel webbplatsadministratörer, inte kan synkroniseras på det här sättet.

Kom ihåg: Det går inte att synkronisera grupper för att ge åtkomst och licenser till Bitbucket/Trello.

Att ta bort användare i Atlassian Access Cloud kan vara tidskrävande, så var försiktig med vilka grupper och användare du lägger till i den katalog du vill synkronisera. Om du synkroniserar för många grupper eller användare rekommenderar vi att du rensar upp med appen BulkOps eller ett alternativ, till exempel REST API.

Tillämpad tvåstegsverifiering med Atlassian Access

När du har konfigurerat Access kan du aktivera 2FA. Det fungerar för Jira och Confluence, men inte för Bitbucket, som tidigare nämnts. Om du redan tillämpar SSO är det dock vanligtvis enklast att göra det på identitetsleverantörsnivå utanför Atlassian. Det fungerar även med Bitbucket eftersom det tillämpas vid inloggning. Det ger en enhetlig inloggningsupplevelse mellan systemen och gör det enklare för användarna att förstå hur de ska autentisera sig.

När du tillämpar SSO har du kontroll över din identitetsleverantör. Där kan du aktivera villkorsstyrd användning, kräva ett lokalt nätverk/IP-intervall med mera.

Även utan Access kan du konfigurera en enda autentiseringsprincip där du kan kräva 2FA, lösenordsstyrka och tid för inaktiva sessioner. Du kan också göra anspråk på domäner och hantera konton, eftersom inget av detta kräver Access.

Attributmappning och din identitetsleverantör

När du mappar attribut bör du se till att värdena i din identitetsleverantör är korrekta och uppdaterade samt att du mappar rätt fält.

Tillgängliga för mappning:

• Visningsnamn

• E-postadress

• Organisation

• Befattning

• Tidszon

• Avdelning

• Föredraget språk

Bra att veta: Visningsnamnet är en kombination av användarens för- och efternamn. Om du uppdaterar detta skrivs attribut över.

En viktig fallgrop gäller en organisation med Atlassian-användare från hela världen. Alla ville inte visa sitt förnamn i Jira, där de vanligtvis använde sitt efternamn eller liknande.

I sådana fall kan du behöva konfigurera flera anslutningar till din identitetsleverantör, var och en med sin egen attributmappning. Detta kräver Atlassian Cloud Enterprise, eftersom du annars bara kan använda en konfiguration för identitetsleverantör. Det kan vara kostsamt, men ger tillgång till nya funktioner och är vanligtvis ett viktigt steg för organisationer som växer globalt.

Kom i gång med Atlassian Access

Det kan kännas överväldigande att konfigurera Access, SSO, användarprovisionering och liknande för första gången. Att klicka på knappen ”claim accounts” när du har verifierat din domän kan kännas som ett stort beslut, men det påverkar dina användare väldigt lite.

Det tar oss vanligtvis en halv dag att konfigurera Atlassian Access, och det är egentligen allt som behövs om du har god förståelse för din identitetsleverantör och hur du vill synkronisera och provisionera användare.

Vi ser att många organisationer kompletterar Access-integrationen med en egen onboardingportal eller plattform. Tanken är att ha en central plats där du kan ge åtkomst till produkter och resurser inom organisationen och automatisera hela processen.

Se till att du har kunskapen, resurserna och tiden innan du ger dig i kast med en sådan uppgift. Genom att förstå organisationens kultur blir det lättare att se hur din portal eller plattform ska utformas och fungera.

Atlassian lägger till nya alternativ och möjligheter varje dag. Det kan vara en liten detalj som gör stor skillnad för din organisation. Kom i gång och var inte rädd för att göra misstag!

Läs vårt blogginlägg om du vill veta mer om Atlassian Access.