Se gjennom siden vår «SSO Overview» for å gjøre deg kjent med nøkkelbegrepene som diskuteres i dette dokumentet.
Før du verifiserer 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 ønsker du at innloggingsflyten for brukere 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 tiden fire ulike metoder for å klargjøre invitasjoner til brukere:
Det er verdt å merke seg at vi skiller mellom tilfeller der invitasjons-e-poster faktisk sendes:
En ny bruker inviteres for første gang gjennom SCIM
ELLER direkte invitasjoner fra appen
Og tilfeller der en invitasjon knyttes stille til en brukers e-postadresse i backend-systemet vårt:
En SCIM-bruker ble fjernet fra IdP-gruppen din og deretter lagt til igjen
Automatisk kontoopprettelse
I det sistnevnte tilfellet vil brukerne ikke se invitasjonene i innboksen sin, men de vil fortsatt bli sendt til riktig arbeidsområde/organisasjon når de prøver å logge inn.
SCIM
SCIM er tilgjengelig både i ChatGPT og API Platform. SCIM gjør det mulig for identitetsleverandører (f.eks. Okta, Entra ID osv.) å utveksle brukeridentitetsdata med OpenAI, og automatiserer klargjøring av invitasjoner (og avvikling av brukerkontoer) basert på organisatoriske endringer.
Selv om SCIM også konfigureres via IdP-en din, kan det settes opp uavhengig av SSO. Derfor er ikke domeneverifisering/SSO krav for SCIM.
Hvis du bestemmer deg for å bruke både SCIM og SSO, er det viktige skillet følgende:
SCIM klargjør bare invitasjoner
SSO håndterer autentisering og brukeropprettelse
Vi anser SCIM som den mest robuste og skalerbare løsningen for helhetlig brukeradministrasjon. Avhengig av hva som er din ideelle implementering, anbefaler vi generelt følgende arkitektur som beste praksis hvis du ruller ut både ChatGPT og API Platform:
Med dette oppsettet kan du enkelt administrere både invitasjoner og tilgang (til ChatGPT og API Platform) separat. Dette oppsettet har også den fordelen at nødvendige endringer kan utføres sentralt av administrasjonsteamene dine direkte i IdP-en din.
Hvis du implementerer SCIM på tvers av flere applikasjoner (f.eks. ChatGPT vs. API Platform vs. andre kontoer), bør SCIM-applikasjonene dine være unike. Selv om målbrukerbasen er identisk, anbefales det sterkt at hver SCIM-implementering refererer til en unik applikasjon i IdP-en din.
Hvis du ikke oppfyller dette kravet, kan det føre til inkonsekvenser som til slutt resulterer i ugyldige medlemskap.
Direkte invitasjoner fra ChatGPT eller API Platform
Administratorer kan invitere brukere direkte via e-post fra de respektive ChatGPT- og Platform-sidene for «Members». I ChatGPT støtter denne metoden også masseinvitasjoner via en opplastet CSV-fil:
Selv om dette vanligvis ikke er skalerbart, anbefaler vi ofte å bruke direkte invitasjoner når du kommer i gang i et nytt arbeidsområde / en ny organisasjon. I motsetning til SCIM er det ingen potensiell forsinkelse før invitasjonene når brukernes innbokser, så dette 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 samle de eksisterende brukerne dine under SCIM-applikasjonen. Det er derfor ingen risiko for at direkte inviterte brukere blir utelatt fra fremtidig automatisering, med mindre det er ønsket.
Automatisk kontoopprettelse (AAC)
I motsetning til de andre alternativene er AAC bare tilgjengelig på Identity-siden i ChatGPT og krever at SSO først er aktivert:
Som vist ovenfor garanterer AAC at brukere som registrerer seg eller logger inn med et verifisert e-postdomene, automatisk blir lagt til i Enterprise-arbeidsområdet ditt. Brukerne vil ikke motta en invitasjons-e-post, og prosessen er helt automatisert. Dette har sine fordeler og ulemper.
Hvis retningslinjene dine er å tillate åpen tilgang for alle brukere med det verifiserte domenet ditt, er AAC et godt alternativ som unngår det ekstra arbeidet med å konfigurere og administrere en SCIM-applikasjon.
AAC er imidlertid ikke ideelt hvis du trenger en mer låst, godkjenningsbasert tilnærming til brukertilgang.
⚠️ ADVARSEL ⚠️
Det er viktig å være klar over at aktivering av AAC i praksis vil tvinge alle forbrukerbrukere (personlig/Plus/Pro) under domenet ditt til å slå seg sammen inn i Enterprise-arbeidsområdet ditt. Du finner mer om dette nedenfor i delen «Handling Existing Users».
Merk at selv om brukerne ikke er medlemmer av IdP-tilgangsgruppen din og ikke kan få tilgang til arbeidsområdet når SSO håndheves, opptar de fortsatt en plass i Enterprise-kontoen din i dette scenariet.
Av denne grunn anbefaler vi generelt SCIM eller direkte invitasjoner i de fleste tilfeller fremfor AAC. Og for å bidra til å unngå mulige misforståelser anbefaler vi at AAC forblir slått av hvis du planlegger å bruke SCIM.
API Platform Admin Invites-endepunkt
API Platform støtter et Invites-endepunkt, som lar deg invitere brukere programmatisk til API-organisasjonen din.
Sammenlignet med SCIM er den største fordelen med endepunktet at du kan angi prosjektet/prosjektene den inviterte brukeren skal tilhøre:
Dette gir et ekstra lag med detaljstyring og kontroll, uten å kreve det manuelle arbeidet med individuelle direkte invitasjoner.
Håndtering av eksisterende forbrukerbrukere
Vi definerer forbrukerbrukere som brukere med et personlig abonnement, Plus eller Pro. Det er ofte slik at det finnes eksisterende forbrukerbrukere med det verifiserte domenet ditt som hadde kontoer før Enterprise-kontrakten din. Siden verifisering av domenet og aktivering av SSO kan ha etterfølgende konsekvenser for disse forbrukerbrukerne, er det viktig å fastsette ønsket resultat på forhånd.
Påvirkning på ChatGPT-forbrukerbrukere
På ChatGPT-siden bestemmes påvirkningen på forbrukere i stor grad av to faktorer:
Vil de bli invitert til Enterprise-arbeidsområdet?
Hvis AAC er aktivert, er standardsvaret «Ja»
Vil du håndheve SSO?
Den resulterende atferden kan ses nedenfor:
| Ventende invitasjon? | SSO håndhevet? | Resultat |
| ✅ | ✅ | Forbrukerbrukerkontoer vil bli tvunget til å slås sammen med Enterprise, og kan bare logge inn med SSO |
| ✅ | ❌ | Forbrukerbrukerkontoer vil bli tvunget til å slås sammen med Enterprise, og brukere kan autentisere med SSO eller sosial innlogging |
| ❌ | ✅ | Ingen påvirkning: Forbrukerbrukere beholder tilgang til sine personlige arbeidsområder via passord eller sosial innlogging |
| ❌ | ❌ | Ingen påvirkning: Forbrukerbrukere beholder tilgang til sine personlige arbeidsområder via passord eller sosial innlogging |
Hvis målet ditt til slutt er å 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 følgende:
Brukerens domene er verifisert
Brukeren har mottatt en invitasjon til Enterprise-arbeidsområdet der domenet deres er verifisert
⚠️ Husk at hvis du har aktivert AAC, vil denne betingelsen alltid være oppfylt for alle brukere med det verifiserte domenet ditt.
Når disse betingelsene er oppfylt, skal brukeren neste gang de logger på eller oppdaterer ChatGPT, se følgende modal:
Som bildet viser, refunderer vi automatisk eventuelle eksisterende Plus- eller Pro-abonnementer før sammenslåingen. Brukerne vil ha mulighet til å overføre den eksisterende chathistorikken og GPT-ene sine, eller eksportere chathistorikken via e-post og starte Enterprise-arbeidsområdet sitt med «blanke ark».
Når forbrukerkontoen er slått sammen, finnes det ingen måte å gjenopprette den på. Hvis brukerne dine valgte alternativet «Transfer existing chat history and GPTs», men ikke så dette gjenspeilet i Enterprise-arbeidsområdet sitt, kan de kontakte brukerstøtte.
Påvirkning på API Platform-forbrukerbrukere
Fordi SSO på Platform fortsatt er domenebasert (i motsetning til ChatGPT, der SSO er spesifikt for arbeidsområdet der det er aktivert), vil forbrukerbrukerne dine bli påvirket så snart du verifiserer domenet ditt og aktiverer SSO på en hvilken som helst organisasjon.
Forbrukerbrukerne mister muligheten til å autentisere med passord, fordi vi identifiserer domenesamsvaret 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 sine.
Se flytene i delen Brukerinnlogging for en mer inngående veiledning til denne arbeidsflyten.
Anbefalte mønstre for identitet og klargjøring
Nå som vi har lagt frem 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:
Brukerinnloggingsflyt
Vi har allerede diskutert virkningen av ventende invitasjoner og håndheving av SSO, så denne delen er ment å hjelpe med å visualisere den forventede flyten/kontrollene vi utfører når en bruker skriver inn e-postadressen sin for å logge inn.
Innloggingsflyt for ChatGPT
Merk: Dette diagrammet utelukker innloggingsforsøk via en sosial metode eller via Tile URL.
Innloggingsflyt for API Platform
Merk: Dette diagrammet utelukker innloggingsforsøk via en sosial metode eller via Tile URL.
Neste trinn
Nå som du har en idé om din ideelle implementering, kan du følge den respektive dokumentasjonen for å aktivere SCIM eller SSO: