به گزارش از وبسایت redhat 📣

Red Hat Developer Hub (RHDH) از ادغام چند IdPs و ارائه‌دهنده‌های catalog مربوط به آن‌ها برای احراز هویت کاربران از منابع مختلف پشتیبانی می‌کند. هرچند این پیکربندی هنوز به‌صورت رسمی در محصول پشتیبانی نشده یا در اسناد رسمی منتشر نشده، این راهنما شما را در کل فرآیند پیکربندی همراهی کرده و بهترین روش‌ها برای استقرار را پیشنهاد می‌دهد. استقرار موفق با چندین ارائه‌دهنده احراز هویت نیازمند توجه دقیق به تضادهای موجودیت و تضمین ورود ایمن کاربران است. 🔐

مرحلهٔ اول: کاربران و گروه‌های مرتبط را در catalog وارد کنید. ورود داده‌های سازمانی به catalog یک پیش‌نیاز است و از عملکردهای پایهٔ برنامه و افزونه‌ها پشتیبانی می‌کند. این واردسازی اولیه کمک می‌کند تا سیستم بتواند موجودیت‌ها را به‌درستی شناسایی و مدیریت کند. ✅

برای مدیریت تداخل‌ها لازم است نحوهٔ برخورد Developer Hub با entityRef هنگام ورود را به‌خوبی درک کنید. مرجع موجودیت از قالب ساده و ساختاریافتهٔ زیر پیروی می‌کند و metadata موجودیت شامل نوع (kind)، namespace و name است که این مرجع را می‌سازند.

kind:namespace/name
user:default/jessicajhee

قانون «اولین خدمت» (first service): اگر دو ارائه‌دهندهٔ مختلف catalog تلاش کنند یک موجودیت مشابه را با یک entityRef وارد کنند، ارائه‌دهنده‌ای که ابتدا موجودیت را با موفقیت همگام‌سازی کند به‌عنوان ارائه‌دهندهٔ اصلی تعیین می‌شود و اولویت برای تعیین داده‌های آن موجودیت را خواهد داشت. تلاش‌های بعدی سایر ارائه‌دهندگان برای همگام‌سازی همان entityRef شکست می‌خورد و داده‌های آن‌ها (به‌جز داده‌های رابطه‌ای) کنار گذاشته می‌شود. ⚠️

برای جلوگیری از تداخل موجودیت‌ها، باید مطمئن شوید که فیلد شناسه‌ای که برای ساخت entityRef استفاده می‌شود (مخصوصاً metadata.name) در همهٔ ارائه‌دهندگان به‌صورت منحصربه‌فرد تنظیم شده است. به‌طور مثال، شناسه‌های متداول که توسط ارائه‌دهندگان مختلف استفاده می‌شوند عبارتند از: Keycloak → username (برای کاربر) و Group name (برای گروه)، LDAP → uid (برای کاربر) و cn (برای گروه)، MsGraph → normalized email (در صورت وجود). 🔎

ارائه‌دهندگان catalog می‌توانند در روابط موجودیت (relations) هم مشارکت کنند؛ یعنی ممکن است یک کاربر که توسط یک ارائه‌دهنده وارد شده عضو گروهی باشد که توسط ارائه‌دهندهٔ دیگری وارد شده است و در نتیجه عضویت (relation) ایجاد می‌شود. برای نمونه، فرض کنید GitHub به‌عنوان ارائه‌دهندهٔ اصلی انتخاب شده، اما یک کاربر با همان entityRef عضوی از گروهی است که توسط Keycloak تعریف شده است. نمونهٔ تعریف گروه Keycloak می‌تواند به شکل زیر باشد:

apiVersion: backstage.io/v1alpha1
kind: Group
metadata:
  name: keycloak-group
spec:
  members:
    - jessicajhee

در این حالت، رابطه از موجودیت گروه Keycloak به کاربر ایجاد می‌شود و موجودیت نهایی کاربر ممکن است هر دو عضویت را داشته باشد، مثلاً GitHub-group و Keycloak-group، که نمونهٔ نهایی کاربر می‌تواند به شکل زیر وارد شود:

kind: User
metadata:
  name: jessicajhee
relations:
  - type: MemberOf
    targetRef: group:default/keycloak-group
  - type: memberOf
    targetRef: group:default/github-group
spec:
  MemberOf:
    - github-group

نکتهٔ سریع: برای دیدن YAML خام هر موجودیت می‌توانید از رابط کاربری Developer Hub روی سه‌نقطه بالای صفحه کلیک کرده، گزینهٔ Inspect entity را انتخاب و به نمای Raw YAML بروید تا محتوای کامل را ببینید. 🧾

نظارت بر هشدارهای تضاد: وقتی تداخلی در backend شناسایی شود، ارائه‌دهندهٔ ثانویه هشداری صادر می‌کند. این هشدارها را می‌توانید در لاگ‌های Developer Hub ببینید؛ هشدار به‌وضوح entityRef در تضاد و نام دو ارائه‌دهنده را مشخص می‌کند تا بتوانید منشا مشکل را پیگیری کنید. 📢

به‌صورت پیش‌فرض، ارائه‌دهندگان catalog در Developer Hub به‌طور هم‌زمان اجرا می‌شوند. برای جلوگیری از درگیری‌های غیرمنتظره، توصیه می‌شود اجرای ارائه‌دهندگان را به‌صورت متوالی پیکربندی کنید؛ به‌عنوان مثال، برای ارائه‌دهندهٔ اصلی (مثل GitHub) یک initial delay کمتر یا صفر و برای ارائه‌دهندهٔ ثانویه (مثل Keycloak) یک مقدار delay بزرگ‌تر در فایل app-config.yaml تنظیم کنید تا GitHub ابتدا همگام‌سازی شود و سپس Keycloak اجرا شود. ⚙️