كيف تُعِدّ SSO وSCIM

سألك عميلك المؤسسي للتوّ ما إن كانت أداتك للمشاريع تدعم SSO وSAML وSCIM قبل أن يوقّع، و«ربما» لن تفي بالغرض. فريق أمنه يريد الموظفين يسجّلون الدخول عبر مزوّد هوية الشركة. يريدون من يغادر الشركة أن يفقد الوصول من دون أن يفتح أحد تذكرة. ويريدون دليلًا على أن الأمرين موصولان فعلًا، لا موعودان. هذه تحديدًا اللحظة التي تصمت فيها كثير من أدوات المشاريع، وتومض بزر «اتصل بالمبيعات»، فيتسرّب الاتفاق أسبوعين.

لا يتوقّف Taskfolk هنا. إعداد SSO وSAML وSCIM لإدارة المشاريع كله يعيش في تبويب إعدادات واحد، ويستطيع مالك مساحة عمل أو مسؤول أن يوصل الأمر كله في نحو الوقت الذي يستغرقه نسخ حفنة قيم من Okta أو Azure AD. هذا الدليل يمشي بك عبر الثلاثة، ويخبرك أي رابط يذهب أين، ويبقى صريحًا بشأن الحواف: ما يفعله Taskfolk، وما لا يفعله عمدًا، وما لا ينبغي أن تعِد به فريق أمنك من دون تحقّق أولًا.

اضبط النموذج الذهني صحيحًا قبل أن تمسّ أي شيء. يوفّر عليك ساعةً من الالتباس لاحقًا.

ما الذي تفعله SSO وSAML وSCIM فعلًا لمساحة عملك

هذه الاختصارات الثلاثة تسافر معًا على كل قائمة مشتريات، لكنها تجيب عن سؤالين منفصلين.

	السؤال الذي تجيب عنه	البروتوكولات في Taskfolk
SSO	من هذا الشخص، وهل يستطيع تسجيل الدخول؟	OIDC وSAML 2.0
SCIM	أي الأشخاص ينبغي أن يوجدوا هنا، وكيف تبقى القائمة مطابقةً للدليل؟	SCIM 2.0 (المستخدمون فقط)

SSO (الدخول الموحّد) عن المصادقة. يتحدّث Taskfolk نكهتين. OIDC (OpenID Connect) هو البروتوكول الحديث JSON-فوق-HTTPS الذي يفترضه معظم مزوّدي الهوية الجدد. SAML 2.0 هو معيار XML الأقدم الذي شغّلته المؤسسات الكبيرة على مستأجري Okta وAzure AD وOneLogin لسنوات. كلاهما يؤدي العمل نفسه. حين يحاول أحدهم تسجيل الدخول، يسلّمه Taskfolk إلى مزوّد هويتك، ويفحص مزوّدك بيانات اعتماده، ويعيد إجابةً موقّعة: نعم، هذا [email protected]، وهي شرعية، فأدخِلها.

SCIM (نظام إدارة الهوية عبر النطاقات) عن التزويد. حين تضيف الموارد البشرية أحدهم إلى مجموعة الهندسة في دليلك، يستطيع SCIM إنشاء حساب Taskfolk الخاص به. وحين يغادر ذلك الشخص ويُعطَّل في الدليل، يزيله SCIM من مساحة العمل. إنه يغطّي نصف «ابقَ متزامنًا» الذي لا يستطيعه الدخول وحده.

المشتري المؤسسي يريد الثلاثة لأن كلًّا يسدّ ثغرةً مختلفة. SSO يعني دخولًا واحدًا وبلا كلمة مرور منفصلة تجلس لتُسرَّب. SCIM يعني أن إنهاء الوصول يحدث تلقائيًا بدلًا من العيش على قائمة ينساها أحدهم يوم جمعة. مجتمعةً، هي الخط الفاصل بين «نثق بتطبيقك على وصول الموظفين» و«لا نثق».

في Taskfolk، الثلاثة تجلس في مكان واحد: الإعدادات > SSO، مرئية للمالكين والمسؤولين في مساحة العمل فقط. وإليك أول شيء تسمّيه بصوت عالٍ، لأنه يشكّل كل قرار لاحق: الدخول بالرابط السحري يبقى يعمل طوال الوقت. تشغيل SSO لا يطفئ رابط البريد بلا كلمة مرور. ذلك حدّ حقيقي بعواقب حقيقية، وسأعود إليه في النهاية. أمسك الفكرة الآن.

قبل أن تبدأ: من يستطيع إعداد هذا، وما تحتاجه من مزوّد هويتك

شرطان مسبقان. ثبّتهما قبل أن تفتح التبويب.

أولًا، الصلاحيات. تبويب SSO للمالك والمسؤول فقط. مقيّد بصلاحية workspace.edit_settings، ما يعني أن الأعضاء والمشاهدين لا يرونه أبدًا. التبويب مخفيّ من شريط إعداداتهم، وإن لصقوا الرابط مباشرةً أُعيد توجيههم بعيدًا. فإن كنت تهيّئ هذا لعميل، تأكّد أن من يفعله مالك أو مسؤول لتلك المساحة تحديدًا. لا مسؤول مشروع. مسؤول مساحة عمل.

ثانيًا، القيم من مزوّد هويتك. ما تحتاجه يعتمد على أي بروتوكول تُعِدّ، وتستطيع فعل واحد أو الاثنين.

لـOIDC، ثلاثة أشياء من مزوّد هويتك، تُجمَع بتسجيل Taskfolk كتطبيق في وحدة تحكم المزوّد الإدارية:

• Issuer URL (الرابط الأساسي لمزوّدك، مثل https://your-org.okta.com)
• Client ID
• Client secret

لـSAML، ثلاثة أشياء مختلفة:

• entity ID لمزوّد هويتك
• sign-in URL الخاص به (حيث ينبغي أن يرسل Taskfolk الناس ليصادقوا)
• signing certificate بصيغة PEM (الشهادة العامة التي يستخدمها مزوّدك لتوقيع التأكيدات، فيستطيع Taskfolk إثبات أنها أصيلة)

تفصيل بيئة يمسك الناس في الاختبار: الإنتاج يتطلّب HTTPS لروابط المُصدِر وSSO. الـhttp:// العادي مقبول فقط لـlocalhost في التطوير. الصق رابط إنتاج http:// ولن يُقبَل.

اختر OIDC أو SAML بناءً على ما يفعله مزوّدك أفضل. معظم الإعدادات الحديثة تمدّ يدها إلى OIDC لأنه حقول أقل للتهيئة. كثير من المؤسسات الكبيرة توحّد على SAML لأن ذلك ما تتحدّثه بقية منظومتها أصلًا. تستطيع تمكين الاثنين، لكن اعلم أن نقطة الدخول ذاتية-الكشف تفضّل OIDC حين يكون الاثنان مشغّلين. لا يوجد منتقٍ لكل مستخدم «دعني أختار SAML اليوم».

تلك اللوحة الواحدة هي حيث يحدث كل هذا. ثلاثة أقسام مكدّسة، ولكل واحد مسار حفظ. الآن لنملأها.

أعِدّ الدخول الموحّد بـOIDC (المسار الأقصر)

إن كان مزوّدك يتحدّث OIDC، ابدأ هنا. حقول أقل، وهو الذي أمدّ يدي إليه أولًا.

افتح الإعدادات > SSO وابحث عن قسم الدخول الموحّد (SSO). أول ما تلاحظه: حسب Taskfolk لك مسبقًا رابطين في الأعلى، حيث {slug} هو معرّف مساحة عملك في الرابط. هذه قيم يحتاج مزوّد هويتك معرفتها عن Taskfolk، لا العكس.

القيمة في Taskfolk	المسار	إلى أين تذهب
Redirect URL	/sso/{slug}/callback	حقل إعادة التوجيه أو استدعاء URI في تطبيق مزوّد هويتك
Sign-in URL	/sso/{slug}/login	أي مكان تريد فيه رابط دخول SSO مباشرًا

فالترتيب يهمّ. انسخ تلك الروابط إلى تطبيق مزوّد هويتك أولًا. حين تُنشئ تكامل التطبيق لـTaskfolk في Okta أو Azure AD، يطلب إعادة توجيه أو استدعاء URI. الصق Redirect URL هناك. ذلك هو العنوان الذي يعيد إليه مزوّدك المستخدم بعد أن يصادق. سجّله قبل أن تنهي جانب Taskfolk، وإلا ارتدّت أول محاولة اختبار للدخول بعدم تطابق إعادة توجيه، وهي أشيع فشل إعداد OIDC وواحدة مزعجة فعلًا لتصحيحها بلا رؤية.

حالما يُسجَّل Taskfolk في مزوّد هويتك، عد واملأ الحقول في الاتجاه الآخر. الصق Issuer URL وClient ID وClient secret. يُخزَّن السرّ مشفّرًا، وبعد أن تحفظ، تُقرأ التسمية «سرّ مُهيّأ» بدلًا من إعادة صدى القيمة. ذلك متوقّع. إن احتجت يومًا تغييره، تعيد إدخاله؛ لن يريك Taskfolk المخزّن.

هناك حقل اختياري هنا أيضًا: نطاق البريد المسموح (اختياري). اتركه فارغًا الآن إن أردت مرور أي بريد موثَّق. سأغطّي لماذا تضبطه في قسم لاحق.

اضغط حفظ التهيئة أولًا. ثم اقلب تمكين الدخول بـSSO. هذا الترتيب من خطوتين (احفظ، ثم مكّن) مقصود. يتيح لك تحضير التهيئة وتشغيلها كفعل منفصل واعٍ، فلا تكون أبدًا نصف-مهيّأ وتقبل بالخطأ دخولات حقيقية.

شيء عن كيف يتصرّف استدعاء OIDC، لأنه سيمسكك إن كان دليلك فوضويًا: الاستدعاء يشترط بصرامة email_verified === true. إن أعاد مزوّد هويتك مستخدمًا بريده غير موسوم موثَّقًا، رفض Taskfolk الدخول. ذلك قرار أمني، لا خلل. يمنع أحدهم من دخول مساحة عمل على عنوان غير موثَّق أو قابل للانتحال. حين يُحجَب شخص حقيقي، الإصلاح في دليلك (وسِم بريده موثَّقًا هناك)، لا في Taskfolk.

كيف تبدو الحالة الجيدة: مبدّل التمكين مشغّل، وأول مرة يجري موظف حقيقي اختبار دخول، يُنشئه Taskfolk في الحال عضوًا في هذه المساحة الواحدة ويُسقطه على اللوحة. بلا بريد دعوة، بلا إضافة يدوية. يصادق مقابل مزوّد هويتك، فيدخل.

أعِدّ SAML 2.0 لـOkta أو Azure AD أو OneLogin

التبويب نفسه، القسم التالي: الدخول الموحّد بـSAML. هذا مسار إعداد SAML 2.0 الكلاسيكي الذي دعمه Okta وAzure AD وOneLogin لسنوات.

النمط يطابق OIDC: انسخ قيم Taskfolk المحسوبة إلى مزوّد هويتك، ثم الصق قيم مزوّدك عائدًا. القيم المحدّدة وحدها بنكهة SAML. في أعلى القسم يعطيك Taskfolk ثلاثًا منها:

القيمة في Taskfolk	المسار	ما هي
ACS (reply) URL	/sso/{slug}/saml/acs	حيث يرسل مزوّد هويتك التأكيد الموقّع بـPOST بعد المصادقة
SP entity ID (audience)	/sso/{slug}/saml/metadata	معرّف Taskfolk كمزوّد خدمة، الجمهور الذي يقصده التأكيد
SAML Sign-in URL	/sso/{slug}/saml/login	نقطة دخول SAML المباشرة

كلٌّ من ACS URL وSP entity ID يذهب إلى تطبيق Taskfolk الذي تُنشئه في مزوّد هويتك.

إليك لطفًا يوفّر كثيرًا من الكتابة اليدوية: يقدّم Taskfolk بيانات SP الوصفية XML على /sso/{slug}/saml/metadata. معظم مزوّدي الهوية يتيحون تسجيل مزوّد خدمة بلصق رابط بيانات وصفية بدلًا من إدخال كل حقل يدويًا. وجّه Okta أو Azure AD أو OneLogin إلى نقطة البيانات الوصفية تلك فيقرأ القيم الصحيحة لك. تعلن البيانات الوصفية WantAssertionsSigned=true (يصرّ Taskfolk على تأكيدات موقّعة)، وربط HTTP-POST للـACS، وصيغة NameID من نوع emailAddress. تلك الأخيرة تهمّ للفقرة التالية.

الآن الصق قيم مزوّدك في Taskfolk: IdP entity ID، وIdP sign-in URL، وIdP signing certificate كنصّ PEM. بعد الحفظ، يُقرأ حقل الشهادة «شهادة مُهيّأة» بدلًا من إظهار الشهادة، النمط نفسه لسرّ OIDC. حقل نطاق البريد المسموح الاختياري نفسه يعيش هنا أيضًا.

احفظ، ثم اقلب تمكين الدخول بـSAML.

الشرط الصارم الوحيد: يجب أن يحمل تأكيد SAML عنوان بريد. إما كـNameID (وهذا سبب أهمية صيغة NameID من نوع emailAddress) أو كسمة بريد في التأكيد. إن أعاد مزوّدك اسم مستخدم أو معرّفًا مبهمًا بلا بريد مرفق، فلا شيء لدى Taskfolk يفهرس المستخدم عليه، ويفشل الدخول. في Okta وAzure AD هذا مجرد تخطيط بريد المستخدم إلى بيان سمات SAML، وهو ما تجعله معالجات إعدادهما بلا ألم. تحقّق منه قبل أن تخبر أحدًا أنه يعمل.

أعِدّ التزويد بـSCIM فيبقى دليلك متزامنًا

المصادقة مُنجَزة. الآن نصف «أبقِ السجلّ مطابقًا»: التزويد بـSCIM، القسم الثالث في التبويب نفسه.

ابدأ بالرمز. انقر توليد رمز فيسكّ Taskfolk رمز Bearer. اقرأ هذه الجملة مرتين: يُعرَض الرمز مرةً واحدة بالضبط. يخزّن Taskfolk تجزئة SHA-256 له فقط، لا الرمز نفسه، فلا يوجد زر «أظهره مجددًا» أي مكان في المنتج. وهو على الشاشة، استخدم نسخ الرمز والصقه مباشرةً في تهيئة موصّل SCIM لمزوّد هويتك. أغلق الحوار من دون نسخه فيختفي؛ ومسارك الوحيد للأمام هو تدوير الرمز لسكّ واحد جديد (ما يُبطِل القديم).

تاليًا، انسخ SCIM base URL (/scim/v2). هذه النقطة التي يتحدّث معها موصّل SCIM لمزوّدك. في إعداد تزويد Okta أو Azure AD، تلصق هذا الرابط الأساسي ورمز Bearer معًا؛ ذلك الزوج هو كيف يصادق دليلك لدى Taskfolk. كل عملية SCIM مقصورة على مساحة العمل التي يملكها الرمز، فرمز مساحة عملك لا يستطيع أبدًا الوصول إلى مساحة أحد آخر.

ثم اقلب تمكين التزويد بـSCIM. قبل وجود رمز، يُقرأ القسم «لم يُولَّد رمز بعد.» حالما ولّدت ومكّنت، يُقرأ «رمز مُهيّأ.» تلك القلبة تأكيدك أن الاتصال مُسلَّح.

موصّل مزوّد هويتك يؤدي كل حركة SCIM عنك، لكن تستطيع التحقّق من الوصل بنفسك بطلب واحد. ابحث عن عضو بالبريد، تمامًا كما يفعل الموصّل قبل أن يقرّر إنشاء أحدهم أو تحديثه:

curl -G "https://taskfolk.ai/scim/v2/Users" \
  -H "Authorization: Bearer utscim_your_token_here" \
  --data-urlencode 'filter=userName eq "[email protected]"'

const params = new URLSearchParams({ filter: 'userName eq "[email protected]"' });
const res = await fetch(`https://taskfolk.ai/scim/v2/Users?${params}`, {
  headers: { Authorization: "Bearer utscim_your_token_here" },
});
console.log(await res.json());

import requests

r = requests.get(
    "https://taskfolk.ai/scim/v2/Users",
    headers={"Authorization": "Bearer utscim_your_token_here"},
    params={"filter": 'userName eq "[email protected]"'},
)
print(r.json())

استجابة سليمة تعود بـapplication/scim+json بغلاف ListResponse القياسي:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 1,
  "startIndex": 1,
  "itemsPerPage": 1,
  "Resources": [
    {
      "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
      "id": "<user-id>",
      "userName": "[email protected]",
      "displayName": "Jane Doe",
      "emails": [{ "value": "[email protected]", "primary": true, "type": "work" }],
      "active": true
    }
  ]
}

تحت السطح، يكشف Taskfolk نقاط اكتشاف SCIM القياسية (ServiceProviderConfig وResourceTypes وSchemas) فيستطيع Okta وAzure AD وOneLogin سبر ما يدعمه Taskfolk قبل أن يدفعوا أي بيانات. موصّلاتهم تطرقها تلقائيًا. GET /scim/v2/ServiceProviderConfig يجيب برايات قدرة كهذه (مقلّمة):

{
  "patch": { "supported": true },
  "bulk": { "supported": false },
  "filter": { "supported": true, "maxResults": 200 },
  "changePassword": { "supported": false },
  "sort": { "supported": false },
  "etag": { "supported": false }
}

هكذا يتعلّم المزوّد أن Taskfolk يدعم PATCH وترشيح المساواة على userName، ولا يدعم العمليات المجمّعة، أو الفرز، أو etags، أو تغيير كلمة المرور. لا تمسّ هذه النقاط بنفسك أبدًا؛ إنها هناك ليعمل التصافح.

كيف يسجّل المستخدمون الدخول فعلًا، وكيف ينشئهم التزويد

أنجزت جانب مساحة العمل. إليك التجربة من الطرف الآخر، لمن يسجّلون الدخول فعلًا.

يذهب الموظف إلى /login. الرابط السحري ما زال الخيار الأساسي والأبرز (ذلك التعايش مجددًا). تحته يجلس رابط الدخول بـSSO. ينقره، فيظهر حقل رابط مساحة العمل يطلب معرّف مساحة العمل (الاسم القصير في رابط مساحة عملك)، فيكتبه، وينقر متابعة.

يوجّهه ذلك إلى /sso/{slug}، حيث يكشف Taskfolk تلقائيًا أي بروتوكول ممكّن لتلك المساحة. OIDC مشغّل؟ يستخدم OIDC. SAML وحده مشغّل؟ يستخدم SAML. الاثنان مشغّلان؟ يفضّل OIDC. لا يختار المستخدم أبدًا؛ يُحوَّل إلى المسار الصحيح، ويصادق مع مزوّدك، ويعود مسجّل الدخول. هناك رابط رجوع لحين يخطئ كتابة المعرّف.

sequenceDiagram
    participant E as Employee
    participant U as Taskfolk
    participant I as Identity provider
    E->>U: Sign in with SSO plus workspace slug
    U->>U: Auto detect protocol, OIDC preferred
    U->>I: Redirect to sign in
    I->>I: Check credentials
    I->>U: Signed response to callback or ACS
    U->>U: Verify email, JIT provision if new
    U->>E: Signed in as a member

سلوك التزويد هو الجزء الذي يستحق الاستيعاب. مستخدم SSO لأول مرة، من لم يكن له حساب Taskfolk قط، يُزوَّد في الحال: يُنشئ Taskfolk المستخدم ويضيفه إلى تلك المساحة الواحدة عضوًا. بلا دعوة سابقة. يصادق، فيوجد، فيدخل، عضوًا.

يغطّي SCIM دورة الحياة الأوفى من جانب دليلك:

• الإنشاء (طلب SCIM POST من مزوّد هويتك) يزوّد العضوية في الحال، مثل دخول JIT.
• إلغاء التزويد يحدث بثلاث طرق: ضبط active=false، أو PATCH يعطّل، أو DELETE. أيٌّ منها يزيل عضوية الشخص في مساحة العمل.
• القراءة طلب SCIM GET لسرد الأعضاء أو جلب واحد.
• الترشيح مطابقة مساواة على userName، وهو كيف يبحث مزوّدك عن مستخدم قبل أن يقرّر إنشاءه أو تحديثه.

flowchart LR
    A[Directory change] --> B{What happened}
    B -->|User added| C[SCIM POST creates the membership]
    B -->|User deactivated| D[PATCH sets active false]
    B -->|User removed| E[DELETE drops the membership]
    C --> F[Workspace roster matches the directory]
    D --> F
    E --> F

التعطيل الذي يرسله مزوّد هويتك حين يغادر أحدهم يبدو هكذا على السلك:

curl -X PATCH "https://taskfolk.ai/scim/v2/Users/<user-id>" \
  -H "Authorization: Bearer utscim_your_token_here" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{ "op": "replace", "path": "active", "value": false }]
  }'

تلك الاستدعاءة الواحدة تزيل عضوية الشخص في مساحة العمل التي يملكها الرمز، وهناك فقط.

لأي أحد لا يمرّ عبر SSO، يعمل مسار الدعوة العادي تمامًا كما قبل. انظر كيف تدعو أعضاء الفريق للمسار القائم على الرابط. SCIM والدعوات يتعايشان بسعادة في مساحة العمل نفسها.

قيّد الدخول بنطاق شركتك وأبقِ أثر تدقيق

أمران يحوّلان إعدادًا يعمل إلى إعداد يُدافَع عنه.

أولًا، حقل نطاق البريد المسموح (اختياري)، الذي يظهر على قسمَي OIDC وSAML معًا. اضبطه على نطاق شركتك، لنقل example.com، فيقبل Taskfolk دخولات SSO فقط لبريد على ذلك النطاق. اتركه فارغًا فيُقبَل أي بريد موثَّق أو مؤكَّد.

لماذا تتكبّد العناء؟ لأن مزوّد هوية مهيّأ بتساهل، أو واحدًا يستطيع تأكيد بريد ضيوف خارجيين، قد يُدخِل إلى مساحة العمل من لم تقصد قبوله قط. تثبيت النطاق حاجز رخيص ومقروء: @example.com من البشر وحدهم يدخلون عبر SSO. لمساحة عمل مربوطة بشركة واحدة، اضبطه. قلّما يوجد سبب لعدم فعله.

ثانيًا، أثر التدقيق، وهو ما تسلّمه لمراجع الأمن حين يسأل «من غيّر مصادقة مؤسستنا، ومتى». كل تغيير تهيئة يُكتَب إلى سجل تدقيق مساحة العمل:

• sso_configured وsso_enabled وsso_disabled وsso_deleted، إضافةً إلى أحداث saml_* الموازية
• scim_token_rotated وscim_enabled وscim_disabled
• الأحداث البشرية التي تهمّ: member.joined_via_sso حين يُزوَّد أحدهم في الحال، وmember.removed_via_scim حين يلغي دليلك تزويد أحدهم

فالقوس كله مسجّل: المسؤول الذي شغّل SAML، وتدوير الرمز الفصل الماضي، والمتعاقد المُزال تلقائيًا حين عطّلته الموارد البشرية. إن كنت تبني الحجّة على أن Taskfolk آمن لتسليمه وصول الموظفين، فهذا السجل دليلك. لكيفية قراءته واستخدامه، انظر الاحتفاظ بأثر تدقيق للتغييرات.

الحدود التي تستحق المعرفة قبل أن تعِد بهذا للأمن

أفضل أن تسمعها مني الآن من أن تسمعها من مراجع أمن منزعج بعد توقيع العقد. لا شيء منها مختلق. إنه كيف تُطلَق الميزة اليوم.

الرابط السحري لا يُطفأ أبدًا. هذه الكبرى. لا يوجد مبدّل «اشترط SSO» ولا مبدّل «عطّل الرابط السحري». SSO وSAML وSCIM كلها تعمل جنبًا إلى جنب مع الدخول بالبريد بلا كلمة مرور، لا بدلًا منه. لا تستطيع فرض SSO كطريقة الدخول الوحيدة. إن كان مطلب فريق أمنك حرفيًا «يجب أن يصادق الموظفون عبر Okta ولا شيء غيره»، فإن Taskfolk لا يفي به اليوم. أي أحد يستطيع تلقّي بريد على عنوان في مساحة العمل ما زال يستطيع طلب رابط سحري. اطرح هذا على الطاولة أثناء الاتفاق؛ لا تدعه يطفو بعد التوقيع.

لا يوجد تخطيط أدوار. كل مستخدم SSO مُزوَّد في الحال ينضمّ عضوًا. لا يقرأ Taskfolk مجموعات مزوّد الهوية ويخطّطها إلى أدوار، ولا يزامن المجموعات إطلاقًا، وSCIM يتعامل مع مورد المستخدم فقط. لا يوجد مورد مجموعات SCIM. فـ«ضع الناس في مجموعة الهندسة في AD فيصبحون مسؤولي مشاريع في Taskfolk» ليس شيئًا يحدث. بعد أن يُزوَّد أحدهم، يغيّر مالك أو مسؤول دوره يدويًا داخل Taskfolk إن احتاج أكثر من عضو.

حذف تهيئة يطفئ الميزة لكن لا يحبس أحدًا خارجًا. استخدم حذف التهيئة (هناك حوار تأكيد، فلن تمحوها بالخطأ) فيتوقّف SSO عن العمل، لكن الأعضاء الحاليين يحتفظون بوصول الرابط السحري. حذف SSO ليس أداة إنهاء وصول.

SCIM بسيط عمدًا. لا عمليات مجمّعة، ولا فرز، ولا etags، ولا تغيير كلمة مرور. الترشيح مساواة على userName فقط. والمالك الأخير لمساحة عمل لا يمكن إلغاء تزويده؛ يرفضه SCIM، فلا تستطيع تيتيم مساحة عمل بتعطيل مالكها الوحيد في دليلك. قيود عاقلة، لكن إن كان موصّل مزوّد هويتك يتوقّع مجمّعًا أو فرزًا، اعلم أن Taskfolk يرفض تلك وينبغي أن يرتدّ الموصّل إلى عمليات لكل مستخدم.

عن الخطط والتسعير، صُغ الأمر بعناية. كما هو مُطلَق، تهيئة SSO وSAML وSCIM مقيّدة بدور مساحة العمل، مالك أو مسؤول، لا بخطة مدفوعة مفحوصة. أي مالك أو مسؤول مساحة عمل يستطيع تشغيله. هناك راية ميزة sso محجوزة في تهيئة الخطة، وقد وصفت بعض مواد المنتج SSO كميزة من فئة Business، لكن لا فحص خطة يعمل فعلًا في مسارات كود SSO أو SAML أو SCIM الآن. فحين يسأل عميل «هل عليّ الترقية لتهيئة SSO»، الإجابة الصادقة كما هو مُطلَق هي لا، البوابة دورك، لا خطتك. قد يتغيّر ذلك، فإن كان التقييد بالخطة يهمّ اتفاقًا، تأكّد منه مقابل فوترتك الحالية بدلًا من اقتباس هذه المقالة. (عن السؤال المتّصل بما إن كان مستخدمو SSO يحرقون مقاعد مدفوعة، انظر هل تُحسب وكلاء الذكاء الاصطناعي كمقاعد لكيف يفكّر Taskfolk بمن يُحسَب.)

تلك الصورة الكاملة، بعيوبها. للفرق التي تريد دخولًا واحدًا عبر مزوّد هويتها الحالي، وإنهاء وصول تلقائيًا حين يغادر أحدهم الدليل، وسجلًا نظيفًا لمن غيّر ماذا، فإن دخول Taskfolk المؤسسي يؤدي العمل في تبويب إعدادات واحد، بلا مكالمة مبيعات ولا مشروع تكامل مفصّل. ادخل واضح العينين بشأن تعايش الرابط السحري والتزويد بالعضوية فقط، وستضبط توقّعات عميلك صحيحةً من أول مرة.

إن كنت توازن بين Taskfolk وأداة أثقل لهذا النوع تحديدًا من المتطلّب المؤسسي، فإن مقارنة Taskfolk مقابل Jira تبيّن أين تقع كل واحدة.

جاهز للوصل؟ افتح تبويب الإعدادات > SSO لمساحة عملك وانسخ ذلك Redirect URL الأول إلى مزوّد هويتك.