Танилт ба эрх¶

Хэн нэвтэрч байна, ямар замаар, хэр удаан, юу хийж чадах вэ. Энэ баримт нь internal/workspace/auth, internal/workspace/identity, internal/workspace/ssoprovider ба internal/operator/operator-ийн кодоос уншиж бичигдсэн.

Баримтын төв · Архитектур

Нэвтрэх зам¶

Зам	Маршрут	Юу нотлох вэ
Нууц үг	`POST /api/v1/auth/login`	Мэддэг зүйл
eID (QR)	`/auth/eid/start` → `/poll` → `/login`	Иргэний үнэмлэхийн гэрчилгээ
eID (регистрээр)	`/auth/eid/start-id`	Мөн адил, эхлэл нь өөр
ДАН	`POST /api/v1/auth/dan/login`	Төрийн танилт
Google	`/auth/google/start` → `/callback`	Гуравдагч талын бүртгэл
Федерацлагдсан SSO	`/auth/sso/start` → `/callback`	Байгууллагын өөрийн IdP
Урилгын кредентшл	`POST /api/v1/auth/credential/redeem`	Урьдчилан өгсөн нэг удаагийн эрх
Impersonation	`POST /api/v1/auth/impersonation/redeem`	Операторын гаргасан нэг удаагийн холбоос

Дөрвөн гадаад рэйл — eID, ДАН, Google, федерацлагдсан IdP — бүгд ижил хоёр асуултаар төгсдөг: энэ нь аль локал бүртгэл вэ, ба бүртгэл байхгүй бол шинээр үүсгэж болох уу. Эхнийх нь binding, хоёр дахь нь access mode.

Клиент бүр nil байж болно. Тохируулаагүй рэйл нь алдаа биш — тохируулаагүй гэдгээ хэлдэг.

Хаалттай эсэх — access mode¶

Нэг шалгалт, бүртгэл үүсгэдэг бүх зам дээр, анхдагчаараа хаалттай.

public   → танихгүй хүн нэвтэрч, бүртгэл нь автоматаар үүснэ
private  → зөвхөн урьдчилан бүртгэгдсэн хүн

Өмнө нь энэ асуултыг хоёр environment variable хариулдаг байсан (EID_JIT_TENANT_SLUG, SSO_CLIENT_TENANT) — хоёр файлд, хоёр багц уншдаг, «танихгүй хүн орж чадах уу» гэдгийг нэг ч газар хариулдаггүй. Одоо нэг газар хариулна.

Юуг хаадаггүй: аль хэдийн бүртгэлтэй хүн нэвтрэх; урилга (урилга нь өөрөө урьдчилсан бүртгэл); операторын консол (тэр өөр хүснэгт, өөр ертөнц).

Засвар (maintenance)¶

Хоёр түвшин — платформ даяар (тохиргоо) ба нэг байгууллагад (мөрийн багана) — хоёулаа хэрэглэгчийн хувьд ижил утгатай: харж болно, өөрчилж болохгүй.

Унших нь зориуд нээлттэй. Бүгдийг татгалздаг засварын горим бол сайхан мессежтэй тасалдал, харин засварын горим байх учир нь доор нь юм зөөгдөж байхад хүмүүс хэрэгтэй зүйлээ харж чаддаг байх.

Session¶

	Ажлын урсгал	Операторын урсгал
Cookie	`session_token`	`cp_session`
Бүтэн хугацаа	12 цаг	8 цаг
Идэвхгүй хугацаа	90 минут (`SESSION_IDLE_TIMEOUT`)	—
Хоёр дахь хүчин зүйл	—	Заавал
Step-up цонх	—	5 минут

Token нь crypto/rand-ийн 256 бит. Өгөгдлийн санд зөвхөн SHA-256 digest нь хадгалагдана, тиймээс сангийн задрал нь нэвтрэлт болж давтагдахгүй.

Идэвхгүй хугацаа нь бүтэн хугацаанаас өөр асуулт хариулдаг: «нэг нэвтрэлт хэр удаан үргэлжлэх вэ» биш, «хараа хяналтгүй компьютер хүнийг хэр удаан нэвтэрсэн байлгах вэ». Найман цагийн ажил тасрах ёсгүй; нийтийн оффисын дэлгэц үдийн хоолны дараа нэвтэрсэн хэвээр байх ёсгүй. Native клиент хоёр дахь дэлгэцэн дээр удаан хугацаагаар нээлттэй байдаг тул энэ нь минут биш, цаг зэрэгцээ хэмжээтэй.

Тохиргоо нь хүсэлт бүрд уншигдана, эхлэлд барьж авдаггүй — инцидентийн үеэр хугацааг богиносгосон оператор түүнийг хүчинтэй болгохын тулд платформыг дахин ачаалах шаардлагагүй.

Session тайлах query дахь гишүүнчлэлийн join нь шалгалт, хайлт биш: хасагдсан хүний session нь дуусах цагаа хүлээхгүй, тэр дороо ажиллахаа болино.

Нууц үг таамаглах¶

15 минутын цонхонд 5 амжилтгүй оролдлого → түгжээ.

Түгжээ дуусмагц тоолол шинээр эхэлнэ. Тоолуур дээр нэмээд орхивол нэг удаа түгжигдсэн хүн дараа нь буруу товшилт болгоны дараа түгжигддэг болно — өөрөөр хэлбэл цонх бүрд нэг хүсэлт илгээж чаддаг хэн боловч тэр бүртгэлийг хаалттай байлгаж чадна.

Платформ өөрөө IdP¶

internal/workspace/ssoprovider нь OAuth2 Authorization Server ба OpenID Connect Provider. Зарлагдсан зүйл нь дэмжигдсэн байдаг:

authorization_code — PKCE заавал
refresh_token — эргэлт (rotation) ба давталтын илрүүлэлт
client_credentials — машин дуудагчид

Access token нь opaque, /oauth2/introspect-ээр шалгагдана; id_token нь RS256 JWT, /.well-known/jwks.json-оор баталгаажна. Access token 1 цаг, refresh token 30 хоног — эхнийх нь богино байгаа шалтгаан нь introspection-ы хариуг кэшлэсэн resource server дундаа цуцлагдсаныг мэдэхгүй.

Энэ рэйл дээр Grafana ба Nexus-ийн бусад суулгацууд нэвтэрдэг. Token нь roles ба platform_admin claim авч явна; сүүлийнх нь тухайн хүн үүсгэн байгуулагч байгууллагын админ эсэхийг хэлнэ — token аль байгууллагыг нэрлэснээс үл хамааран.

Операторын эрх¶

Дөрвөн үүрэг, 15 чадвар, нэг хүснэгт. «Энэ үүрэг тэрийг хийж чадах уу» гэсэн асуулт бүр тэр хүснэгтийг уншиж хариулагдана — handler дотор if role == "superadmin" гэж бичигддэггүй. Тэр нь эрхийн алдаа амьдардаг газар бөгөөд бүтэн зургийг нэг дор харах боломжгүй болгодог.

Чадвар	superadmin	operator	support	auditor
`tenant.read`	●	●	●	●
`audit.read`	●	●	●	●
`operator.read`	●	●		●
`tenant.create`	●	●
`tenant.suspend`	●	●
`quota.write`	●	●
`settings.write`	●	●
`flags.write`	●	●
`announce`	●	●
`support.act`	●	●	●
`user.impersonate`	●		●
`tenant.delete`	●
`approval.decide`	●
`deploy.trigger`	●
`operator.write`	●

Уншигчийн буруу таамаглах гурван зүйл:

Дөрвөн үүрэг нь шат биш. operator байгууллага үүсгэж чадна, support чадахгүй; support байгууллагын дотор харж чадна, operator чадахгүй. Аль нь ч нөгөөгөөсөө «дээгүүр» биш.
auditor бүхнийг уншиж, юу ч хийж чадахгүй. Тэр нь яг л зорилго: платформыг шалгадаг, өөрчилж чаддаггүй хүн.
Устгал нь нэг superadmin-ы хүсэлт ба өөр superadmin-ы зөвшөөрөл. Хоёр үүрэг барьсан нэг хүн бол хоёр хүн биш, тиймээс шалгалт нь чадвар дээр биш хувь хүн дээр хийгддэг.

Танихгүй үүрэг ямар ч чадвар барихгүй. Жагсаалтыг мэдэхгүй зүйлийн бичсэн role багана нь нэвтэрч чаддаг ба юу ч хийж чаддаггүй бүртгэл болно — бүхнийг хийж чаддаг биш.

settings.write ба flags.write нь operator-т байгаа нь зориуд: шөнө дундын дуудлагад хариулж байгаа хүн бол оператор, superadmin биш.

Impersonation¶

Консолын хийдэг зүйлсээс цорын ганц нь хэрэглэгчийн өгөгдөлд хүрдэг, тиймээс тэр нь чимээгүй хийх боломжгүй байхаар барьсан. Таван нөхцөл, аль нь ч сонголттой биш:

бичсэн шалтгаан      — хадгалагдана, байгууллагад харагдана, checkbox биш
хоёр дахь хүчин зүйл — маршрут дээр RequireStepUp
30 минут             — session дуусна, сунгагдахгүй
banner               — байгууллагын UI үүнийг session-ээсээ өөрөө уншина
хоёр audit мөр       — операторынх, ба байгууллагын өөрийнх

Сүүлийнх нь хамгийн чухал. Зөвхөн операторууд харж чаддаг impersonation бол цаасан бичигтэй харуулдалт болно. Мөр нь байгууллагын өөрийнх нь audit_events-д болон operator_impersonations-д бичигдэх бөгөөд тэдний админууд түүнийг унших эрхтэй — «манай өгөгдлийг хэн харсан бэ» гэдэг нь биднээс асуухгүйгээр хариулагддаг асуулт.

Дамжуулалт (handover) байдгийн шалтгаан нь cookie нь hostname давж чаддаггүйд оршино: консол нэг нэрэн дээр, session нөгөө дээр тавигдах ёстой. Консол нэг удаагийн token гаргаж, операторт холбоос өгнө; платформын тал түүнийг session болгож солино — нэг удаа, нэг минутын дотор.

Хүн, түүний өөрийн орон зай¶

eID-ээр нээгдсэн бүртгэлд өөрийн хаяг байдаггүй: иргэн хэн болохоо нотолсон болохоос имэйлээ хэлээгүй. Платформ түүнд Gerege дугаараас гаралтай хаяг өгнө (10000263@gemail.com). Зөвхөн ийм зохиомол хаягийг дараа нь дарж бичиж болно — хүний өөрийн бичсэн хаягт хүрэхгүй.

Нэг eID нь нэг хүн. Тэр нь unique index-ээр хэрэгжинэ, Go дотор биш.