سنگل سائن اَن

سنگل سائن اَن کسی بیرونی شناختی فراہم کنندہ (IdP) کو یہ فیصلہ کرنے دیتا ہے کہ آپ کے Control Center سرور پر کون سائن اِن کر سکتا ہے۔ دو پروٹوکول معاون ہیں — SAML 2.0 اور OpenID Connect — اور دونوں ایک ہی جگہ پہنچتے ہیں: ایک تازہ جاری کردہ ڈیوائس اسناد، جو آگے کی ہر سطح پر دعوت یا QR پیئرنگ سے الگ پہچانی نہیں جا سکتی۔

سائن اِن کی صورت

SAML لاگ اِن براؤزر کے ذریعے ہوتے ہیں۔ IdP آپ کے سرور سے کبھی کنیکشن نہیں کھولتا؛ سب کچھ صارف کا براؤزر اُٹھائے چلتا ہے:

browser ──> /saml/login ──> IdP ──POST SAMLResponse──> /saml/acs
                                                          │  verify
                                                          ▼
                                              provision user (maybe)
                                                          │
                                                          ▼
                                  browser handoff: device PSK in the URL
                                  fragment (never a query parameter)

چونکہ براؤزر ہی قاصد ہے، اس لیے لاگ اِن کے لیے NAT کے پیچھے والا سرور بھی ٹھیک کام کرتا ہے: localhost، LAN، Tailscale، VPN یا کوئی ٹنل — سب کام دے جاتے ہیں؛ صرف صارف کے براؤزر کو ACS URL تک پہنچنا ضروری ہے۔ فون ریموٹ کنٹرول کا استعمال کردہ WebSocket ریلے یہ HTTP راؤنڈ ٹرپ نہیں اُٹھا سکتا، اسی لیے SSO انٹری پوائنٹس ہمیشہ سرور کے HTTP اوریجن کو نشانہ بناتے ہیں۔

OpenID Connect یہی صورت اختیار کرتا ہے، مگر ایک authorization-code + PKCE راؤنڈ ٹرپ کے ساتھ؛ کلیمز TLS کے اوپر جاری کنندہ کے ٹوکن اینڈ پوائنٹ سے پڑھے جاتے ہیں، اس لیے براؤزر شناخت کا کوئی ڈیٹا سرے سے فراہم ہی نہیں کرتا۔

اڈاپٹرز

Control Center ذمہ داری جان بوجھ کر تقسیم کرتا ہے:

جزو	کہاں	کیا سنبھالتا ہے
cc_saml native	packages/cc_natives/native/saml/	XML-DSig کی تصدیق، کینونیکلائزیشن، SAML پروفائل کی توثیق — ایک اسٹیٹ لیس C ABI کے پیچھے پن شدہ خالص-Rust saml کریٹ کے سپرد
SamlService / OidcService	cc_server_core	لاگ اِن اسٹیٹ (زیر التواء درخواست ٹریکرز، ری پلے ڈی ڈوپ)، توثیق کی پالیسی کے نوبس، مشترکہ پروویژنگ کال
SsoProvisioner	cc_server_core	صارف کو ڈھونڈنا-یا-بنانا، فراہم کنندہ کا سبجیکٹ پن کرنا، آٹو-ممبر پالیسی کے تحت رکنیتیں دینا
ScimService	cc_server_core	SCIM 2.0 کی پش سطح (پروویژن/ڈی پروویژن لائف سائیکل)
SsoSettingsService	cc_server_core	محفوظ شدہ کنیکشن قطاریں، لائیو ری اپلائی، SCIM ٹوکن

جان بوجھ کر خالص-Dart پر کوئی SAML کرپٹو فال بیک نہیں ہے: ہاتھ سے بنائی گئی XML-DSig/کینونیکلائزیشن ہی وہ جگہ ہے جہاں سگنیچر ریپنگ کی کمزوریاں رہتی ہیں، اس لیے cc_saml لائبریری کی عدم موجودگی SAML سائن اِن اور سرور بوٹ، دونوں سے انکار کر دیتی ہے۔ نیٹو ڈیزائن ہی سے اسٹیٹ لیس ہے — درخواستوں کے پار کی اسٹیٹ Dart سروسز میں رہتی ہے، یک بار استعمال اور قلیل مدت۔

سائن اِن کس چیز کی تصدیق کرتا ہے

تصدیق شدہ نیٹو اور سروس کے اندر، ترتیب سے:

1. ایسرشن کا دستخط (ہمیشہ لازمی؛ ریسپانس لفافے کا دستخط کنفیگریشن کے مطابق اختیاری ہے) — سگنیچر ریپنگ کے خلاف ساختی طور پر مزاحم، کیونکہ توثیق شدہ پے لوڈ تصدیق شدہ عنصر سے بندھا ہوتا ہے،
2. جاری کنندہ کنفیگر شدہ IdP سے مماثل ہو،
3. مخاطب اسی سروس پرووائیڈر کا نام لے،
4. منزل ہمارا ACS URL ہو،
5. InResponseTo ہماری جاری کردہ کسی زیر التواء AuthnRequest سے مماثل ہو (غیر طلب شدہ، IdP سے شروع ہونے والے ریسپانسز بطور ڈیفالٹ بند ہیں)،
6. مدتِ کار کی کھڑکیاں کلاک اسکیو (ڈیفالٹ 90s) کے اندر رہیں، اور
7. ایسرشن ID پہلے کبھی نہ دیکھا گیا ہو (ری پلے کیش)۔

ناکامیاں ٹائپ شدہ کوڈز کی صورت میں واپس آتی ہیں — دستخط، میعاد ختم، مخاطب، منزل، جاری کنندہ، درخواست کی مماثلت — اور اینڈ پوائنٹس جنرک غلطیاں واپس کرتے ہیں، تاکہ کوئی حملہ آور یہ نہ جان سکے کہ جعل سازی کیوں ناکام ہوئی۔

اکاؤنٹس اور سبجیکٹ پننگ

پہلا SSO لاگ اِن فراہم کنندہ کے ناقابلِ تغیر سبجیکٹ (issuer کے ساتھ SAML NameID / OIDC sub، یا SCIM externalId) کو اکاؤنٹ پر پن کر دیتا ہے۔ اُس کے بعد لاگ اِن کی شناخت سبجیکٹ سے ہوتی ہے، ای میل سے نہیں۔ اگر کوئی اور بعد میں وہی ای میل اسی یا کسی دوسرے IdP سے پیش کرے، تو پن شدہ اکاؤنٹ اُسے مسترد کر دیتا ہے۔ یہی چیز روکتی ہے کہ کسی فراہم کنندہ پر ری سائیکل شدہ ای میل اکاؤنٹ ٹیک اوور بن جائے۔

پروویژنگ اور ڈی پروویژنگ

JIT پروویژنگ لاگ اِن کے وقت ہوتی ہے (SsoProvisioner)۔ SCIM ایک الگ پش سطح ہے (ScimService) جو صارف کی قطار پر وہی سبجیکٹ پن کرتی ہے؛ یہ ورک اسپیس کی رکنیتیں نہیں دیتی۔ ڈی پروویژننگ — SCIM active: false یا DELETE — انکار کر دیتی ہے اگر اکاؤنٹ کسی ورک اسپیس کا مالک ہو (پہلے منتقلی کریں)۔ ورنہ یہ پہلے ہر ڈیوائس اسناد منسوخ کرتی ہے (ڈیوائس واچ کے ذریعے سیشنز سیکنڈوں میں گر جاتے ہیں)، ہر ورک اسپیس کی رکنیت ہٹاتی ہے اور اکاؤنٹ کو غیر فعال نشان زد کر دیتی ہے۔ صارف کی قطار برقرار رہتی ہے: انتساب دائمی ہے۔ دوبارہ فعال کرنا سائن اِن بحال کرتا ہے مگر رکنیتیں کبھی دوبارہ نہیں دیتا۔

باہر کیا رہتا ہے

• گروپ→کردار میپنگ لاگ اِن کے وقت ہوتی ہے، SAML اٹریبیوٹس / OIDC کلیمز سے — پش شدہ SCIM گروپس محفوظ نہیں کیے جاتے۔
• مالک کا کردار SSO سے ناقابلِ رسائی ہے — نہ بطور ڈیفالٹ کردار اور نہ گروپ میپنگ کے ذریعے۔
• WebSocket ریلے کبھی SSO چینل نہیں ہوتا؛ وہ فونز جو سرور تک صرف ریلے کے ذریعے پہنچتے ہیں، اُس کے خلاف براؤزر راؤنڈ ٹرپ مکمل نہیں کر سکتے۔