আমার মনে হয় আপনি conflating করছি প্রমাণীকরণ এবং অনুমোদন ।
আমি সম্পূর্ণরূপে সম্মত হই যে ডিবিতে সুরক্ষা মডেল রাখা বুদ্ধিমানের কাজ, বিশেষত লেজারএসএমবি একাধিক ক্লায়েন্টকে মনে রেখে অ্যাক্সেস নিয়ে তৈরি করা হয়েছে। আপনি যদি মিডলওয়্যার স্তরটি নিয়ে ত্রি-স্তরের দিকে যাওয়ার পরিকল্পনা না করেন তবে এটি ব্যবহারকারীদের ডাটাবেসের ভূমিকা হিসাবে বিশেষত অ্যাকাউন্টিং অ্যাপের মতো ব্যবহারের জন্য সঠিক ধারণা অর্জন করে।
এর অর্থ এই নয় যে আপনাকে পোস্টগ্র্রেএসকিউএল-সমর্থিত প্রমাণীকরণ পদ্ধতি ব্যবহার করে ডাটাবেসের বিরুদ্ধে ব্যবহারকারীদের প্রমাণীকরণ করতে হবে। আপনার ডাটাবেস ব্যবহারকারী, ভূমিকা এবং অনুদানগুলি কেবলমাত্র যদি আপনি চান তবে অনুমোদনের জন্য ব্যবহার করা যেতে পারে ।
উদাহরণস্বরূপ এটি ওয়েব ইউআইয়ের জন্য কীভাবে কাজ করে তা এখানে রয়েছে:
janeওয়েব ইউআই সার্ভারের সাথে সংযোগ স্থাপন করে এবং যে কোনও পদ্ধতি পছন্দসই ব্যবহার করে প্রমাণীকরণ করুন, বলুন HTTPS X.509 ক্লায়েন্টের শংসাপত্র হ্যান্ডশেক এবং ডিআইজিএসটি আথ। সার্ভারটির এখন কোনও ব্যবহারকারীর সংযোগ রয়েছে যা এটি গ্রহণ করে jane।
সার্ভার একটি নির্দিষ্ট ব্যবহারকারীর নাম / পাসওয়ার্ড (বা কার্বেরোস বা আপনার পছন্দসই) ব্যবহার করে পোস্টগ্রিএসকিউএলে কানেক্ট করে, এটি ডিবি সার্ভারের সাথে ব্যবহারকারী হিসাবে স্বীকৃত করে webui। ডিবি সার্ভার webuiতার ব্যবহারকারীদের প্রমাণীকরণের উপর নির্ভর করে তাই webuiযথাযথ GRANTগুলি দেওয়া হয়েছে (নীচে দেখুন)।
সেই সংযোগে সার্ভারটি SET ROLE jane;ব্যবহারকারীর অনুমোদনের স্তরটি ধরে নিতে ব্যবহার করে jane। RESET ROLE;অন্য কোনওটি SET ROLEচালিত না হওয়া পর্যন্ত সংযোগটি একই অ্যাক্সেস অধিকারগুলির সাথে কাজ করছে janeএবং SELECT current_user()ইত্যাদি রিপোর্ট করবে jane।
সার্ভার ডাটাবেস সংযোগ এটা আছে যার উপর মধ্যে যোগসূত্র বজায় রাখে SET ROLEকরার janeএবং ব্যবহারকারীর জন্য ওয়েব অধিবেশন janeফলে না যে পোস্টগ্রি সংযোগ একটি নতুন ছাড়া অন্যান্য ব্যবহারকারীদের সাথে অন্য সম্পর্কগুলি দ্বারা ব্যবহার করা হবে SET ROLEinbetween।
এখন আপনি অনুমোদন সার্ভার বাহিরে কিন্তু বজায় রাখার অনুমোদন সার্ভার। Pg- র ব্যবহারকারীদের কী রয়েছে তা জানা দরকার তবে তাদের জন্য পাসওয়ার্ড বা প্রমাণীকরণের পদ্ধতিগুলির প্রয়োজন নেই।
দেখা:
বিস্তারিত
ওয়েবুই সার্ভারটি কোয়েরিগুলিকে চালিত করতে নিয়ন্ত্রণ করে এবং এটি janeকাঁচা এসকিউএল চালানোর সুযোগ দেয় না (আশা করি!) সুতরাং ওয়েব ইউআইয়ের মাধ্যমে এটি janeপারবেন না RESET ROLE; SET ROLE special_admin_user;। অতিরিক্ত সুরক্ষার জন্য আমি সার্ভারে একটি স্টেটমেন্ট ফিল্টার যুক্ত করব যা প্রত্যাখাত হয়েছিল SET ROLEএবং RESET ROLEযদি না সংযোগটি অ-সাইনড সংযোগগুলির পুলটিতে প্রবেশ করা না থাকে unless
আপনি এখনও অন্য ক্লায়েন্টগুলিতে পিজির সরাসরি প্রমাণীকরণ ব্যবহার করতে পারবেন না; আপনি অবাধে মিশ্রিত এবং মেলে করতে পারেন। আপনি শুধু আছে করার জন্য ব্যবহারকারীর অধিকার ব্যবহারকারী যারা ওয়েবের মাধ্যমে লগ ইন করতে পারেন এবং তারপর ঐ ব্যবহারকারীদের কোনো স্বাভাবিক দিতে অধিকার, পাসওয়ার্ড, ইত্যাদি আপনি চান। আপনি যদি তাদের কেবল ওয়েব-করতে চান তবে ডাটাবেসে তাদের অধিকার (এবং থেকে )।GRANTwebuiSET ROLECONNECTREVOKECONNECTpublic
এই জাতীয় প্রমাণীকরণ / অনুমোদনের বিভাজনকে সহজ করার জন্য আমার একটি বিশেষ ভূমিকা রয়েছে 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তবে তা অপরিবর্তনযোগ্য ছিল এবং আপনি যদি ভূমিকা সদস্য হন তবে সুপারভাইজার না হয়ে কাজ করবে দুর্দান্ত great এই মুহুর্তে একটি নেই, তবে আপনি যদি যত্নশীল হন তবে আপনি প্রমাণীকরণ এবং অনুমোদনের বিষয়টি খুব ভালভাবে আলাদা করতে পারেন।
উদাহরণ এবং ব্যাখ্যা
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ডি janeএবং এমনকি যদিও janeকরা হয়েছে GRANTভূমিকা অনুমান করা ঠিক ed jim। SET ROLEআপনার কার্যকর ব্যবহারকারী আইডি সেট করে, তবে এটি SET ROLEঅন্যান্য ভূমিকার সাথে আপনার ক্ষমতা সরিয়ে দেয় না , এটি আপনার বর্তমান কার্যকর ভূমিকা নয় বরং আপনি যে ভূমিকাটির সাথে সংযুক্ত ছিলেন সেই সম্পত্তি। ফলস্বরূপ আপনার অবশ্যই আদেশ SET ROLEএবং RESET ROLEকমান্ডের অ্যাক্সেস সাবধানে নিয়ন্ত্রণ করতে হবে । এএফআইকে রয়েছে, কোনও 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যে অধিকার ed:
regress=> SET ROLE dbowner;
ERROR: permission denied to set role "dbowner"
সুতরাং এটি নিজের শক্তি দ্বারা একেবারেই শক্তিহীন, এটি কেবলমাত্র অন্যান্য ব্যবহারকারীর অধিকারই গ্রহণ করতে পারে এবং কেবল তখন যখন সেই ব্যবহারকারীরা ওয়েব অ্যাক্সেস সক্ষম করে থাকে।