ورود تیم‌تان با SSO
آنچه خواهید ساخت
بخش با عنوان “آنچه خواهید ساخت”تا پایان این آموزش، این‌ها را خواهید داشت:
- یک اتصال SAML میان سرور Control Center شما و یک ارائه‌دهندهٔ هویت (Okta را نمونه می‌گیریم)،
- یک کاربر که در نخستین ورودش خودکار تأمین می‌شود، و
- یک سیاست عضویت فضای کاری که آگاهانه انتخاب کرده‌اید.
به سروری نیاز دارید که خودتان اداره می‌کنید (مالک سرور — بهره‌بردار این نصب) و یک برنامهٔ IdP که بتوانید پیکربندی کنید. 20 دقیقه وقت بگذارید.
1. تنظیمات ورود یکپارچه را باز کنید
بخش با عنوان “1. تنظیمات ورود یکپارچه را باز کنید”به Control Center وارد شوید، سپس به تنظیمات → سرور → ورود یکپارچه بروید. این صفحه میان SAML و OpenID Connect جابه‌جا می‌شود و یک کارت تأمین کاربر (SCIM) هم دارد. روی SAML بمانید.
همه‌چیز در این صفحه در سطح سرور است: یک IdP هویت همهٔ کاربران انسانی هر فضای کاری را احراز می‌کند، پس فقط مالک سرور می‌تواند آن را ویرایش کند.
2. فرادادهٔ IdP را جای‌گذاری کنید
بخش با عنوان “2. فرادادهٔ IdP را جای‌گذاری کنید”در Okta، زبانهٔ Sign On برنامهٔ خود را باز کنید و XML فراداده را کپی کنید (یا آن را دانلود کنید و محتوای فایل را جای‌گذاری کنید). به Control Center برگردید، آن را در XML فرادادهٔ IdP جای‌گذاری کنید و آزمایش اتصال را بزنید.
توست، نقطهٔ پایانی ورود IdP را گزارش می‌کند — گواهی بر این که فراداده تجزیه
شد، گواهی خوانده شد و سرور می‌تواند یک درخواست ورود در برابر آن بسازد (این
آزمایش همه‌چیز جز رفت‌وبرگشت مرورگر را می‌آزماید). اگر شکست بخورد، آن XML
یک EntityDescriptor کامل نبوده است (زبانهٔ SAML در Okta آن را
«Metadata URL» می‌نامد؛ URL را باز کنید و آنچه ارائه می‌دهد را کپی کنید).
همان دکمه روی OpenID Connect به‌جایش سند کشف صادرکنندهٔ شما را بررسی
می‌کند. برای این که گواهی در آستانهٔ انقضا را هم بگیرید و ببینید IdP اصلاً
Control Center را می‌شناسد یا نه، از
بررسی‌کنندهٔ گام 6 استفاده کنید.
3. Control Center را نزد IdP ثبت کنید
بخش با عنوان “3. Control Center را نزد IdP ثبت کنید”کپی فرادادهٔ SP را بزنید و آن را به هر کس که سمت Okta را پیکربندی می‌کند بسپارید (یا دو مقداری را که می‌پرسند بخوانید):
- ACS URL:
https://<your-server>/saml/acs - Entity ID:
https://<your-server>/saml
این URLها از مبدأیی مشتق می‌شوند که مرورگر کاربران‌تان به آن می‌رسد. اگر سرور پشت یک تونل یا پروکسی معکوس اجرا می‌شود، مطمئن شوید مبدأ پایدار است (تنظیمات → سرور → اتصال و وضعیت → اشتراک این سرور نشانی عمومی را نشان می‌دهد) — یا شناسهٔ موجودیت را به‌صراحت در فیلد شناسهٔ موجودیت SP سنجاق کنید.
4. مشخص کنید یک ورود چه چیزی می‌دهد
بخش با عنوان “4. مشخص کنید یک ورود چه چیزی می‌دهد”دو سیاست تعیین می‌کنند نخستین ورود چه می‌کند:
- افزودن کاربران به همهٔ فضاهای کاری در اولین ورود — برای استقراری تک‌تیمی که SSO در آن برابر با اعتماد است روشن بگذارید. وقتی چند تیم یا مشتری سرور را شریک‌اند خاموشش کنید: آن‌وقت هر تازه‌وارد به یک دعوت صریح فضای کاری نیاز دارد، که پیش‌فرض امن‌تری است.
- تأمین کاربران ناشناخته در اولین ورود — به‌طور پیش‌فرض روشن است؛ خاموشش کنید تا هر کس که حسابش از قبل وجود ندارد رد شود.
به‌صورت اختیاری ویژگی‌ای را که نام گروه‌ها را حمل می‌کند نگاشت کنید (ویژگی
رایج Okta معمولاً groups است) و با همان نگاشت گروه‌ها را به نقش‌ها ترجمه
کنید — برای نمونه {"platform-leads": "admin"}. SSO هرگز نمی‌تواند نقش
مالک را بدهد.
5. آن را فعال کنید و یک ورود انجام دهید
بخش با عنوان “5. آن را فعال کنید و یک ورود انجام دهید”استفاده از SAML برای ورود را روشن کنید، ذخیرهٔ اتصال را بزنید،
سپس یک پنجرهٔ خصوصی مرورگر در https://<your-server>/saml/login باز کنید.
در Okta وارد شوید و به کلاینت وب برمی‌گردید — واردشده، با حسابی که ساخته
شده و عضویتی که بر پایهٔ سیاست انتخابی شما اعطا شده است.
همان نقطهٔ ورود به‌محض این که نشانی سرور را تایپ کنید در صفحهٔ اتصال وب ظاهر می‌شود (ورود با SAML) — فرم خود را با آنچه سرور ارائه می‌دهد وفق می‌دهد (OpenID Connect گزینهٔ ورود با OpenID Connect را نشان می‌دهد). این دکمه ورود را در یک زبانهٔ جدید باز می‌کند؛ وقتی رفت‌وبرگشت کامل شد، زبانهٔ منتظر خودکار نشست را برمی‌دارد. صفحهٔ راه‌اندازی سرور در برنامهٔ دسکتاپ هم همین کار را می‌کند: URL سرور را تایپ کنید، دکمه‌ای با عنوان ورود با SAML ظاهر می‌شود که مرورگر شما را باز می‌کند و برنامه با کامل شدن رفت‌وبرگشت وارد می‌شود.
6. از همین صفحه بررسی‌اش کنید
بخش با عنوان “6. از همین صفحه بررسی‌اش کنید”پیش از این که SSO را همه‌جا به کار بگیرید، یا وقتی یک ورود شکست می‌خورد، قطعه‌ها را همین‌جا بررسی کنید. این بررسی‌کننده کاملاً در مرورگر شما اجرا می‌شود: فراداده‌ای را که در این زبانه جای‌گذاری می‌کنید می‌خواند و همان قواعد سرور را اعمال می‌کند. اگر نشانی سرور را بدهید، از خود آن سرور هم می‌پرسد که آیا ورود SAML روشن است.
چیزهایی را می‌گیرد که آزمایش اتصال در برنامه نمی‌تواند ببیند: گواهی امضایی که نزدیک انقضاست، IdPای که بر درخواست‌های امضاشده پافشاری می‌کند، و با ورود آزمایشی، این که آیا IdP اصلاً Control Center را می‌شناسد.
Runs in your browserYour metadata is read in this tab and never uploaded. Add a server address and your browser also asks that server which sign-in methods it offers.
Test sign-in at your IdP
- Your IdP's sign-in page: it recognizes Control Center's entity ID. You can close the tab.
- An error at your IdP: it names what to fix, usually an unknown entity ID (Entra: AADSTS700016) or a user not assigned to the app.
- Your server's "Sign-in failed" page: also a pass. The IdP accepted the request and posted back to your ACS URL; your server refuses it only because this page started the sign-in, not your server.
گام‌های بعدی
بخش با عنوان “گام‌های بعدی”- چرخهٔ عمر را هم به IdP خود بسپارید: تأمین و لغو تأمین کاربران با SCIM.
- IdP شما به‌جای SAML از OpenID Connect حرف می‌زند؟ اتصال یک ارائه‌دهندهٔ OpenID Connect.
- کنجکاوید رفت‌وبرگشت مرورگر واقعاً چه چیزی را تأیید می‌کند؟ ورود یکپارچه چطور کار می‌کند.