माइक्रोसर्विस आर्किटेक्चर में Authentication और Authorization
(microservices.io)यह श्रृंखला माइक्रोसर्विस आर्किटेक्चर में Authentication और Authorization को इम्प्लीमेंट करने के तरीकों पर केंद्रित है.
इस लेख में समग्र अवलोकन के साथ single application (monolithic) से इसके अंतर को समझाया गया है.
उदाहरण application: RealGuard.io
RealGuard.io एक commercial security system platform है, जो security devices के control और alarms को manage करता है.
उपयोगकर्ता sales companies, customer companies और monitoring providers से जुड़े होते हैं, और सभी के access permissions अलग-अलग होते हैं.
Monolithic architecture में Authentication और Authorization
Monolithic structure एक application और database से बना होता है, और Authentication को session token से इम्प्लीमेंट किया जाता है.
Authorization निम्न संरचना के अनुसार किया जाता है:
isAllowed(user, operation, resource)
उदाहरण:
isAllowed(user, "disarm", SecuritySystem(ID))
Authorization के 4 मॉडल
- RBAC: role-based access control – उपयोगकर्ता को दिए गए role के आधार पर permission तय होती है
- ReBAC: relationship-based access control – उपयोगकर्ता और resource के संबंध के आधार पर access तय होता है
- ABAC: attribute-based access control – उपयोगकर्ता, resource और environment के attributes के आधार पर निर्णय होता है
- Hybrid model: ऊपर के 3 मॉडलों को मिलाकर complex policies इम्प्लीमेंट की जा सकती हैं
Authorization के उदाहरण और role-वार permissions
| Operation | Required Role |
|---|---|
| getAlarmSystem() | SecuritySystemViewer |
| armSystem() | SecuritySystemArmer |
| disarmSystem() | SecuritySystemDisarmer |
| cancelSystem() | SecuritySystemAlarmCanceller |
विशिष्ट role के अलावा working hours restrictions (ABAC) या notification list में शामिल होने जैसी अतिरिक्त शर्तें भी लागू हो सकती हैं.
Authorization validation कहाँ की जाए
- Network infrastructure: service mesh, ingress controller आदि में simple permission checks किए जा सकते हैं
- REST API handlers: request-level coarse-grained Authorization
- Domain logic: complex condition-based Authorization
- DB access layer: SQL के भीतर Authorization filtering (large-scale processing के लिए प्रभावी)
UI में Authorization
UI Authorization को enforce नहीं कर सकती, लेकिन उपयोगकर्ता की permissions के अनुसार buttons/features को दिखाकर या disable करके UX को बेहतर बना सकती है.
माइक्रोसर्विस आर्किटेक्चर में Authentication
BFF(Backend For Frontend) login और session management संभालता है.
क्योंकि हर माइक्रोसर्विस स्वतंत्र रूप से चलती है, इसलिए वह session से सीधे user information access नहीं कर सकती, और JWT जैसे tokens के माध्यम से user information भेजनी पड़ती है.
माइक्रोसर्विस आर्किटेक्चर में Authorization
Request BFF → SecurityService क्रम में आगे बढ़ती है, और Authorization validation निम्न तीन स्थानों पर की जा सकती है:
- BFF: session information के आधार पर path और method के हिसाब से request-level Authorization संभव
- Inter-service Network: service mesh JWT-आधारित कुछ Authorization कर सकता है
- प्रत्येक service के अंदर: domain logic और DB access layer में Authorization किया जाता है
Distributed Authorization की कठिनाइयाँ
क्योंकि हर service के पास जरूरी जानकारी अपने DB में नहीं होती, इसलिए Authorization के लिए दूसरी services के APIs को कॉल करना पड़ सकता है.
इसे JWT से हल करने की कोशिश भी की जाती है, लेकिन token size और validation cost समस्या बन सकते हैं.
सारांश
- Authentication उपयोगकर्ता की पहचान की पुष्टि है, Authorization permissions का निर्णय है
isAllowed(user, operation, resource)पैटर्न Authorization का मुख्य आधार है- RBAC, ReBAC, ABAC तीनों Authorization models को मिलाकर इम्प्लीमेंटेशन किया जा सकता है
- Monolithic में single DB access की वजह से Authorization आसान होता है
- माइक्रोसर्विस में Authorization के लिए जरूरी data बिखरा होने से इम्प्लीमेंटेशन अधिक जटिल हो जाता है
अभी कोई टिप्पणी नहीं है.