ဤစာတမ်းတွင် ဆွေးနွေးထားသော အဓိကအယူအဆများကို သိရှိနားလည်ရန် ကျွန်ုပ်တို့၏ “SSO အကျဉ်းချုပ်” စာမျက်နှာကို ဖတ်ရှုပေးပါ။
သင့် domains များကို verify မလုပ်မီ မေးခွန်းအချို့ကို စဉ်းစားထားရန် အရေးကြီးပါသည်။
အသုံးပြုသူအသစ်များအတွက် ဖိတ်ကြားချက်များကို မည်သို့ provision လုပ်လိုပါသလဲ။
ရှိပြီးသား consumer (personal/Plus/Pro) အသုံးပြုသူများကို မည်သို့ကိုင်တွယ်လိုပါသလဲ။
သင့်အသုံးပြုသူ login flow ကို မည်သို့ဖြစ်စေလိုပါသလဲ။
သင့်လိုအပ်ချက်နှင့် အကောင်းဆုံးကိုက်ညီသော ရွေးချယ်စရာကို ရွေးနိုင်ရန် ဤမေးခွန်းတစ်ခုချင်းစီကို ပိုမိုအသေးစိတ် လေ့လာကြပါမည်။
အသုံးပြုသူအသစ်များကို ဖိတ်ကြားခြင်း
လက်ရှိတွင် အသုံးပြုသူများအတွက် ဖိတ်ကြားချက်များ provision လုပ်ရန် နည်းလမ်း ၄ မျိုး ပံ့ပိုးထားပါသည်။
ဖိတ်ကြားချက်အီးမေးလ်များကို တက်ကြွစွာ ပို့သည့်အခြေအနေများနှင့် ကျွန်ုပ်တို့၏ backend တွင် အသုံးပြုသူ၏ အီးမေးလ်နှင့် ဖိတ်ကြားချက်ကို အသံတိတ် ချိတ်ဆက်ထားသည့်အခြေအနေများကို ကျွန်ုပ်တို့ ခွဲခြားထားကြောင်း မှတ်သားရန် ကောင်းပါသည်။
ဖိတ်ကြားချက်အီးမေးလ်များကို တက်ကြွစွာ ပို့သည့်အချိန်များမှာ-
အသုံးပြုသူအသစ်ကို SCIM မှတစ်ဆင့် ပထမဆုံးအကြိမ် ဖိတ်ကြားသောအခါ။
အသုံးပြုသူကို ChatGPT သို့မဟုတ် API Platform မှ တိုက်ရိုက်ဖိတ်ကြားသောအခါ။
ဖိတ်ကြားချက်များကို အသံတိတ် ချိတ်ဆက်ထားသည့်အချိန်များမှာ-
SCIM အသုံးပြုသူတစ်ဦးကို သင့် IdP group မှ ဖယ်ရှားပြီး နောက်တစ်ကြိမ် ပြန်ထည့်သောအခါ။
Automatic Account Creation သက်ရောက်သောအခါ။
နောက်ပိုင်းအခြေအနေတွင် အသုံးပြုသူများသည် inbox ထဲတွင် ဖိတ်ကြားချက်များကို မမြင်ရသော်လည်း login ဝင်ရန် ကြိုးစားသောအခါ သက်ဆိုင်ရာ အလုပ်နေရာ/organization သို့ မှန်ကန်စွာ လမ်းညွှန်ခံရမည်ဖြစ်သည်။
SCIM
SCIM ကို ChatGPT နှင့် API Platform နှစ်ခုလုံးတွင် အသုံးပြုနိုင်သည်။ SCIM သည် identity provider များ (ဥပမာ Okta၊ Entra ID စသည်) ကို OpenAI နှင့် အသုံးပြုသူ identity data ဖလှယ်နိုင်စေပြီး အဖွဲ့အစည်းအပြောင်းအလဲများအပေါ် မူတည်၍ ဖိတ်ကြားချက် provision လုပ်ခြင်း (နှင့် အသုံးပြုသူအကောင့် de-provision လုပ်ခြင်း) ကို အလိုအလျောက် ပြုလုပ်ပေးသည်။
SCIM ကိုလည်း သင့် IdP မှတစ်ဆင့် configure လုပ်သော်လည်း SSO နှင့် သီးခြားစီ setup လုပ်နိုင်သည်။ ထို့ကြောင့် domain verification/SSO သည် SCIM အတွက် လိုအပ်ချက်များ မဟုတ်ပါ။
SCIM နှင့် SSO နှစ်ခုလုံးကို အသုံးပြုရန် ဆုံးဖြတ်ပါက အရေးကြီးသော ကွာခြားချက်မှာ-
SCIM သည် ဖိတ်ကြားချက်များကိုသာ provision လုပ်သည်
SSO သည် authentication နှင့် အသုံးပြုသူဖန်တီးခြင်းကို ကိုင်တွယ်သည်
SCIM ကို အသုံးပြုသူစီမံခန့်ခွဲမှု တစ်ခုလုံးအတွက် အခိုင်မာဆုံးနှင့် scalability အကောင်းဆုံး ဖြေရှင်းချက်အဖြစ် ကျွန်ုပ်တို့ သတ်မှတ်ပါသည်။ သင့်အတွက် သင့်လျော်သော အကောင်အထည်ဖော်ပုံပေါ် မူတည်၍ ChatGPT နှင့် API Platform နှစ်ခုလုံးတွင် deploy လုပ်မည်ဆိုပါက အောက်ပါ architecture ကို best practice အဖြစ် ယေဘုယျအားဖြင့် အကြံပြုပါသည်။

ဤ setup ဖြင့် ဖိတ်ကြားချက်များ နှင့် access (ChatGPT နှင့် API Platform သို့) ကို သီးခြားစီ လွယ်ကူစွာ စီမံနိုင်သည်။ ဤ setup ၏ နောက်ထပ်အကျိုးကျေးဇူးမှာ လိုအပ်သောပြောင်းလဲမှုများကို သင်၏ administration teams များက သင်၏ IdP ထဲတွင် တိုက်ရိုက် ဗဟိုမှ စီမံလုပ်ဆောင်နိုင်ခြင်းဖြစ်သည်။
အက်ပ်များစွာတွင် SCIM ကို အကောင်အထည်ဖော်နေပါက (ဥပမာ ChatGPT၊ API Platform၊ သို့မဟုတ် အခြားအကောင့်များ) သင်၏ SCIM Applications များသည် တစ်ခုနှင့်တစ်ခု သီးခြားဖြစ်သင့်သည်။ သင်ဦးတည်ထားသော အသုံးပြုသူအုပ်စု တူညီနေသော်လည်း SCIM အကောင်အထည်ဖော်မှုတိုင်းသည် သင်၏ IdP ထဲရှိ သီးခြား application တစ်ခုကို ကိုးကားရန် အထူးအကြံပြုပါသည်။
ဤလိုအပ်ချက်ကို မပြည့်မီပါက နောက်ဆုံးတွင် အကျုံးမဝင်သော membership များ ဖြစ်စေနိုင်သည့် မညီညွတ်မှု ပြဿနာများ ပေါ်ပေါက်နိုင်သည်။
ChatGPT သို့မဟုတ် API Platform မှ တိုက်ရိုက်ဖိတ်ကြားချက်များ
Admin များသည် သက်ဆိုင်ရာ ChatGPT နှင့် Platform ၏ “Members” စာမျက်နှာများမှ အသုံးပြုသူများကို အီးမေးလ်ဖြင့် တိုက်ရိုက်ဖိတ်ကြားနိုင်သည်။ ChatGPT တွင် ဤနည်းလမ်းသည် uploaded CSV မှတစ်ဆင့် bulk invitations များကိုလည်း ပံ့ပိုးသည်။

ပုံမှန်အားဖြင့် scalability မကောင်းသော်လည်း အလုပ်နေရာ/organization အသစ်တွင် စတင်အသုံးပြုနေချိန်တွင် တိုက်ရိုက်ဖိတ်ကြားမှုများ အသုံးပြုရန် ကျွန်ုပ်တို့ မကြာခဏ အကြံပြုပါသည်။ SCIM နှင့် မတူဘဲ ဖိတ်ကြားချက်များ အသုံးပြုသူ inbox ထံ ရောက်ရန် နှောင့်နှေးနိုင်ခြေ မရှိသောကြောင့် လျင်မြန်စွာ access ပေးခြင်း၊ permissions ပြင်ဆင်ခြင်းနှင့် အထွေထွေ testing အတွက် အထိရောက်ဆုံး ရွေးချယ်မှုဖြစ်သည်။
ထို့အပြင် နောက်ပိုင်းတွင် SCIM ကို အမြဲဖွင့်နိုင်ပြီး သင့်ရှိပြီးသား အသုံးပြုသူများကို SCIM application အောက်တွင် စုစည်းနိုင်ပါသည်။ ထို့ကြောင့် မလိုလားပါက တိုက်ရိုက်ဖိတ်ကြားထားသော အသုံးပြုသူများသည် အနာဂတ် automation မှ ဖယ်ထုတ်ခံရမည်ကို စိုးရိမ်ရန် မလိုပါ။
Automatic Account Creation (AAC)
အခြားရွေးချယ်စရာများနှင့် ဆန့်ကျင်ဘက်အနေဖြင့် AAC ကို ChatGPT ၏ Identity page တွင်သာ ရနိုင်ပြီး SSO ကို အရင်ဖွင့်ထားရန် လိုအပ်သည်။

အထက်တွင် ပြထားသည့်အတိုင်း AAC သည် verified email domain ဖြင့် sign up သို့မဟုတ် login ဝင်သည့် အသုံးပြုသူများကို သင့် Enterprise အလုပ်နေရာထဲသို့ အလိုအလျောက် ထည့်ပေးရန် အာမခံသည်။ အသုံးပြုသူများသည် ဖိတ်ကြားချက်အီးမေးလ်ကို ရရှိမည်မဟုတ်ဘဲ လုပ်ငန်းစဉ်တစ်ခုလုံးမှာ အလိုအလျောက်ဖြစ်သည်။ ၎င်းတွင် အားသာချက်နှင့် အားနည်းချက်များ ရှိသည်။
သင့် policy သည် သင် verify လုပ်ထားသော domain ရှိ မည်သည့်အသုံးပြုသူမဆို open-door access ခွင့်ပြုရန်ဖြစ်ပါက AAC သည် SCIM application configure နှင့် manage လုပ်ရန် ထပ်ဆောင်းအားထုတ်ရမှုကို ရှောင်ရှားနိုင်သည့် ကောင်းမွန်သောရွေးချယ်မှုဖြစ်သည်။
သို့သော် အသုံးပြုသူ access အတွက် ပိုမိုတင်းကျပ်ပြီး approval-based approach လိုအပ်ပါက AAC သည် မသင့်လျော်ပါ။
⚠️ သတိပေးချက် ⚠️
AAC ကို ဖွင့်ပါက သင့် domain အောက်ရှိ consumer (personal/Plus/Pro) အသုံးပြုသူအားလုံးကို သင့် Enterprise အလုပ်နေရာထဲသို့ လက်တွေ့အားဖြင့် အတင်းအကျပ် merge လုပ်မည်ဖြစ်ကြောင်း သတိပြုရန် အရေးကြီးပါသည်။ ဤအကြောင်းကို အောက်ရှိ “ရှိပြီးသား အသုံးပြုသူများကို ကိုင်တွယ်ခြင်း” ကဏ္ဍတွင် ပိုမိုဖတ်ရှုနိုင်ပါသည်။
ဤအခြေအနေတွင် အသုံးပြုသူများသည် သင့် IdP access group ၏ အဖွဲ့ဝင်များမဟုတ်ဘဲ SSO enforced ဖြစ်ပါက အလုပ်နေရာကို အောင်မြင်စွာ ဝင်ရောက်နိုင်ခြင်းမရှိသော်လည်း သင့် Enterprise အကောင့်တွင် seat တစ်ခုကို ဆက်လက်ယူထားမည်ဖြစ်ကြောင်း မှတ်သားပါ။
ဤအကြောင်းကြောင့် AAC အစား SCIM သို့မဟုတ် တိုက်ရိုက်ဖိတ်ကြားချက်များကို အခြေအနေအများစုတွင် ယေဘုယျအားဖြင့် အကြံပြုပါသည်။ ထို့အပြင် ရှုပ်ထွေးမှုဖြစ်နိုင်သည့် လမ်းကြောင်းများကို ရှောင်ရှားရန် SCIM အသုံးပြုရန် စီစဉ်ထားပါက AAC ကို ပိတ်ထားရန် အကြံပြုပါသည်။
API Platform Admin Invites Endpoint
ကျွန်ုပ်တို့၏ API Platform တွင် Invites Endpoint ကို ပံ့ပိုးထားပြီး၊ ၎င်းမှတစ်ဆင့် သင့် API organization သို့ အသုံးပြုသူများကို programmatically ဖိတ်ကြားနိုင်သည်။
SCIM နှင့် နှိုင်းယှဉ်ပါက endpoint ၏ အဓိကအကျိုးကျေးဇူးမှာ ဖိတ်ကြားခံအသုံးပြုသူ ပါဝင်သင့်သော project များကို သတ်မှတ်နိုင်ခြင်းဖြစ်သည်။

ဤနည်းဖြင့် တစ်ဦးချင်း တိုက်ရိုက်ဖိတ်ကြားရန် manual အလုပ် မလိုဘဲ ပိုမိုအသေးစိတ်သော ခွဲခြားသတ်မှတ်မှုနှင့် ထိန်းချုပ်မှု အလွှာတစ်ခုကို ရရှိစေသည်။
ရှိပြီးသား Consumer Users များကို ကိုင်တွယ်ခြင်း
consumer အသုံးပြုသူများကို personal၊ Plus သို့မဟုတ် Pro subscription ပေါ်ရှိသူများဟု ကျွန်ုပ်တို့ သတ်မှတ်ပါသည်။ သင့် Enterprise contract မတိုင်မီကတည်းက အကောင့်ရှိထားသည့်၊ သင် verify လုပ်ထားသော domain နှင့် သက်ဆိုင်သော ရှိပြီးသား consumer အသုံးပြုသူများ ရှိနေတတ်ပါသည်။ သင့် domain ကို verify လုပ်ခြင်းနှင့် SSO ဖွင့်ခြင်းတို့သည် ဤ consumer အသုံးပြုသူများအပေါ် ဆက်နွယ်သက်ရောက်မှု ရှိနိုင်သောကြောင့် လိုချင်သောရလဒ်ကို ကြိုတင်ဆုံးဖြတ်ထားရန် အရေးကြီးပါသည်။
ChatGPT Consumer Users များအပေါ် သက်ရောက်မှု
ChatGPT ဘက်တွင် consumer များအပေါ် သက်ရောက်မှုကို အဓိကအားဖြင့် အချက်နှစ်ချက်က သတ်မှတ်သည်။
၎င်းတို့ကို Enterprise အလုပ်နေရာသို့ ဖိတ်ကြားမည်လား။
သင် SSO ကို enforce လုပ်မည်လား။
ရလဒ်အနေနှင့် ဖြစ်ပေါ်မည့်လုပ်ဆောင်ပုံကို အောက်တွင် ကြည့်နိုင်သည်။
| Pending Invite ရှိပါသလား။ | SSO Enforced ဖြစ်ပါသလား။ | ရလဒ် |
|---|---|---|
| ရှိသည် | ရှိသည် | Consumer အသုံးပြုသူအကောင့်များသည် Enterprise သို့ အတင်း merge လုပ်ခံရပြီး SSO ဖြင့်သာ login ဝင်နိုင်မည်။ |
| ရှိသည် | မရှိပါ | Consumer အသုံးပြုသူအကောင့်များသည် Enterprise သို့ အတင်း merge လုပ်ခံရပြီး အသုံးပြုသူများသည် SSO သို့မဟုတ် social login ဖြင့် authenticate လုပ်နိုင်မည်။ |
| မရှိပါ | ရှိသည် | သက်ရောက်မှုမရှိပါ- Consumer အသုံးပြုသူများသည် password သို့မဟုတ် social authentication မှတစ်ဆင့် ၎င်းတို့၏ personal အလုပ်နေရာများကို ဆက်လက်အသုံးပြုနိုင်သည်။ |
| မရှိပါ | မရှိပါ | သက်ရောက်မှုမရှိပါ- Consumer အသုံးပြုသူများသည် password သို့မဟုတ် social authentication မှတစ်ဆင့် ၎င်းတို့၏ personal အလုပ်နေရာများကို ဆက်လက်အသုံးပြုနိုင်သည်။ |
သင့်ရည်မှန်းချက်မှာ နောက်ဆုံးတွင် consumer အကောင့်များကို လုံးဝတားဆီးရန်ဖြစ်ပါက ဖြစ်နိုင်သောရွေးချယ်စရာများကို ဆွေးနွေးရန် သင့် Account Director ထံ ဆက်သွယ်ပါ။
အကောင့် ပေါင်းစည်းခြင်း
စားသုံးသူအကောင့်ကို Enterprise အကောင့်ထဲသို့ အလိုအလျောက် ပေါင်းစည်းမှု စတင်ရန် လိုအပ်ချက်များမှာ အောက်ပါအတိုင်း ဖြစ်သည်-
အသုံးပြုသူ၏ ဒိုမိန်းကို အတည်ပြုပြီး ဖြစ်ရမည်။
အသုံးပြုသူသည် ၎င်းတို့၏ ဒိုမိန်းကို အတည်ပြုထားသော Enterprise အလုပ်နေရာသို့ ဖိတ်ကြားချက် လက်ခံရရှိထားရမည်။
မှတ်ချက်- AAC ကို ဖွင့်ထားပါက၊ သင့်အတည်ပြုထားသော ဒိုမိန်းရှိ အသုံးပြုသူတိုင်းအတွက် ဤအခြေအနေသည် အမြဲမှန်ကန်နေမည်။
ဤအခြေအနေများ ပြည့်မီပါက၊ အသုံးပြုသူသည် နောက်တစ်ကြိမ် ChatGPT သို့ ဝင်ရောက်သည့်အခါ သို့မဟုတ် ပြန်လည်ဆန်းသစ်သည့်အခါ အောက်ပါ modal ကို မြင်ရမည် ဖြစ်သည်-

ပုံတွင် ပြထားသည့်အတိုင်း၊ ပေါင်းစည်းမှုမပြုမီ ရှိပြီးသား Plus သို့မဟုတ် Pro စာရင်းသွင်းမှုများအတွက် ကျွန်ုပ်တို့ အလိုအလျောက် ငွေပြန်အမ်းပေးမည်။ အသုံးပြုသူများသည် ရှိပြီးသား စကားဝိုင်းမှတ်တမ်းနှင့် GPT များကို လွှဲပြောင်းနိုင်မည်ဖြစ်သည်။ သို့မဟုတ် စကားဝိုင်းမှတ်တမ်းကို အီးမေးလ်မှတစ်ဆင့် ထုတ်ယူပြီး ၎င်းတို့၏ Enterprise အလုပ်နေရာကို “အစကနေ အသစ်” အဖြစ် စတင်နိုင်မည် ဖြစ်သည်။
မှတ်ချက်- လွှဲပြောင်းမည့် Enterprise သို့မဟုတ် Edu အလုပ်နေရာတွင် ဒေတာ သိမ်းဆည်းပြီး စီမံဆောင်ရွက်သည့်နေရာကို ဖွင့်ထားပါက Personal အလုပ်နေရာဒေတာကို လွှဲပြောင်း၍ မရပါ။ အသုံးပြုသူများသည် ၎င်းတို့၏ စကားဝိုင်းများကို ထုတ်ယူပြီး Personal အလုပ်နေရာကို ဖျက်ခြင်းသာ ပြုလုပ်နိုင်သည်။ အသေးစိတ်အတွက် အီးမေးလ် ဖိတ်ကြားချက်များနှင့် အကောင့် ရွှေ့ပြောင်းမှုများ ကို ကြည့်ပါ။
စားသုံးသူအကောင့်ကို ပေါင်းစည်းပြီးသည်နှင့် ၎င်းကို ပြန်လည်ရယူရန် နည်းလမ်း မရှိတော့ပါ။ သင့်အသုံးပြုသူများသည် “ရှိပြီးသား စကားဝိုင်းမှတ်တမ်းနှင့် GPT များကို လွှဲပြောင်းရန်” ရွေးချယ်မှုကို ရွေးခဲ့သော်လည်း ၎င်းတို့၏ Enterprise အလုပ်နေရာတွင် ၎င်းကို မတွေ့ပါက၊ Support ကို ဆက်သွယ်ပါ။
API Platform Consumer Users များအပေါ် သက်ရောက်မှု
Platform ပေါ်ရှိ SSO သည် domain-based ဖြစ်နေသေးသောကြောင့် (SSO ကို ဖွင့်ထားသည့် အလုပ်နေရာအလိုက် သီးခြားဖြစ်သော ChatGPT နှင့် ဆန့်ကျင်ဘက်) သင်၏ domain ကို verify လုပ်ပြီး မည်သည့် organization တွင်မဆို SSO ဖွင့်လိုက်သည်နှင့် သင့် consumer အသုံးပြုသူများအပေါ် သက်ရောက်မှုရှိမည်ဖြစ်သည်။
ကျွန်ုပ်တို့က domain ကိုက်ညီမှုကို ခွဲခြားသိရှိပြီး ၎င်းတို့ကို သင်၏ IdP သို့ forward လုပ်သောကြောင့် consumer အသုံးပြုသူများသည် password ဖြင့် authenticate လုပ်နိုင်စွမ်း ဆုံးရှုံးမည်ဖြစ်သည်။ ၎င်းတို့သည် သင့် IdP ၏ အဖွဲ့ဝင်များဖြစ်ပါက အောင်မြင်စွာ authenticate လုပ်နိုင်သည်။ တနည်းအားဖြင့် ၎င်းတို့အတွက် ရနိုင်ပါက social OAuth option ဖြင့် login ဝင်နိုင်သည်။ မရနိုင်ပါက သင်သည် ၎င်းတို့ကို ၎င်းတို့၏ consumer အကောင့်များမှ လက်တွေ့အားဖြင့် lock out ဖြစ်စေထားခြင်း ဖြစ်သည်။
ဤ workflow အတွက် ပိုမိုအသေးစိတ်လမ်းညွှန်ကို အသုံးပြုသူ Login Flow ကဏ္ဍတွင် ကြည့်ပါ။
အကြံပြုထားသော Identity နှင့် Provisioning Patterns
ကျွန်ုပ်တို့၏ identity authentication နှင့် invitation provisioning တို့နှင့် ဆက်နွယ်သော အခြေခံလုပ်ဆောင်ပုံကို ရှင်းပြပြီးဖြစ်သဖြင့် Enterprise အသုံးပြုသူများအတွက် ရရှိနိုင်သော ပိုမိုအသုံးများသည့် implementation patterns အချို့ကို ပြန်လည်ကြည့်ရှုခြင်းက အထောက်အကူ ဖြစ်နိုင်ပါသည်။

အသုံးပြုသူ Login Flow
စောင့်ဆိုင်းနေသော ဖိတ်ကြားချက်များနှင့် SSO enforced ဖြစ်ခြင်း၏ သက်ရောက်မှုကို ဆွေးနွေးပြီးဖြစ်သဖြင့်၊ ဤကဏ္ဍသည် အသုံးပြုသူက login ဝင်ရန် အီးမေးလ်လိပ်စာ ထည့်သွင်းသောအခါ ကျွန်ုပ်တို့လုပ်ဆောင်သည့် မျှော်မှန်း flow/checks များကို မြင်သာစေရန် ကူညီရန် ရည်ရွယ်ပါသည်။
ChatGPT Login Flow
မှတ်ချက်- ဤပုံပြကားချပ်တွင် Social နည်းလမ်း သို့မဟုတ် Tile URL မှတစ်ဆင့် login ကြိုးပမ်းမှုများ မပါဝင်ပါ။

API Platform Login Flow
မှတ်ချက်- ဤပုံပြကားချပ်တွင် Social နည်းလမ်း သို့မဟုတ် Tile URL မှတစ်ဆင့် login ကြိုးပမ်းမှုများ မပါဝင်ပါ။

နောက်အဆင့်များ
သင့်အတွက် သင့်လျော်သော အကောင်အထည်ဖော်ပုံကို ယခု ခန့်မှန်းသဘောပေါက်ပြီးဖြစ်သဖြင့် SCIM သို့မဟုတ် SSO ကို ဖွင့်ရန် သက်ဆိုင်ရာ စာရွက်စာတမ်းများကို လိုက်နာနိုင်ပါသည်။
