Se siden vår «Oversikt over SSO» for å gjøre deg kjent med nøkkelbegrepene som diskuteres i dette dokumentet.
Før du bekrefter domenene dine, er det viktig å vurdere noen ulike spørsmål:
Hvordan vil du klargjøre invitasjoner til nye brukere?
Hvordan vil du håndtere eksisterende forbrukerbrukere (personlig/Plus/Pro)?
Hvordan vil du at brukerinnloggingsflyten skal se ut?
Vi skal se nærmere på hvert av disse spørsmålene for å bidra til at du velger alternativet som passer best til behovene dine.
Invitere nye brukere
Vi tilbyr for øyeblikket fire ulike metoder for å klargjøre invitasjoner til brukere:
Det er verdt å merke seg at vi skiller mellom tilfeller der invitasjons-e-poster sendes aktivt, og tilfeller der en invitasjon knyttes stille til brukerens e-postadresse i backend-systemet vårt.
Invitasjons-e-poster sendes aktivt når:
En ny bruker inviteres for første gang via SCIM.
En bruker inviteres direkte fra ChatGPT eller API-plattformen.
Invitasjoner knyttes stille når:
En SCIM-bruker ble fjernet fra IdP-gruppen din og deretter lagt til på nytt.
Automatisk kontooppretting gjelder.
I sistnevnte tilfelle vil ikke brukerne se invitasjonene i innboksen sin, men de vil likevel bli sendt riktig til det aktuelle arbeidsområdet eller den aktuelle organisasjonen når de prøver å logge inn.
SCIM
SCIM er tilgjengelig både i ChatGPT og på API-plattformen. SCIM gjør det mulig for identitetsleverandører (f.eks. Okta, Entra ID osv.) å utveksle brukeridentitetsdata med OpenAI, slik at klargjøring av invitasjoner (og avvikling av brukerkontoer) automatiseres basert på organisatoriske endringer.
Selv om SCIM også konfigureres via IdP-en din, kan det settes opp uavhengig av SSO. Derfor er ikke domenebekreftelse/SSO krav for SCIM.
Hvis du bestemmer deg for å bruke både SCIM og SSO, er det viktige skillet:
SCIM klargjør bare invitasjoner
SSO håndterer autentisering og brukeroppretting
Vi anser SCIM som den mest robuste og skalerbare løsningen for samlet brukeradministrasjon. Avhengig av den ideelle implementeringen din anbefaler vi vanligvis følgende arkitektur som beste praksis hvis du ruller ut både ChatGPT og API-plattformen:

Med dette oppsettet kan du enkelt administrere både invitasjoner og tilgang (til ChatGPT og API-plattformen) separat. Dette oppsettet har den ekstra fordelen at nødvendige endringer kan utføres sentralt av administrasjonsteamene dine direkte i IdP-en.
Hvis du implementerer SCIM på tvers av flere applikasjoner (f.eks. ChatGPT kontra API-plattformen kontra andre kontoer), bør SCIM-applikasjonene dine være unike. Selv om målgruppen av brukere er identisk, anbefaler vi på det sterkeste at hver SCIM-implementering viser til en unik applikasjon i IdP-en din.
Hvis du ikke oppfyller dette kravet, kan det føre til inkonsistensproblemer som til slutt resulterer i ugyldige medlemskap.
Direkte invitasjoner fra ChatGPT eller API-plattformen
Administratorer kan invitere brukere direkte via e-post fra de respektive ChatGPT- og Platform-sidene «Medlemmer». I ChatGPT støtter denne metoden også masseinvitasjoner via en opplastet CSV:

Selv om dette vanligvis ikke skalerer godt, anbefaler vi ofte å bruke direkte invitasjoner når du kommer i gang i et nytt arbeidsområde eller en ny organisasjon. I motsetning til SCIM er det ingen potensiell forsinkelse før invitasjonene når brukernes innbokser, så det er det mest effektive alternativet for å gi rask tilgang, endre tillatelser og utføre generell testing.
I tillegg kan du alltid aktivere SCIM senere og plassere de eksisterende brukerne dine under SCIM-applikasjonen. Det er derfor ingen grunn til bekymring for at direkte inviterte brukere blir utelatt fra fremtidig automatisering, med mindre det er ønskelig.
Automatisk kontooppretting (AAC)
I motsetning til de andre alternativene er AAC bare tilgjengelig på identitetssiden i ChatGPT og krever at SSO først er aktivert:

Som vist ovenfor sikrer AAC at brukere som registrerer seg eller logger inn med et bekreftet e-postdomene, automatisk legges til i Enterprise-arbeidsområdet ditt. Brukerne mottar ikke en invitasjons-e-post, og prosessen er helt automatisert. Dette har sine fordeler og ulemper.
Hvis retningslinjene dine er å gi åpen tilgang til alle brukere med det bekreftede domenet ditt, er AAC et godt alternativ som unngår ekstraarbeidet med å konfigurere og administrere en SCIM-applikasjon.
AAC er imidlertid ikke ideelt hvis du krever en mer låst, godkjenningsbasert tilnærming til brukertilgang.
⚠️ ADVARSEL ⚠️
Det er viktig å huske at aktivering av AAC i praksis vil tvinge sammenslåing av alle forbrukerbrukere (personlig/Plus/Pro) under domenet ditt inn i Enterprise-arbeidsområdet ditt. Mer om dette finner du nedenfor i delen «Håndtere eksisterende brukere».
Vær oppmerksom på at selv om brukerne ikke er medlemmer av tilgangsgruppen i IdP-en din og ikke får tilgang til arbeidsområdet når SSO håndheves, opptar de fortsatt et sete i Enterprise-kontoen din i dette scenarioet.
Av denne grunn anbefaler vi vanligvis SCIM eller direkte invitasjoner i de fleste tilfeller, i stedet for AAC. Og for å unngå mulige kilder til forvirring anbefaler vi å la AAC være slått av hvis du planlegger å bruke SCIM.
Admin Invites Endpoint for API-plattformen
API-plattformen vår støtter et Invites Endpoint, som lar deg invitere brukere til API-organisasjonen din programmatisk.
Sammenlignet med SCIM er den største fordelen med endpoint at det lar deg angi hvilke prosjekter den inviterte brukeren skal tilhøre:

Dette gir et ekstra nivå av detaljer og kontroll, uten at det kreves manuelt arbeid med individuelle direkte invitasjoner.
Håndtere eksisterende forbrukerbrukere
Vi definerer forbrukerbrukere som brukere med et personlig abonnement, Plus-abonnement eller Pro-abonnement. Det er ofte slik at det finnes eksisterende forbrukerbrukere med det bekreftede domenet ditt som har hatt kontoer før Enterprise-kontrakten din. Siden bekreftelse av domenet ditt og aktivering av SSO kan få konsekvenser nedstrøms for disse forbrukerbrukerne, er det viktig å avgjøre ønsket resultat på forhånd.
Virkning på ChatGPT-forbrukerbrukere
På ChatGPT-siden bestemmes virkningen på forbrukere i stor grad av to faktorer:
Blir de invitert til Enterprise-arbeidsområdet?
Vil du håndheve SSO?
Den resulterende atferden vises nedenfor:
| Ventende invitasjon? | SSO håndhevet? | Resultat |
|---|---|---|
| Ja | Ja | Forbrukerbrukerkontoer blir tvunget til å slås sammen med Enterprise, og brukerne kan bare logge inn med SSO. |
| Ja | Nei | Forbrukerbrukerkontoer blir tvunget til å slås sammen med Enterprise, og brukerne kan autentisere seg med SSO eller sosial innlogging. |
| Nei | Ja | Ingen virkning: Forbrukerbrukere beholder tilgang til sine personlige arbeidsområder via passord eller sosial autentisering. |
| Nei | Nei | Ingen virkning: Forbrukerbrukere beholder tilgang til sine personlige arbeidsområder via passord eller sosial autentisering. |
Hvis målet ditt er å til slutt forhindre alle forbrukerkontoer, kan du kontakte Account Director for å diskutere mulige alternativer.
Kontosammenslåing
Forutsetningene for å utløse en automatisk sammenslåing av forbrukerkontoen til en Enterprise-konto er som følger:
Brukerens domene er bekreftet.
Brukeren har mottatt en invitasjon til Enterprise-arbeidsområdet der domenet er bekreftet.
Merk: Hvis du har aktivert AAC, vil denne betingelsen alltid være oppfylt for alle brukere med det bekreftede domenet ditt.
Når disse betingelsene er oppfylt, skal brukeren se følgende modal neste gang hen logger inn på eller oppdaterer ChatGPT:

Som bildet fremhever, refunderer vi automatisk eventuelle eksisterende Plus- eller Pro-abonnementer før sammenslåingen. Brukere får mulighet til å overføre eksisterende chatlogg og GPT-er, eller eksportere chatloggen via e-post og starte Enterprise-arbeidsområdet som et «blankt ark».
Når forbrukerkontoen er slått sammen, finnes det ingen måte å gjenopprette den på. Hvis brukerne dine valgte alternativet «Overfør eksisterende chatlogg og GPT-er», men ikke så at dette ble gjenspeilet i Enterprise-arbeidsområdet deres, kan du kontakte brukerstøtte.
Virkning på forbrukerbrukere på API-plattformen
Fordi SSO på plattformen fortsatt er domenebasert (i motsetning til ChatGPT, der SSO er knyttet til arbeidsområdet der det er aktivert), blir forbrukerbrukerne dine berørt så snart du bekrefter domenet ditt og aktiverer SSO i en hvilken som helst organisasjon.
Forbrukerbrukerne mister muligheten til å autentisere seg med passord, ettersom vi identifiserer domenetreffet og videresender dem til IdP-en din. Hvis de er medlemmer av IdP-en din, kan de autentisere seg. Alternativt kan de logge inn med et sosialt OAuth-alternativ hvis det er tilgjengelig for dem. Hvis ikke, har du i praksis låst dem ute fra forbrukerkontoene deres.
Se delen Flyt for brukerinnlogging for en mer inngående veiledning til denne arbeidsflyten.
Anbefalte mønstre for identitet og klargjøring
Nå som vi har beskrevet den grunnleggende atferden knyttet til identitetsautentisering og klargjøring av invitasjoner, kan det være nyttig å se gjennom noen av de vanligste implementeringsmønstrene som er tilgjengelige for Enterprise-brukere:

Flyt for brukerinnlogging
Vi har allerede diskutert virkningen av ventende invitasjoner og håndheving av SSO, så denne delen skal bidra til å visualisere den forventede flyten og kontrollene vi utfører når en bruker skriver inn e-postadressen sin for å logge inn.
Innloggingsflyt for ChatGPT
Merk: Dette diagrammet utelater innloggingsforsøk via en sosial metode eller via Tile-URL-en.

Innloggingsflyt for API-plattformen
Merk: Dette diagrammet utelater innloggingsforsøk via en sosial metode eller via Tile-URL-en.

Neste trinn
Nå som du har en idé om den ideelle implementeringen, kan du følge den relevante dokumentasjonen for å aktivere SCIM eller SSO:
