Gluu fungerer med jeres eksisterende identitetsudbyder fra dag ét, uden at der kræves opsætning. Denne vejledning forklarer, hvordan I strammer adgangskontrollen, forbinder Microsoft Azure AD eller Google Workspace, administrerer tilladelser og holder brugerdata synkroniseret.
Før I går i gang #
- Plan: Grundlæggende login med Microsoft eller Google fungerer i alle planer. Panelet Godkendelse, som bruges til at begrænse loginmetoder og låse en tenant, kræver planen Advanced. Automatisk provisionering af AD-grupper og fulde tilladelsesgrupper kræver desuden tilføjelsen Enterprise Security.
- Rolle: I skal have tilladelsen Administrer konto for at åbne panelet Godkendelse og konfigurere SSO.
- Opsætning: Hav jeres Azure AD Tenant ID eller jeres Google Workspace-domæne klar, før I begynder at begrænse login.
Hvad der virker fra start #
Hver Gluu-konto leveres med fire loginmuligheder aktiveret som standard. Brugere kan logge ind med e-mail og en engangskode, e-mail og adgangskode, Microsoft-konto eller Google-konto, alt sammen i planen Core, uden at der kræves konfiguration.
Hvorfor så overhovedet konfigurere SSO? Fordi den reelle værdi kommer, når I begrænser adgangen. Når I låser brugere til Microsoft- eller Google-login, arver Gluu automatisk jeres identitetsudbyders MFA, betinget adgang og offboardingregler. Jeres IT-team bevarer kontrollen uden at røre ved Gluu-indstillingerne.
Begrænsning af, hvem der kan logge ind #
Plankrav: Panelet Godkendelse, der beskrives i dette afsnit, er kun tilgængeligt i planen Advanced.
Panelet Godkendelse i jeres kontoindstillinger giver jer tre afkrydsningsfelter: Gluu login/adgangskode, Google-godkendelse og Microsoft-godkendelse. Fjern markeringen ved en metode for at deaktivere den. De fleste sikkerhedsbevidste kunder fjerner markeringen ved “Gluu login / adgangskode” helt, så alle brugere skal godkendes via Microsoft eller Google.
Det betyder, at jeres identitetsudbyders MFA og politikker for betinget adgang gælder automatisk. I styrer adgangen via jeres egen sikkerhedsopsætning, og Gluu respekterer blot den beslutning, jeres identitetsudbyder returnerer.
Lås Microsoft-login til jeres Azure AD-tenant #
Som standard kan enhver Microsoft-konto logge ind. For at begrænse login til jeres egen organisation skal I indtaste jeres Azure AD Tenant ID i panelet Godkendelse. Dette ene trin låser også op for Office 365- og SharePoint-integrationer og aktiverer valgfri auto-provisionering for nye brugere.
Adgangsstyring med Azure AD App Roles #
Har I brug for et ekstra lag kontrol? Gluu understøtter op til tre afkrydsningsfelter for App Role, som hver især mappes til en rolle, I definerer på Gluu Enterprise App i jeres Azure AD-tenant. Markér mere end én, og de kombineres med OG: En bruger skal have alle markerede roller for at kunne logge ind. Det gør det muligt at kræve kombineret medlemskab som “Gluu Users” OG “Finance Department”.
Bemærk: Klargøringsrettigheder baseret på Azure AD-grupper (automatisk tildeling af Gluus tilladelsesgrupper ud fra AD-gruppemedlemskab) kræver tilføjelsen Enterprise Security ud over planen Advanced. Grundlæggende begrænsning af Tenant ID og App Role-gating kræver ikke denne tilføjelse.
Tilsidesættelser af loginudbyder pr. bruger #
Har I en konto med både interne medarbejdere og eksterne partnere? Panelet Custom Authentication Providers gør det muligt at fastlåse en bestemt loginudbyder til enkelte brugere. Interne medarbejdere logger ind via Microsoft; eksterne konsulenter via Google. Gluu understøtter også Okta for organisationer, der bruger det som standard. Kontakt Customer Success for at aktivere det.
Forbindelse til Microsoft Azure Active Directory #
Gluu er tæt integreret med Microsoft-økosystemet. Når en bruger klikker på “Log ind med Microsoft”, viderestiller Gluu dem til Microsofts loginside. Når Microsoft har bekræftet deres identitet, inklusive eventuel MFA, som jeres tenant kræver, stoler Gluu på det returnerede token og logger dem ind.
Vigtigst af alt: Der kræves ingen separat Gluu-adgangskode. Brugerens eksisterende virksomhedslogin klarer det.
Valgfrit: registrering i begrænset tenant #
Nogle IT-teams foretrækker at registrere Gluu som en Enterprise Application i deres egen Azure AD-tenant. Det giver direkte kontrol over samtykke, politikker for betinget adgang og app-roller. Processen omfatter registrering af appen i Azure Portal, konfiguration af redirect URI, tildeling af User.Read-tilladelser samt deling af Tenant ID og Client ID med Gluus Customer Success-team.
Gluu understøtter også SAML, som er tilgængeligt efter anmodning for organisationer, der har brug for det ved siden af OIDC.
Forbindelse til Google Workspace #
For organisationer på Google Workspace er forløbet det samme som med Microsoft. Brugere klikker på “Log ind med Google”, godkender via deres eksisterende virksomhedskonto, og Gluu accepterer det verificerede token. Ingen forudgående konfiguration er nødvendig.
Vil I forhindre personlige Google-konti i at logge ind? Kontakt Customer Success med jeres verificerede domæne. Gluu kan begrænse adgangen til medarbejdere med en @yourcompany.com-konto. Det er et anbefalet trin for enhver organisation, der bruger Google Workspace som standard.
Styring af tilladelser i Gluu #
Loginbegrænsning og tilladelser i Gluu er to separate lag. Jeres identitetsudbyder styrer hvem der kommer ind ad døren. Gluus tilladelsesgrupper styrer hvad disse brugere kan se og gøre, når de først er inde.
Gluu tilbyder to komplementære adgangsmodeller. Procesbaseret adgang giver brugere eller grupper adgang til kun specifikke processer. Det er ideelt for procesansvarlige. Rollebaserede tilladelsesgrupper giver finmasket kontrol på tværs af hele platformen for alle brugertyper fra Admin til Read-Only Viewer.
Bemærk: Rollebaserede tilladelsesgrupper kræver tilføjelsen Enterprise Security. De er ikke inkluderet i nogen basisplan. Læs mere om tilladelsesgrupper.
Da tilladelsesgrupper tildeles i Gluu af en administrator (eller samlet via REST API), synkroniseres de ikke løbende fra Azure AD eller Google. Anbefalet praksis er at bruge Azure AD App Role-gating som en første adgangsbarriere og derefter bruge Gluus tilladelsesgrupper til at fastsætte det rette adgangsniveau, når brugerne er inde.
Hvordan brugere oprettes #
Som standard skal en bruger eksistere i Gluu, før vedkommende kan logge ind. Der er tre standardmåder at oprette brugere på: en administrator inviterer dem én ad gangen (planen Core og op), en masseimport fra Gluus brugerflade (planen Essential og op) eller en Customer Success-masseimport ved hjælp af en struktureret dataskabelon, som er den hurtigste løsning for store organisationer.
Når Azure AD Tenant ID er konfigureret, kan Gluu også automatisk oprette en brugerpost ved første Microsoft-login. Navn og e-mail hentes fra Microsoft-profilen. Kombinér dette med App Role-gating for at begrænse auto-oprettelse til en bestemt gruppe: For eksempel auto-provisioneres kun medlemmer af AD-gruppen “Gluu Users”.
Hvordan offboardede brugere blokeres #
Offboarding håndteres på identitetsudbyderniveau. Når en medarbejder fratræder, deaktiverer eller sletter jeres IT-team vedkommendes konto i Azure AD eller Google Workspace. Fra det øjeblik er vedkommendes godkendelsestoken ikke længere gyldigt, og Gluu afviser automatisk ethvert loginforsøg. Der kræves ingen handling i Gluu.
Dette er den centrale sikkerhedsfordel ved SSO frem for separate legitimationsoplysninger. Én offboardinghandling i jeres HR- eller IT-system forplanter sig straks til alle tilknyttede applikationer. Gluu-administratorer kan også deaktivere brugere manuelt, og når en bruger slettes fra Gluu-kontoen, anonymiseres vedkommendes persondata i overensstemmelse med GDPR.
Import og vedligeholdelse af brugerdata via API’et #
Gluu stiller et åbent REST API til rådighed til programmatisk administration af brugere og profilfelter. Det er særligt nyttigt ved den indledende udrulning og til løbende at holde Gluu synkroniseret med jeres HR-system.
FAQ: Guide til SSO-konfiguration #
For de fleste opsætninger, som indtastning af et Tenant ID eller fravalg af loginmetoder, er svaret nej. En administrator med adgang til Kontoindstillinger kan gøre dette selv. For mere avancerede konfigurationer som begrænset tenant-registrering, SAML-opsætning eller Okta-integration skal I kontakte Gluu Customer Success for at færdiggøre processen.
Hvis I har deaktiveret Gluu-adgangskodelogin helt og udelukkende er afhængig af Microsoft- eller Google-godkendelse, kan brugerne ikke logge ind under et nedbrud hos identitetsudbyderen. Hvis forretningskontinuitet kræver reserveadgang, bør I overveje at lade Gluu-loginmetoden være aktiveret for et lille antal administratorer.
Slettede brugere kan ikke logge ind og vises ikke længere i brugervælgere, men deres historiske kommentarer, redigeringer og procesattributioner bevares som en del af jeres organisations vidensgrundlag. Personlige profiloplysninger anonymiseres i overensstemmelse med GDPR.
Ja. Tilsidesættelse af loginudbyder pr. bruger gør det muligt at tildele en anden loginmetode til enkelte brugere. Eksterne partnere kan logge ind med Google eller en Gluu-adgangskode, mens jeres interne medarbejdere bruger Microsoft. Alt sammen foregår i den samme konto.
REST API’et kræver tilføjelsen Integrationer og API. Det er ikke inkluderet i nogen basisplan (Core, Essential eller Advanced). Kontakt Customer Success for at drøfte aktivering for jeres konto.
I Azure-portalen skal I gå til Azure Active Directory → Oversigt. Jeres Tenant ID vises under Grundlæggende oplysninger. Kopiér det, og indsæt det i Godkendelsespanelet i jeres Gluu-kontoindstillinger.
