Hjelpesenter

Alle samlingerIntegrationsSupported SSO IntegrationsSingle Sign-On (SSO) via OpenID Connect (OIDC)

Single Sign-On (SSO) via OpenID Connect (OIDC)

Denne artikkelen forklarer hvordan du konfigurerer Single Sign-On (SSO) med OpenID Connect (OIDC) ved å koble identitetsleverandøren din til vår plattform.

Single Sign-On (SSO) med OpenID Connect (OIDC) gjør det mulig for organisasjonen deres å autentisere brukere via en sentral identitetsleverandør (IdP), mens Tagd fungerer som avhengig part (relying party). Identitetsleverandøren deres har ansvaret for autentiseringen, inkludert flerfaktorautentisering og betinget tilgang, og Tagd ser aldri noe passord.

Forutsetning: En identitetsleverandør som støtter OpenID Connect med authorization code-flyten og et publisert discovery-dokument (for eksempel Microsoft Entra ID (Azure AD), Okta eller Google Workspace).

Viktig: Tagd autentiserer mot token-endepunktet deres med client_secret_post. client_secret_basic, som er standard i de fleste identitetsleverandører, støttes ikke. Hvis identitetsleverandøren deres ikke kan bruke client_secret_post, bruk SAML 2.0 i stedet.

Trinn 1: Samle inn opplysninger om avhengig part

Følgende opplysninger trengs når dere konfigurerer identitetsleverandøren deres:

Parameter

Verdi

Sign-in redirect URI

https://tagd-prod-platform.auth.eu-north-1.amazoncognito.com/oauth2/idpresponse

Grant type

Authorization code

Scopes

openid email profile

Klientautentisering

client_secret_post

Signering av ID-token

RS256, ES256 eller HS256, med en kid publisert i JWKS-endepunktet deres

Trinn 2: Konfigurer identitetsleverandøren (IdP)

Opprett en applikasjon i identitetsleverandøren deres:

  1. Opprett en ny OpenID Connect-applikasjon av typen Web Application, en konfidensiell klient med en klienthemmelighet (client secret). En applikasjon av typen single-page eller native/mobil fungerer ikke

  2. Sett grant type til Authorization Code og legg inn sign-in redirect URI fra tabellen over

  3. Sett klientautentisering til client_secret_post

  4. Konfigurer claims som skal sendes med i ID-tokenet

    1. email (Obligatorisk, gis av scopet email)

    2. given_name (fornavn, gis av scopet profile)

    3. family_name (etternavn, gis av scopet profile)

    4. groups (Obligatorisk, minst én gruppe kreves). Hvis groups står under scopes_supported i discovery-dokumentet deres (https://<deres-issuer>/.well-known/openid-configuration), trenger ingenting å konfigureres. Ellers legger dere til et groups-claim i applikasjonen. Claimet må sendes i ID-tokenet eller i userinfo-svaret, ikke bare i access-tokenet. Gruppenavn kan kun inneholde bokstaver, sifre og . - * _ (for eksempel Acme-Legal, ikke Acme Legal)

  5. Tildel testbrukere til både applikasjonen og gruppen. En bruker som ikke er tildelt, kan ikke logge inn

  6. Velg en utloggings-URL (Obligatorisk). Enten identitetsleverandørens utloggingsadresse, som også logger brukeren ut av identitetsleverandøren, eller en landingsside, for eksempel intranettet deres. Adressen må begynne med https://. Legg den også til blant applikasjonens sign-out redirect URIs

  7. Velg ønsket påloggingsalias, for eksempel "firmaet". Påloggingslenken blir da https://prod.tagd.ai/api/v1/auth/login?org=firmaet. Bruk kun små bokstaver (a–z), sifre og bindestrek

Trinn 3: Send SSO-opplysninger til Tagd

Send følgende opplysninger til [email protected]

  • Issuer URL, nøyaktig slik den står i discovery-dokumentet (https://, uten avsluttende skråstrek)

  • Client ID

  • Client secret, sendt via en sikker kanal, for eksempel en delingslenke fra en passordbehandler. Ikke i selve e-posten eller i en chat

  • Bekreftelse på at klientautentiseringen er satt til client_secret_post

  • Utloggings-URL

  • Ønsket påloggingsalias

  • Testbrukerens e-postadresse

  • Navn på gruppene som skal synkroniseres, stavet nøyaktig som i groups-claimet

  • Claim-navn, hvis de avviker fra email, given_name, family_name og groups

  • Valgfritt: en gruppe som skal gi rollen Administrator i Tagd

  • Navn og e-postadresse til en teknisk kontaktperson for produksjonssettingen

Send aldri brukerpassord, private nøkler eller API-nøkler for identitetsleverandøren. Når opplysningene er mottatt, konfigurerer teamet vårt OpenID Connect-autentiseringen for organisasjonen deres.

Trinn 4: Test SSO-oppsettet

Før SSO rulles ut til alle brukere, testes oppsettet sammen med noen fra teamet vårt.

  • Åpne påloggingslenken og kontroller at den sender dere rett til identitetsleverandøren

  • Utfør en testpålogging med en brukerkonto i identitetsleverandøren, inkludert eventuelt flerfaktortrinn

  • Kontroller at brukerens navn og e-postadresse vises riktig i Tagd

  • Kontroller at brukeren legges til i riktig gruppe i Tagd og har forventet rolle

  • Kontroller at utlogging avslutter økten i Tagd og sender brukeren til utloggings-URL-en

  • Kontroller at en bruker som ikke er tildelt applikasjonen, ikke kan logge inn

Vi anbefaler sterkt å teste med en begrenset gruppe brukere først. Rapporter eventuelle problemer til [email protected]

Trinn 5: PRODUKSJONSSETTING

Koordiner produksjonssettingen av SSO-integrasjonen sammen med kontaktpersonen deres hos oss:

  • Bestem dato for produksjonssetting, og sørg for at den tekniske kontaktpersonen er tilgjengelig underveis.

  • Tildel brukere til Tagd-applikasjonen i identitetsleverandøren. Når en bruker logger inn via SSO for første gang, opprettes kontoen automatisk eller kobles til en eksisterende konto basert på e-postadressen. Gruppemedlemskap fra identitetsleverandøren legger brukeren til i tilsvarende grupper i Tagd.

  • Informer brukerne om endringen og del påloggingslenken. Brukerne logger inn med sin vanlige jobbpålogging og trenger ikke et eget passord til Tagd.

Var dette svaret til hjelp?
😞
😐
😁