Прегледайте нашата страница „Общ преглед на SSO“, за да се запознаете с ключовите понятия, обсъждани в този документ.
Преди да потвърдите домейните си, е важно да обмислите няколко различни въпроса:
Как искате да предоставяте покани на нови потребители?
Как искате да третирате съществуващите потребители с потребителски акаунти (лични/Plus/Pro)?
Как искате да изглежда потокът за влизане на потребителите?
Ще разгледаме всеки от тези въпроси по-подробно, за да ви помогнем да изберете опцията, която най-добре отговаря на нуждите ви.
Канене на нови потребители
В момента предлагаме четири различни метода за предоставяне на покани на потребители:
Струва си да отбележим, че разграничаваме случаите, в които имейлите с покани се изпращат активно, от случаите, в които поканата се свързва тихо с имейла на потребителя в нашия бекенд.
Имейлите с покани се изпращат активно, когато:
Нов потребител е поканен за първи път чрез SCIM.
Потребител е поканен директно от ChatGPT или API Platform.
Поканите се свързват тихо, когато:
Потребител в SCIM е премахнат от вашата IdP група и след това добавен отново.
Прилага се автоматично създаване на акаунт.
Във втория случай потребителите няма да видят поканите във входящата си кутия, но все пак ще бъдат правилно насочени към съответното работно пространство/организация, когато се опитат да влязат.
SCIM
SCIM е наличен както в ChatGPT, така и в API Platform. SCIM позволява на доставчиците на идентичност (напр. Okta, Entra ID и др.) да обменят данни за потребителска идентичност с OpenAI, като автоматизират предоставянето на покани (и премахването на потребителски акаунти) въз основа на организационни промени.
Въпреки че SCIM също се конфигурира чрез вашия IdP, той може да бъде настроен независимо от SSO. Следователно потвърждаването на домейн/SSO не са изисквания за SCIM.
Ако решите да използвате едновременно SCIM и SSO, важното разграничение е:
SCIM само предоставя покани
SSO обработва удостоверяването и създаването на потребители
Считаме SCIM за най-стабилното и мащабируемо решение за цялостно управление на потребителите. В зависимост от идеалното за вас внедряване, обикновено препоръчваме следната архитектура като добра практика, ако внедрявате както в ChatGPT, така и в API Platform:
С тази настройка можете лесно да управлявате отделно както поканите, така и достъпа (до ChatGPT и API Platform). Допълнително предимство на тази настройка е, че всички необходими промени могат да се извършват централно от вашите административни екипи директно във вашия IdP.
Ако внедрявате SCIM в няколко приложения (т.е. ChatGPT спрямо API Platform спрямо други акаунти), вашите SCIM приложения трябва да са уникални. Дори целевата ви потребителска база да е една и съща, силно препоръчваме всяко внедряване на SCIM да сочи към уникално приложение във вашия IdP.
Ако не спазите това изискване, може да възникнат проблеми с несъответствия, които в крайна сметка водят до невалидни членства.
Директни покани от ChatGPT или API Platform
Администраторите могат директно да канят потребители по имейл от съответните страници „Членове“ в ChatGPT и Platform. В ChatGPT този метод поддържа и масови покани чрез качен CSV файл:
Макар че обикновено не е мащабируемо решение, често препоръчваме да използвате директни покани, когато започвате работа в ново работно пространство/организация. За разлика от SCIM, няма потенциално забавяне, докато поканите достигнат до входящите кутии на потребителите, така че това е най-ефективната опция за бърз достъп, промяна на разрешения и общо тестване.
Освен това винаги можете да активирате SCIM по-късно и да групирате съществуващите си потребители под SCIM приложението. Така няма опасност директно поканените потребители да бъдат изключени от бъдеща автоматизация, освен ако не го желаете.
Автоматично създаване на акаунт (AAC)
За разлика от другите опции, AAC е налично само на страницата Identity в ChatGPT и изисква първо да е активирано SSO:
Както е показано по-горе, AAC гарантира, че потребителите, които се регистрират или влизат с потвърден имейл домейн, автоматично ще бъдат добавени към вашето Enterprise работно пространство. Потребителите няма да получат имейл с покана, а процесът е изцяло автоматизиран. Това има своите плюсове и минуси.
Ако политиката ви е да позволите свободен достъп на всеки потребител с вашия потвърден домейн, AAC е отлична опция, която избягва допълнителните усилия по конфигуриране и управление на SCIM приложение.
AAC обаче не е идеално, ако изисквате по-строг подход към потребителския достъп, основан на одобрение.
⚠️ ПРЕДУПРЕЖДЕНИЕ ⚠️
Важно е да имате предвид, че активирането на AAC на практика ще принуди всички потребители с потребителски акаунти (лични/Plus/Pro) във вашия домейн да бъдат обединени във вашето Enterprise работно пространство. Повече по темата можете да намерите по-долу в раздела „Работа със съществуващи потребители“.
Имайте предвид, че дори ако потребителите не са членове на групата за достъп във вашия IdP и не могат успешно да получат достъп до работното пространство при наложено SSO, в този сценарий те все пак заемат място във вашия Enterprise акаунт.
Поради тази причина в повечето случаи обикновено препоръчваме SCIM или директни покани вместо AAC. И за да избегнете потенциални източници на объркване, препоръчваме да оставите AAC изключено, ако планирате да използвате SCIM.
Endpoint за администраторски покани в API Platform
Нашата API Platform поддържа Invites Endpoint, който ви позволява програмно да каните потребители във вашата API организация.
В сравнение със SCIM основното предимство на endpoint е, че ви позволява да посочите към кои проекти трябва да принадлежи поканеният потребител:
Това осигурява допълнително ниво на детайлност и контрол, без да изисква ръчната работа по индивидуални директни покани.
Работа със съществуващи потребители с потребителски акаунти
Определяме като потребители с потребителски акаунти тези, които имат личен абонамент, Plus или Pro. Често се случва да има съществуващи потребители с потребителски акаунти във вашия потвърден домейн, които са имали акаунти преди вашия Enterprise договор. Тъй като потвърждаването на домейна ви и активирането на SSO може да има последващо въздействие върху тези потребители, важно е предварително да определите желания резултат.
Влияние върху потребители с потребителски акаунти в ChatGPT
От страна на ChatGPT влиянието върху потребителите се определя основно от два фактора:
Ще бъдат ли поканени в Enterprise работното пространство?
Ще наложите ли SSO?
Полученото поведение може да се види по-долу:
| Чакаща покана? | Наложено SSO? | Резултат |
|---|---|---|
| Да | Да | Потребителските акаунти ще бъдат принудително обединени с Enterprise и потребителите ще могат да влизат само със SSO. |
| Да | Не | Потребителските акаунти ще бъдат принудително обединени с Enterprise, а потребителите ще могат да се удостоверяват със SSO или социално влизане. |
| Не | Да | Няма влияние: потребителите запазват достъпа до личните си работни пространства чрез парола или социално удостоверяване. |
| Не | Не | Няма влияние: потребителите запазват достъпа до личните си работни пространства чрез парола или социално удостоверяване. |
Ако целта ви в крайна сметка е да предотвратите наличието на потребителски акаунти, свържете се с вашия Account Director, за да обсъдите възможните опции.
Обединяване на акаунти
Предварителните условия за задействане на автоматично обединяване на потребителски акаунт с Enterprise акаунт са следните:
Домейнът на потребителя е потвърден.
Потребителят е получил покана за Enterprise работното пространство, в което неговият домейн е потвърден.
Забележка: Ако сте активирали AAC, това условие винаги ще бъде изпълнено за всеки потребител с вашия потвърден домейн.
Когато тези условия са изпълнени, при следващото влизане или обновяване на ChatGPT потребителят трябва да види следния модален прозорец:
Както е подчертано на изображението, автоматично ще възстановим сумите за всички съществуващи абонаменти Plus или Pro преди обединяването. Потребителите ще имат възможност да прехвърлят съществуващата си история на чатове и GPT, или да експортират историята на чатове по имейл и да започнат в своето Enterprise работно пространство „на чисто“.
След като потребителският акаунт бъде обединен, няма начин да бъде възстановен. Ако потребителите ви са избрали опцията „Прехвърляне на съществуващата история на чатове и GPT“, но не виждат това отразено в своето Enterprise работно пространство, свържете се с поддръжката.
Влияние върху потребители с потребителски акаунти в API Platform
Тъй като SSO в Platform все още е базирано на домейн (за разлика от ChatGPT, където SSO е специфично за работното пространство, в което е активирано), потребителите с потребителски акаунти ще бъдат засегнати веднага щом потвърдите домейна си и активирате SSO в която и да е организация.
Потребителите с потребителски акаунти ще загубят възможността да се удостоверяват с пароли, тъй като ние разпознаваме съвпадението на домейна и ги препращаме към вашия IdP. Ако са членове на вашия IdP, те могат да се удостоверят успешно. Като алтернатива могат да влязат чрез социална OAuth опция, ако такава им е налична. Ако не, на практика сте ги лишили от достъп до техните потребителски акаунти.
Вижте раздела „Поток за влизане на потребител“ за по-подробно ръководство за този работен процес.
Препоръчани модели за идентичност и предоставяне
След като очертахме основното поведение, свързано с удостоверяването на идентичност и предоставянето на покани, може да е полезно да разгледате някои от по-често срещаните модели за внедряване, достъпни за Enterprise потребители:
Поток за влизане на потребител
Вече обсъдихме влиянието на чакащите покани и налагането на SSO, затова този раздел има за цел да визуализира очаквания поток/проверки, които извършваме, когато потребител въведе имейл адреса си за влизане.
Поток за влизане в ChatGPT
Забележка: Тази диаграма не включва опити за влизане чрез социален метод или чрез Tile URL.
Поток за влизане в API Platform
Забележка: Тази диаграма не включва опити за влизане чрез социален метод или чрез Tile URL.
Следващи стъпки
След като вече имате представа за идеалното си внедряване, можете да следвате съответната документация, за да активирате SCIM или SSO: