मुझे लगता है कि आप प्रमाणीकरण और प्राधिकरण को भ्रमित कर रहे हैं ।
मैं इस बात से पूरी तरह सहमत हूं कि DB में सुरक्षा मॉडल को ध्यान में रखते हुए, विशेष रूप से LedgerSMB को कई ग्राहकों को ध्यान में रखकर बनाया गया है। जब तक आप एक मिडिलवेयर परत के साथ 3-स्तरीय जाने की योजना नहीं बनाते हैं, तो यह उपयोगकर्ताओं को डेटाबेस भूमिकाओं के रूप में सही अर्थ देता है , विशेष रूप से एक लेखांकन ऐप की तरह कुछ के लिए।
इसका मतलब यह नहीं है कि आपको पोस्टग्रेएसक्यूएल-समर्थित प्रमाणीकरण पद्धति का उपयोग करके डेटाबेस के खिलाफ उपयोगकर्ताओं को प्रमाणित करना होगा। आपके डेटाबेस उपयोगकर्ता, भूमिकाएँ और अनुदान केवल प्राधिकरण के लिए उपयोग किए जा सकते हैं, यदि आप चाहें।
यहाँ उदाहरण के लिए यह वेब यूआई के लिए कैसे काम करता है:
janeHTTPS X.509 क्लाइंट सर्टिफिकेट हैंडशेक और DIGEST ऑर्कुट कहते हैं कि वेब यूआई सर्वर से जुड़ता है और जो भी विधि वांछित है, उसका उपयोग करता है। सर्वर का अब उपयोगकर्ता से एक कनेक्शन है जिसे वह स्वीकार करता है jane।
सर्वर एक उपयोगकर्ता नाम के रूप में db सर्वर के लिए अपने आप को प्रमाणित करने के लिए एक निश्चित उपयोगकर्ता नाम / पासवर्ड (या केर्बोस या जो कुछ भी आप चाहते हैं) का उपयोग करके PostgreSQL से जुड़ता है webui। Db सर्वर webuiअपने उपयोगकर्ताओं को प्रमाणित करने के लिए भरोसा करता है इसलिए webuiउसे उपयुक्त GRANTएस (नीचे देखें) दिया गया है ।
उस कनेक्शन पर सर्वर SET ROLE jane;उपयोगकर्ता के प्राधिकरण स्तर को मानने के लिए उपयोग करता है jane। जब तक RESET ROLE;या किसी अन्य SET ROLEको चलाया जाता है, तब तक कनेक्शन उसी एक्सेस अधिकारों के साथ काम कर रहा है जैसे कि janeऔर SELECT current_user()आदि रिपोर्ट करेंगे jane।
सर्वर डेटाबेस कनेक्शन यह है जिस पर के बीच सहयोग का कहना है SET ROLEकरने के लिए janeऔर उपयोगकर्ता के लिए वेब सत्र jane, की अनुमति नहीं दे कि PostgreSQL कनेक्शन एक नया बिना अन्य उपयोगकर्ताओं के साथ अन्य कनेक्शन द्वारा प्रयोग की जाने SET ROLEinbetween।
अब आप सर्वर के बाहर प्रमाणीकरण कर रहे हैं , लेकिन सर्वर में प्राधिकरण बनाए रखते हैं । पीजी को यह जानना होगा कि उपयोगकर्ता क्या मौजूद हैं, लेकिन उनके लिए पासवर्ड या प्रमाणीकरण विधियों की आवश्यकता नहीं है।
देख:
विवरण
Webui सर्वर चलाने वाले प्रश्नों को नियंत्रित करता है, और यह janeकच्चे SQL को चलाने नहीं देता है (मुझे उम्मीद है!) ऐसा वेब ui के माध्यम से janeनहीं हो सकता है RESET ROLE; SET ROLE special_admin_user;। अतिरिक्त सुरक्षा के लिए मैं सर्वर के लिए एक स्टेटमेंट फ़िल्टर जोड़ूंगा जो अस्वीकार कर दिया गया था SET ROLEऔर RESET ROLEजब तक कि कनेक्शन बिना कनेक्शन के पूल में प्रवेश या प्रवेश नहीं कर रहा था।
आप अभी भी अन्य ग्राहकों में Pg के लिए प्रत्यक्ष प्रमाणीकरण का उपयोग करने के लिए स्वतंत्र हैं; आप मिश्रण और स्वतंत्र रूप से मैच कर सकते हैं। आपको बस GRANTउन webuiउपयोगकर्ताओं के लिए उपयोगकर्ता के अधिकार हैं SET ROLEजो वेब के माध्यम से लॉग इन कर सकते हैं और फिर उन उपयोगकर्ताओं को CONNECTआपके द्वारा इच्छित सामान्य अधिकार, पासवर्ड आदि दे सकते हैं। यदि आप उन्हें केवल-वेब बनाना चाहते हैं, तो डेटाबेस पर REVOKEउनके CONNECTअधिकार (और से public)।
इस तरह के प्रमाणीकरण / प्राधिकरण विभाजन को आसान बनाने के लिए मेरी एक विशेष भूमिका है assume_any_userजिसे मैं GRANTहर नए उपयोगकर्ता को बनाता हूं । फिर मैं GRANT assume_any_userएक विश्वसनीय वेब फ्रंट-एंड जैसी चीजों के द्वारा उपयोग किए जाने वाले वास्तविक उपयोगकर्ता नाम पर, उन्हें कोई भी उपयोगकर्ता बनने का अधिकार देता हूं, जिसे वे पसंद करते हैं।
assume_any_userएक NOINHERITभूमिका बनाना महत्वपूर्ण है , इसलिए webuiउपयोगकर्ता या जो भी अपने स्वयं के द्वारा कोई निजीकरण नहीं करता है और केवल SET ROLEएक वास्तविक उपयोगकर्ता के लिए डेटाबेस पर कार्य कर सकता है । किसी भी परिस्थिति में webuiएक सुपरयुसर या डीबी मालिक नहीं होना चाहिए ।
यदि आप पूलिंग कनेक्शन कर रहे हैं SET LOCAL ROLE, तो आप केवल लेन-देन के भीतर भूमिका सेट करने के लिए उपयोग कर सकते हैं , इसलिए आप पूल में COMMITया उसके बाद कनेक्शन वापस कर सकते हैं ROLLBACK। सावधान रहें कि RESET ROLEयह अभी भी काम करता है, इसलिए क्लाइंट को जो भी एसक्यूएल चाहिए, उसे चलने देना अभी भी सुरक्षित नहीं है।
SET SESSION AUTHORIZATIONइस कमांड का संबंधित लेकिन मजबूत संस्करण है। इसके लिए भूमिका सदस्यता की आवश्यकता नहीं है, लेकिन यह केवल सुपर कमांडर है। आप अपने वेब यूआई को एक सुपरयुसर के रूप में नहीं जोड़ना चाहते हैं। इसे उलट दिया जा सकता है RESET SESSION AUTHORIZATION, SET SESSION AUTHORIZATION DEFAULTया SET SESSION AUTHORIZATION theusernameफिर सुपरसुअर अधिकारों को पुनः प्राप्त किया जा सकता है , इसलिए यह सुरक्षा अवरोधक भी नहीं है।
एक कमांड जो काम करता SET SESSION AUTHORIZATIONथा लेकिन अपरिवर्तनीय था और अगर आप एक भूमिका सदस्य थे तो काम करेंगे लेकिन सुपरयुसर महान नहीं होगा। इस बिंदु पर एक नहीं है, लेकिन आप अभी भी प्रमाणीकरण और प्राधिकरण को बहुत अच्छी तरह से अलग कर सकते हैं यदि आप सावधान रहें।
उदाहरण और स्पष्टीकरण
CREATE ROLE dbowner NOLOGIN;
CREATE TABLE test_table(x text);
INSERT INTO test_table(x) VALUES ('bork');
ALTER TABLE test_table OWNER TO dbowner;
CREATE ROLE assume_any_user NOINHERIT NOLOGIN;
CREATE ROLE webui LOGIN PASSWORD 'somepw' IN ROLE assume_any_user;
CREATE ROLE jane LOGIN PASSWORD 'somepw';
GRANT jane TO assume_any_user;
GRANT ALL ON TABLE test_table TO jane;
CREATE ROLE jim LOGIN PASSWORD 'somepw';
GRANT jim TO assume_any_user;
अब के रूप में कनेक्ट करें webui। ध्यान दें कि आप कुछ भी नहीं कर सकते test_tableलेकिन आप कर सकते SET ROLE हैं janeऔर फिर आप उपयोग कर सकते हैं test_table:
$ psql -h 127.0.0.1 -U webui regress
Password for user webui:
regress=> SELECT session_user, current_user;
session_user | current_user
--------------+--------------
webui | webui
(1 row)
regress=> SELECT * FROM test_table;
ERROR: permission denied for relation test_table
regress=> SET ROLE jane;
SET
regress=> SELECT session_user, current_user;
session_user | current_user
--------------+--------------
webui | jane
(1 row)
regress=> SELECT * FROM test_table;
x
------
bork
(1 row)
ध्यान दें कि webui कर सकते हैं SET ROLE करने के लिए jim, पहले से ही यहाँ तक कि जब SET ROLEकरने के लिए d janeऔर भले ही janeनहीं किया गया है GRANTभूमिका ग्रहण करने का अधिकार एड jim। SET ROLEआपकी प्रभावी उपयोगकर्ता आईडी सेट करता है, लेकिन यह SET ROLEअन्य भूमिकाओं के लिए आपकी क्षमता को दूर नहीं करता है , यह आपके द्वारा वर्तमान भूमिका के रूप में नहीं, बल्कि आपके द्वारा जुड़ी भूमिका की एक संपत्ति है। नतीजतन आपको ध्यान से SET ROLEऔर RESET ROLEआदेशों तक पहुंच को नियंत्रित करना होगा । वहाँ है, AFAIK, SET ROLEएक कनेक्शन के लिए स्थायी रूप से कोई रास्ता नहीं है , वास्तव में लक्ष्य उपयोगकर्ता बन रहा है, हालांकि यह निश्चित रूप से अच्छा होगा।
की तुलना करें:
$ psql -h 127.0.0.1 -U webui regress
Password for user webui:
regress=> SET ROLE jane;
SET
regress=> SET ROLE jim;
SET
regress=> SELECT session_user, current_user;
session_user | current_user
--------------+--------------
webui | jim
(1 row)
सेवा:
$ psql -h 127.0.0.1 -U jane regress
Password for user jane:
regress=> SET ROLE webui;
ERROR: permission denied to set role "webui"
regress=> SET ROLE jim;
ERROR: permission denied to set role "jim"
इसका मतलब यह है कि SET ROLEदिए गए भूमिका के रूप में लॉगिंग के समान नहीं है, कुछ आपको ध्यान में रखना चाहिए।
webuiचूंकि यह सही नहीं SET ROLEहै, dbownerइसलिए इसे GRANTसंपादित नहीं किया जा सकता है :
regress=> SET ROLE dbowner;
ERROR: permission denied to set role "dbowner"
इसलिए अपने स्वयं के द्वारा यह बहुत शक्तिहीन है, यह केवल अन्य उपयोगकर्ताओं के अधिकारों को मान सकता है और केवल तभी जब उन उपयोगकर्ताओं के पास वेब पहुंच सक्षम हो।