وكيل خدمات eID¶
تستدعي التطبيقات المسجَّلة خدمات eID الخاصّة بـ Gerege SSO نيابةً عن مستخدميها عبر وكيل (proxy). يتعرّف نظام الدخول الموحّد على المستخدم من موضوع الرمز، ثمّ يجلب البيانات باستخدام بيانات اعتماده هو كطرف معتمِد لدى eidmongolia.mn — وبذلك لا تحتاج التطبيقات إلى حيازة أيّ بيانات اعتماد eID.
خدمتان¶
| الخدمة | المسار العام | نقاط النهاية |
|---|---|---|
eid-proxy (شخصي) |
https://sso.gerege.mn/rp/eid/* |
summary · certificates · devices · activity |
eid-org-proxy (المنظمات) |
https://sso.gerege.mn/rp/eid-org/* |
organizations · organizations/{regNo}/signers |
جميعها للقراءة فقط (GET). وقد فُصلت الخدمات الشخصية عن خدمات المنظمات في مجموعتين حتى يتمكّن المشرف من إدارتهما باستقلال.
استدعاء الوكيل¶
تحتوي الاستجابة على بيانات eID الخاصّة بذلك المستخدم (مجلوبة ببيانات اعتماد الطرف المعتمِد لدى نظام الدخول الموحّد).
التخويل¶
يجب أن تكون الخدمة ممنوحة للتطبيق. ويُعبَّر عن المنح بـنطاق الخدمة
(svc:eid-proxy / svc:eid-org-proxy) ضمن نطاقات OAuth2 المسموح بها للعميل —
ومنح الخدمة للتطبيق من لوحة الإدارة يضيف هذا النطاق.
في كلّ طلب يقوم نظام الدخول الموحّد بما يلي:
- يفحص الرمز (RFC 7662) ←
active+sub. - يبحث عن العميل بـ
client_idالوارد في الرمز ويتحقّق من منح نطاق الخدمة (يتحقّق من المنح الحالي، فيسري المنح أو السحب فورًا). - يستدلّ على المستخدم من
subويجلب البيانات من eID Mongolia.
| الحالة | الاستجابة |
|---|---|
| لا يوجد رمز / الرمز منتهٍ | 401 |
| الخدمة غير ممنوحة للتطبيق | 403 |
| الخدمة معطَّلة في البوّابة | 503 |
| نجاح | 200 + البيانات |
كيف تُمنح الخدمة؟
الإدارة ← التطبيقات ← التطبيق ← علِّم eid-proxy / eid-org-proxy ← حفظ. يتلقّى التطبيق غير الممنوح رمز 403. انظر بوّابة API للتفاصيل.
مفتاح التشغيل أثناء العمل¶
كلتا الخدمتين مسجَّلتان في كتالوج بوّابة API، ويمكن تفعيلهما أو تعطيلهما
من واجهة إدارة البوّابة أثناء التشغيل (المعطَّلة ← 503). ويمكن إيقاف eID
الشخصي بينما يظلّ eID المنظمات يعمل (فهما مستقلّان).