JAAS - ٹیکنالوجی کا تعارف (حصہ 1)

رسائی سیکیورٹی جاوا میں کافی عرصے سے نافذ ہے اور اس سیکیورٹی کو فراہم کرنے کے فن تعمیر کو JAAS - Java Authentication and Authorization Service کہا جاتا ہے۔ یہ جائزہ اس راز کو کھولنے کی کوشش کرے گا کہ توثیق، اجازت کیا ہے اور JAAS کا اس سے کیا تعلق ہے۔ JAAS Servlet API کے ساتھ کیسے دوست ہے، اور ان کے تعلقات میں کہاں مسائل ہیں۔

تعارف

اس جائزے میں میں ویب ایپلیکیشن سیکیورٹی جیسے موضوع پر بات کرنا چاہوں گا۔ جاوا میں کئی ٹیکنالوجیز ہیں جو سیکورٹی فراہم کرتی ہیں:

• " جاوا ایس ای پلیٹ فارم سیکیورٹی آرکیٹیکچر "، جس کے بارے میں مزید تفصیلات اوریکل کی گائیڈ میں پڑھی جا سکتی ہیں: " جاوا ٹی ایم ایس ای پلیٹ فارم سیکیورٹی آرکیٹیکچر "۔ یہ فن تعمیر بیان کرتا ہے کہ ہمیں جاوا SE رن ٹائم ماحول میں اپنی جاوا ایپلیکیشنز کو کیسے محفوظ کرنے کی ضرورت ہے۔ لیکن یہ ہماری آج کی گفتگو کا موضوع نہیں ہے۔

• " جاوا کرپٹوگرافی آرکیٹیکچر " ایک جاوا ایکسٹینشن ہے جو ڈیٹا انکرپشن کو بیان کرتی ہے۔ آپ جاوا رش پر اس ایکسٹینشن کے بارے میں مزید پڑھ سکتے ہیں " جاوا کرپٹوگرافی آرکیٹیکچر: پہلا تعارف " یا اوریکل کی گائیڈ میں: " جاوا کرپٹوگرافی آرکیٹیکچر (JCA) حوالہ گائیڈ "۔

لیکن آج کی ہماری گفتگو ایک اور ٹیکنالوجی کے بارے میں ہو گی، جس کا نام "جاوا اوتھنٹیکیشن اینڈ اتھورائزیشن سروس (JAAS)" ہے۔ یہ وہی ہے جو تصدیق اور اجازت جیسی اہم چیزوں کو بیان کرتی ہے۔ آئیے اس کو مزید تفصیل سے دیکھتے ہیں۔

JAAS

JAAS Java SE کی توسیع ہے اور اسے Java Authentication and Authorization Service (JAAS) حوالہ گائیڈ میں بیان کیا گیا ہے ۔ جیسا کہ ٹیکنالوجی کے نام سے پتہ چلتا ہے، JAAS بیان کرتا ہے کہ کس طرح تصدیق اور اجازت کو انجام دیا جانا چاہئے:

• " توثیق ": یونانی سے ترجمہ شدہ، "authentikos" کا مطلب ہے "حقیقی، حقیقی"۔ یعنی تصدیق صداقت کا امتحان ہے۔ کہ جس کی توثیق ہو رہی ہے وہ واقعی وہی ہے جو وہ کہتے ہیں۔

• " اختیار ": انگریزی سے ترجمہ کا مطلب ہے "اجازت"۔ یعنی، اجازت ایکسیس کنٹرول ہے جو کامیاب تصدیق کے بعد انجام دیا جاتا ہے۔

یعنی، JAAS اس بات کا تعین کرنے کے بارے میں ہے کہ کون کسی وسائل تک رسائی کی درخواست کر رہا ہے اور یہ فیصلہ کرنا ہے کہ آیا وہ یہ رسائی حاصل کر سکتا ہے۔ زندگی سے ایک چھوٹی سی تشبیہ: آپ سڑک پر گاڑی چلا رہے ہیں اور ایک انسپکٹر آپ کو روکتا ہے۔ براہ کرم دستاویزات فراہم کریں - تصدیق۔ کیا آپ دستاویزات کے ساتھ کار چلا سکتے ہیں - اجازت؟ یا، مثال کے طور پر، آپ کسی دکان میں شراب خریدنا چاہتے ہیں۔ سب سے پہلے، آپ سے پاسپورٹ کے لیے کہا جاتا ہے - تصدیق۔ اس کے بعد، آپ کی عمر کی بنیاد پر، یہ فیصلہ کیا جاتا ہے کہ آیا آپ الکحل خریدنے کے اہل ہیں یا نہیں۔ یہ اجازت ہے۔ ویب ایپلیکیشنز میں، بطور صارف لاگ ان کرنا (صارف کا نام اور پاس ورڈ درج کرنا) توثیق ہے۔ اور اس بات کا تعین کرنا کہ آپ کون سے صفحات کھول سکتے ہیں اس کا تعین اجازت کے ذریعے کیا جاتا ہے۔ یہ وہ جگہ ہے جہاں "جاوا تصدیق اور اجازت کی خدمت (JAAS)" ہماری مدد کرتی ہے۔ JAAS پر غور کرتے وقت، JAAS کے بیان کردہ کئی کلیدی تصورات کو سمجھنا ضروری ہے: موضوع، پرنسپل، اسناد۔ موضوع توثیق کا موضوع ہے۔ یعنی حقوق کا علمبردار یا حامل ہے۔ دستاویزات میں، موضوع کو کچھ کارروائی کرنے کی درخواست کے ذریعہ کے طور پر بیان کیا گیا ہے۔ موضوع یا ماخذ کو کسی نہ کسی طرح بیان کیا جانا چاہیے اور اس مقصد کے لیے پرنسپل استعمال کیا جاتا ہے، جسے روسی زبان میں بعض اوقات پرنسپل بھی کہا جاتا ہے۔ یعنی، ہر پرنسپل ایک خاص نقطہ نظر سے ایک مضمون کی نمائندگی کرتا ہے۔ اسے واضح کرنے کے لیے، آئیے ایک مثال دیتے ہیں: ایک مخصوص شخص ایک موضوع ہے۔ اور مندرجہ ذیل پرنسپل کے طور پر کام کر سکتے ہیں:

• اس کا ڈرائیونگ لائسنس ایک سڑک صارف کے طور پر کسی شخص کی نمائندگی کے طور پر
• اس کا پاسپورٹ، ایک شخص کی نمائندگی کے طور پر اس کے ملک کے شہری کے طور پر
• اس کا غیر ملکی پاسپورٹ، بین الاقوامی تعلقات میں ایک شخص کی نمائندگی کے طور پر
• لائبریری میں اس کا لائبریری کارڈ، لائبریری سے منسلک قاری کے طور پر کسی شخص کی نمائندگی کے طور پر

اس کے علاوہ، Subject میں "Credential" کا ایک سیٹ ہے، جس کا مطلب انگریزی میں "شناخت" ہے۔ اس طرح سبجیکٹ اس بات کی تصدیق کرتا ہے کہ وہ وہی ہے۔ مثال کے طور پر، صارف کا پاس ورڈ اسناد ہو سکتا ہے۔ یا کوئی ایسی چیز جس سے صارف اس بات کی تصدیق کر سکے کہ وہ واقعی وہی ہے۔ آئیے اب دیکھتے ہیں کہ JAAS کو ویب ایپلی کیشنز میں کیسے استعمال کیا جاتا ہے۔

ویب ایپلیکیشن

لہذا، ہمیں ایک ویب ایپلیکیشن کی ضرورت ہے۔ گریڈل آٹومیٹک پروجیکٹ کی تعمیر کا نظام اسے بنانے میں ہماری مدد کرے گا۔ Gradle کے استعمال کی بدولت، ہم چھوٹی چھوٹی کمانڈز کو عمل میں لا کر، جاوا پروجیکٹ کو اس فارمیٹ میں جمع کر سکتے ہیں جس کی ہمیں ضرورت ہے، خود بخود ضروری ڈائریکٹری ڈھانچہ تشکیل دے سکتے ہیں، اور بہت کچھ۔ آپ گریڈل کے بارے میں مختصر جائزہ میں مزید پڑھ سکتے ہیں: " گریڈل کا مختصر تعارف " یا سرکاری دستاویزات " گریڈل شروع کرنا " میں۔ ہمیں پروجیکٹ کو شروع کرنے کی ضرورت ہے (ابتدائی)، اور اس مقصد کے لیے گریڈل کے پاس ایک خاص پلگ ان ہے: " گریڈل انیٹ پلگ ان " (Init ابتدا کے لیے مختصر ہے، یاد رکھنا آسان ہے)۔ اس پلگ ان کو استعمال کرنے کے لیے، کمانڈ لائن پر کمانڈ چلائیں:

gradle init --type java-application

کامیاب تکمیل کے بعد، ہمارے پاس جاوا پروجیکٹ ہوگا۔ آئیے اب ایڈیٹنگ کے لیے اپنے پروجیکٹ کی بلڈ اسکرپٹ کھولتے ہیں۔ ایک بلڈ اسکرپٹ ایک فائل ہے جسے کہتے ہیں build.gradle، جو ایپلی کیشن کی تعمیر کی باریکیوں کو بیان کرتی ہے۔ اس لیے نام، اسکرپٹ بنائیں۔ ہم کہہ سکتے ہیں کہ یہ ایک پروجیکٹ کی تعمیر کا اسکرپٹ ہے۔ گریڈل ایک ایسا ورسٹائل ٹول ہے، جس کی بنیادی صلاحیتوں کو پلگ ان کے ساتھ بڑھایا جاتا ہے۔ لہذا، سب سے پہلے، آئیے "پلگ ان" بلاک پر توجہ دیں:

plugins {
    id 'java'
    id 'application'
}

پہلے سے طے شدہ طور پر، گریڈل نے، جو ہم نے بیان کیا ہے اس کے مطابق --type java-application، کچھ بنیادی پلگ انز کا سیٹ اپ کیا ہے، یعنی وہ پلگ ان جو خود گریڈل کی تقسیم میں شامل ہیں۔ اگر آپ gradle.org ویب سائٹ پر "دستاویزات" (یعنی دستاویزات) سیکشن پر جاتے ہیں، تو "حوالہ" سیکشن میں عنوانات کی فہرست میں بائیں جانب ہمیں " کور پلگ انز " سیکشن نظر آتا ہے، یعنی ان انتہائی بنیادی پلگ انز کی تفصیل کے ساتھ سیکشن۔ آئیے بالکل وہی پلگ ان منتخب کریں جن کی ہمیں ضرورت ہے، نہ کہ وہ جو گریڈل نے ہمارے لیے تیار کیے ہیں۔ دستاویزات کے مطابق، " گریڈل جاوا پلگ ان " جاوا کوڈ کے ساتھ بنیادی آپریشن فراہم کرتا ہے، جیسے کہ سورس کوڈ کو مرتب کرنا۔ نیز، دستاویزات کے مطابق، " گریڈل ایپلیکیشن پلگ ان " ہمیں "قابل عمل JVM ایپلیکیشن" کے ساتھ کام کرنے کے لیے ٹولز فراہم کرتا ہے، یعنی ایک جاوا ایپلیکیشن کے ساتھ جسے اسٹینڈ اپلی کیشن کے طور پر لانچ کیا جا سکتا ہے (مثال کے طور پر، کنسول ایپلی کیشن یا اس کے اپنے UI والی ایپلیکیشن)۔ یہ پتہ چلتا ہے کہ ہمیں "ایپلی کیشن" پلگ ان کی ضرورت نہیں ہے، کیونکہ... ہمیں اسٹینڈ اکیلی ایپ کی ضرورت نہیں ہے، ہمیں ایک ویب ایپ کی ضرورت ہے۔ آئیے اسے ڈیلیٹ کرتے ہیں۔ نیز "mainClassName" کی ترتیب، جو صرف اس پلگ ان کو معلوم ہے۔ مزید، اسی " پیکیجنگ اور تقسیم " سیکشن میں جہاں ایپلیکیشن پلگ ان دستاویزات کا لنک فراہم کیا گیا تھا، وہاں گریڈل وار پلگ ان کا لنک بھی ہے۔ گریڈل وار پلگ ان ، جیسا کہ دستاویزات میں بتایا گیا ہے، جاوا ویب ایپلیکیشنز کو جنگی شکل میں بنانے کے لیے معاونت فراہم کرتا ہے۔ WAR فارمیٹ کا مطلب یہ ہے کہ JAR آرکائیو کے بجائے ایک WAR آرکائیو بنایا جائے گا۔ ایسا لگتا ہے کہ ہمیں یہی ضرورت ہے۔ نیز، جیسا کہ دستاویزات میں کہا گیا ہے، "وار پلگ ان جاوا پلگ ان کو بڑھاتا ہے"۔ یعنی ہم جاوا پلگ ان کو وار پلگ ان سے بدل سکتے ہیں۔ لہذا، ہمارا پلگ ان بلاک بالآخر اس طرح نظر آئے گا:

plugins {
    id 'war'
}

نیز "گریڈل وار پلگ ان" کی دستاویزات میں یہ کہا گیا ہے کہ پلگ ان ایک اضافی "پروجیکٹ لے آؤٹ" استعمال کرتا ہے۔ لے آؤٹ کا انگریزی سے لوکیشن کے طور پر ترجمہ کیا گیا ہے۔ یعنی جنگی پلگ ان بذریعہ ڈیفالٹ فائلوں کے ایک مخصوص مقام کے وجود کی توقع کرتا ہے جسے وہ اپنے کاموں کے لیے استعمال کرے گا۔ یہ ویب ایپلیکیشن فائلوں کو ذخیرہ کرنے کے لیے درج ذیل ڈائرکٹری کا استعمال کرے گا: src/main/webapp پلگ ان کا برتاؤ اس طرح بیان کیا گیا ہے: یعنی پلگ ان ہماری ویب ایپلیکیشن کا WAR آرکائیو بناتے وقت اس مقام سے فائلوں کو مدنظر رکھے گا۔ اس کے علاوہ، گریڈل وار پلگ ان دستاویزات میں کہا گیا ہے کہ یہ ڈائریکٹری "آرکائیو کی جڑ" ہوگی۔ اور پہلے ہی اس میں ہم ایک WEB-INF ڈائرکٹری بنا سکتے ہیں اور وہاں web.xml فائل شامل کر سکتے ہیں۔ یہ کس قسم کی فائل ہے؟ web.xml- یہ ایک "تعیناتی وضاحت کنندہ" یا "تعیناتی بیان کنندہ" ہے۔ یہ ایک فائل ہے جو بتاتی ہے کہ ہماری ویب ایپلیکیشن کو کام کرنے کے لیے کنفیگر کرنے کا طریقہ۔ یہ فائل بتاتی ہے کہ ہماری ایپلیکیشن کن درخواستوں کو سنبھالے گی، سیکیورٹی کی ترتیبات، اور بہت کچھ۔ اس کے بنیادی طور پر، یہ کسی حد تک JAR فائل سے ایک مینی فیسٹ فائل سے ملتا جلتا ہے (دیکھیں " مینی فیسٹ فائلوں کے ساتھ کام کرنا: بنیادی باتیں ")۔ مینی فیسٹ فائل بتاتی ہے کہ جاوا ایپلیکیشن (یعنی ایک JAR آرکائیو) کے ساتھ کیسے کام کرنا ہے، اور web.xml بتاتی ہے کہ جاوا ویب ایپلیکیشن (یعنی ایک WAR آرکائیو) کے ساتھ کیسے کام کرنا ہے۔ "تعیناتی ڈسکرپٹر" کا تصور خود ہی پیدا نہیں ہوا تھا، لیکن دستاویز میں بیان کیا گیا ہے " Servlet API تفصیلات"کوئی بھی جاوا ویب ایپلیکیشن اس "Servlet API" پر منحصر ہے۔ یہ سمجھنا ضروری ہے کہ یہ ایک API ہے - یعنی یہ کچھ تعامل کے معاہدے کی تفصیل ہے۔ ویب ایپلیکیشنز آزاد ایپلی کیشنز نہیں ہیں۔ یہ ویب سرور پر چلتی ہیں۔ ، جو صارفین کے ساتھ نیٹ ورک مواصلت فراہم کرتا ہے۔ یعنی ویب سرور ویب ایپلیکیشنز کے لیے ایک قسم کا "کنٹینر" ہے۔ یہ منطقی ہے، کیونکہ ہم ویب ایپلیکیشن کی منطق لکھنا چاہتے ہیں، یعنی صارف کون سے صفحات دیکھے گا اور کیسے انہیں صارف کے اعمال پر رد عمل ظاہر کرنا چاہیے۔ اور ہم اس کے لیے کوڈ نہیں لکھنا چاہتے کہ صارف کو پیغام کیسے بھیجا جائے گا، معلومات کے بائٹس کیسے منتقل کیے جائیں گے اور دیگر کم درجے کی اور انتہائی معیاری چیزیں۔ اس سے پتہ چلتا ہے کہ ویب ایپلیکیشنز سبھی مختلف ہیں، لیکن ڈیٹا کی منتقلی ایک جیسی ہے۔ یعنی ایک ملین پروگرامرز کو ایک ہی مقصد کے لیے بار بار کوڈ لکھنا پڑے گا۔ اس لیے ویب سرور صارف کے کچھ تعامل کے لیے ذمہ دار ہے۔ اور ڈیٹا کا تبادلہ، اور ویب ایپلیکیشن اور ڈویلپر اس ڈیٹا کو تیار کرنے کے ذمہ دار ہیں۔ اور ان دونوں حصوں کو جوڑنے کے لیے، یعنی ویب سرور اور ویب ایپلیکیشن، آپ کو ان کے تعامل کے لیے ایک معاہدے کی ضرورت ہے، یعنی ایسا کرنے کے لیے وہ کن اصولوں پر عمل کریں گے؟ کسی نہ کسی طرح معاہدے کی وضاحت کرنے کے لیے، ویب ایپلیکیشن اور ویب سرور کے درمیان تعامل کیسا نظر آنا چاہیے، Servlet API کی ایجاد ہوئی۔ دلچسپ بات یہ ہے کہ یہاں تک کہ اگر آپ اسپرنگ جیسے فریم ورک استعمال کرتے ہیں، تب بھی ایک سرولیٹ API موجود ہے۔ یعنی، آپ Spring استعمال کرتے ہیں، اور Spring آپ کے لیے Servlet API کے ساتھ کام کرتا ہے۔ یہ پتہ چلتا ہے کہ ہمارے ویب ایپلیکیشن پروجیکٹ کا انحصار Servlet API پر ہونا چاہیے۔ اس صورت میں، Servlet API ایک انحصار ہوگا۔ جیسا کہ ہم جانتے ہیں، گریڈل آپ کو پراجیکٹ کے انحصار کو اعلانیہ انداز میں بیان کرنے کی بھی اجازت دیتا ہے۔ پلگ ان بتاتے ہیں کہ انحصار کو کس طرح منظم کیا جا سکتا ہے۔ مثال کے طور پر، Java Gradle پلگ ان "testImplementation" انحصار کے انتظام کا طریقہ متعارف کراتا ہے، جو کہتا ہے کہ ایسی انحصار صرف ٹیسٹوں کے لیے ضروری ہے۔ لیکن گریڈل وار پلگ ان انحصار کے انتظام کے طریقہ کار کو شامل کرتا ہے "providedCompile"، جو کہتا ہے کہ اس طرح کا انحصار ہماری ویب ایپلیکیشن کے WAR آرکائیو میں شامل نہیں کیا جائے گا۔ ہم اپنے WAR آرکائیو میں Servlet API کو کیوں شامل نہیں کرتے؟ کیونکہ Servlet API ہماری ویب ایپلیکیشن کو ویب سرور ہی فراہم کرے گا۔ اگر کوئی ویب سرور سرولیٹ API فراہم کرتا ہے، تو سرور کو سرولیٹ کنٹینر کہا جاتا ہے۔ لہذا، یہ ویب سرور کی ذمہ داری ہے کہ وہ ہمیں Servlet API فراہم کرے، اور یہ ہماری ذمہ داری ہے کہ ServletAPI کو صرف کوڈ کے مرتب ہونے کے وقت فراہم کریں۔ اس لیے providedCompile. اس طرح، انحصار بلاک اس طرح نظر آئے گا:

dependencies {
    providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
    testImplementation 'junit:junit:4.12'
}

تو آئیے web.xml فائل پر واپس چلتے ہیں۔ پہلے سے طے شدہ طور پر، Gradle کوئی بھی تعیناتی ڈسکرپٹر نہیں بناتا، لہذا ہمیں یہ خود کرنے کی ضرورت ہے۔ آئیے ایک ڈائریکٹری بنائیں src/main/webapp/WEB-INF، اور اس میں ہم ایک XML فائل بنائیں گے جس کا نام ہے web.xml۔ اب آئیے خود "جاوا سرولیٹ اسپیسیفیکیشن" کھولتے ہیں اور چیپٹر " چیپٹر 14 ڈیپلائمنٹ ڈسکرپٹر "۔ جیسا کہ "14.3 Deployment Descriptor" میں بتایا گیا ہے، Deployment Descriptor کی XML دستاویز کو اسکیما http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd کے ذریعہ بیان کیا گیا ہے ۔ ایک XML سکیما بیان کرتا ہے کہ دستاویز کن عناصر پر مشتمل ہو سکتی ہے اور انہیں کس ترتیب میں ظاہر ہونا چاہیے۔ کون سے لازمی ہیں اور کون سے نہیں۔ عام طور پر، یہ دستاویز کی ساخت کی وضاحت کرتا ہے اور آپ کو یہ جانچنے کی اجازت دیتا ہے کہ آیا XML دستاویز صحیح طریقے سے تشکیل دی گئی ہے۔ اب آئیے باب " 14.5 مثالوں " سے مثال استعمال کرتے ہیں، لیکن اسکیم کو ورژن 3.1 کے لیے مخصوص کیا جانا چاہیے، یعنی

http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd

ہمارا خالی web.xmlاس طرح نظر آئے گا:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
         http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <display-name>JAAS Example</display-name>
</web-app>

آئیے اب اس سرولیٹ کی وضاحت کرتے ہیں جس کی حفاظت ہم JAAS کا استعمال کرتے ہوئے کریں گے۔ پہلے، گریڈل نے ہمارے لیے ایپ کلاس تیار کی تھی۔ آئیے اسے ایک سرولیٹ میں تبدیل کریں۔ جیسا کہ " CHAPTER 2 The Servlet Interface " میں تصریح میں کہا گیا ہے ، کہ " زیادہ تر مقاصد کے لیے، ڈویلپرز HttpServlet کو اپنے سرولیٹس کو لاگو کرنے کے لیے بڑھا دیں گے "، یعنی کسی کلاس کو سرولیٹ بنانے کے لیے، آپ کو اس کلاس کو اس سے وراثت میں لینے کی ضرورت ہے HttpServlet:

public class App extends HttpServlet {
	public String getGreeting() {
        return "Secret!";
    }
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.getWriter().print(getGreeting());
    }
}

جیسا کہ ہم نے کہا، Servlet API سرور اور ہماری ویب ایپلیکیشن کے درمیان ایک معاہدہ ہے۔ یہ معاہدہ ہمیں یہ بیان کرنے کی اجازت دیتا ہے کہ جب کوئی صارف سرور سے رابطہ کرتا ہے، تو سرور صارف کی طرف سے ایک اعتراض کی شکل میں ایک درخواست تیار کرے گا HttpServletRequestاور اسے سرولیٹ کو بھیج دے گا۔ یہ سرولیٹ کو ایک آبجیکٹ بھی فراہم کرے گا HttpServletResponseتاکہ سرولیٹ صارف کے لیے اس کا جواب لکھ سکے۔ ایک بار جب servlet چلنا ختم ہو جائے گا، سرور صارف کو اس کی بنیاد پر جواب فراہم کر سکے گا HttpServletResponse۔ یعنی، servlet صارف کے ساتھ براہ راست بات چیت نہیں کرتا، لیکن صرف سرور کے ساتھ. سرور کو یہ جاننے کے لیے کہ ہمارے پاس ایک سرولیٹ ہے اور اسے کن درخواستوں کے لیے استعمال کرنے کی ضرورت ہے، ہمیں سرور کو اس کے بارے میں تعیناتی ڈسکرپٹر میں بتانا ہوگا:

<servlet>
	<servlet-name>app</servlet-name>
	<servlet-class>jaas.App</servlet-class>
</servlet>
<servlet-mapping>
	<servlet-name>app</servlet-name>
	<url-pattern>/secret</url-pattern>
</servlet-mapping>

اس صورت میں، تمام درخواستیں /secretہمارے ایک سرولیٹ کو نام سے نہیں بھیجی جائیں گی app، جو کلاس سے مماثل ہے jaas.App۔ جیسا کہ ہم نے پہلے کہا، ایک ویب ایپلیکیشن صرف ویب سرور پر تعینات کی جا سکتی ہے۔ ویب سرور کو الگ سے انسٹال کیا جاسکتا ہے (اسٹینڈ اسٹون)۔ لیکن اس جائزے کے مقاصد کے لیے، ایک متبادل آپشن موزوں ہے - ایمبیڈڈ سرور پر چل رہا ہے۔ اس کا مطلب یہ ہے کہ سرور تخلیق کیا جائے گا اور پروگرام کے مطابق لانچ کیا جائے گا (پلگ ان ہمارے لیے ایسا کرے گا)، اور ساتھ ہی ہماری ویب ایپلیکیشن اس پر تعینات کی جائے گی۔ گریڈل بلڈ سسٹم آپ کو ان مقاصد کے لیے " گریڈل گریٹی پلگ ان " پلگ ان استعمال کرنے کی اجازت دیتا ہے:

plugins {
    id 'war'
    id 'org.gretty' version '2.2.0'
}

مزید برآں، گریٹی پلگ ان میں اچھی دستاویزات ہیں ۔ آئیے اس حقیقت کے ساتھ شروع کریں کہ گریٹی پلگ ان آپ کو مختلف ویب سرورز کے درمیان سوئچ کرنے کی اجازت دیتا ہے۔ اس کو دستاویزات میں مزید تفصیل سے بیان کیا گیا ہے: " سرولیٹ کنٹینرز کے درمیان سوئچنگ "۔ آئیے Tomcat پر سوئچ کریں، کیونکہ... یہ استعمال میں سب سے زیادہ مقبول ہے، اور اس میں اچھی دستاویزات اور بہت سی مثالیں اور تجزیہ کردہ مسائل بھی ہیں:

gretty {
    // Переключаемся с дефолтного Jetty на Tomcat
    servletContainer = 'tomcat8'
    // Укажем Context Path, он же Context Root
    contextPath = '/jaas'
}

اب ہم "gradle appRun" چلا سکتے ہیں اور پھر ہماری ویب ایپلیکیشن http://localhost:8080/jaas/secret پر دستیاب ہوگی۔ یہ چیک کرنا ضروری ہے کہ سرولیٹ کنٹینر Tomcat کے ذریعہ منتخب کیا گیا ہے (#1 دیکھیں) اور چیک کریں کہ ہماری ویب ایپلیکیشن کس ایڈریس پر دستیاب ہے (دیکھیں #2)۔

تصدیق

تصدیق کی ترتیبات اکثر دو حصوں پر مشتمل ہوتی ہیں: سرور کی طرف کی ترتیبات اور اس سرور پر چلنے والی ویب ایپلیکیشن کی طرف کی ترتیبات۔ ویب ایپلیکیشن کی سیکیورٹی سیٹنگز ویب سرور کی سیکیورٹی سیٹنگز کے ساتھ تعامل نہیں کرسکتی ہیں، اگر اس کے علاوہ کسی اور وجہ سے ویب ایپلیکیشن ویب سرور کے ساتھ تعامل نہیں کرسکتی ہے۔ یہ بیکار نہیں تھا کہ ہم نے ٹامکیٹ کو تبدیل کیا، کیونکہ... Tomcat ایک اچھی طرح سے بیان کردہ فن تعمیر ہے (دیکھیں " Apache Tomcat 8 Architecture ")۔ اس فن تعمیر کی تفصیل سے یہ واضح ہے کہ Tomcat، ایک ویب سرور کے طور پر، ویب ایپلیکیشن کو ایک مخصوص سیاق و سباق کے طور پر پیش کرتا ہے، جسے " Tomcat Context " کہا جاتا ہے۔ یہ سیاق و سباق ہر ویب ایپلیکیشن کو دوسرے ویب ایپلیکیشنز سے الگ تھلگ اپنی سیٹنگز رکھنے کی اجازت دیتا ہے۔ مزید برآں، ویب ایپلیکیشن اس سیاق و سباق کی ترتیبات کو متاثر کر سکتی ہے۔ لچکدار اور آسان۔ گہری تفہیم کے لیے، ہم مضمون " Tomcat Context Containers کو سمجھنا " اور Tomcat دستاویزی سیکشن " The Context Container " پڑھنے کی تجویز کرتے ہیں۔ جیسا کہ اوپر بتایا گیا ہے، ہماری ویب ایپلیکیشن ہماری ایپلیکیشن کے Tomcat سیاق و سباق کو استعمال کر کے متاثر کر سکتی ہے /META-INF/context.xml۔ اور ایک بہت ہی اہم ترتیبات جس پر ہم اثر انداز ہو سکتے ہیں وہ ہے سیکیورٹی ریلمز۔ سیکیورٹی ریلمز ایک قسم کا "سیکیورٹی ایریا" ہے۔ ایک علاقہ جس کے لیے مخصوص حفاظتی ترتیبات متعین ہیں۔ اسی مناسبت سے، سیکیورٹی کے دائرے کا استعمال کرتے وقت ہم اس دائرے کے لیے بیان کردہ سیکیورٹی سیٹنگز کا اطلاق کرتے ہیں۔ حفاظتی دائروں کا انتظام کنٹینر کے ذریعے کیا جاتا ہے، یعنی ویب سرور، ہماری ویب ایپلیکیشن نہیں۔ ہم سرور کو صرف یہ بتا سکتے ہیں کہ ہماری درخواست تک کس حفاظتی دائرہ کار کو بڑھانے کی ضرورت ہے۔ ٹومکیٹ دستاویزات سیکشن " دی ریئلم کمپوننٹ " میں ایک دائرے کو صارفین اور تصدیق کرنے کے لیے ان کے کردار کے بارے میں ڈیٹا کے مجموعے کے طور پر بیان کیا گیا ہے۔ Tomcat مختلف سیکورٹی دائرے کے نفاذ کا ایک سیٹ فراہم کرتا ہے، جن میں سے ایک " جاس دائرہ " ہے۔ تھوڑی سی اصطلاحات کو سمجھنے کے بعد، آئیے فائل میں Tomcat کے سیاق و سباق کو بیان کرتے ہیں /META-INF/context.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <Realm className="org.apache.catalina.realm.JAASRealm"
           appName="JaasLogin"
           userClassNames="jaas.login.UserPrincipal"
           roleClassNames="jaas.login.RolePrincipal"
           configFile="jaas.config" />
</Context>

appName- درخواست کا نام۔ Tomcat اس نام کو میں بیان کردہ ناموں کے ساتھ ملانے کی کوشش کرے گا configFile۔ configFile- یہ "لاگ ان کنفیگریشن فائل" ہے۔ اس کی ایک مثال JAAS دستاویزات میں دیکھی جا سکتی ہے: " ضمیمہ B: مثال لاگ ان کنفیگریشنز "۔ اس کے علاوہ، یہ ضروری ہے کہ اس فائل کو وسائل میں سب سے پہلے تلاش کیا جائے گا. لہذا، ہماری ویب ایپلیکیشن یہ فائل خود فراہم کر سکتی ہے۔ صفات userClassNamesاور roleClassNamesان کلاسوں کا اشارہ پر مشتمل ہے جو صارف کے پرنسپل کی نمائندگی کرتی ہیں۔ JAAS "صارف" اور "کردار" کے تصورات کو دو مختلف تصورات کے طور پر الگ کرتا ہے java.security.Principal۔ آئیے مندرجہ بالا کلاسوں کو بیان کرتے ہیں۔ آئیے صارف کے پرنسپل کے لیے آسان ترین نفاذ بنائیں:

public class UserPrincipal implements Principal {
    private String name;
    public UserPrincipal(String name) {
        this.name = name;
    }
    @Override
    public String getName() {
        return name;
    }
}

ہم کے لیے بالکل وہی عمل دہرائیں گے RolePrincipal۔ جیسا کہ آپ انٹرفیس سے دیکھ سکتے ہیں، پرنسپل کے لیے اہم چیز کچھ نام (یا ID) کو ذخیرہ کرنا اور واپس کرنا ہے جو پرنسپل کی نمائندگی کرتا ہے۔ اب، ہمارے پاس سیکیورٹی کا دائرہ ہے، ہمارے پاس پرنسپل کلاسز ہیں۔ configFile" " وصف سے فائل کو بھرنا باقی ہے ، عرف login configuration file۔ اس کی تفصیل Tomcat دستاویزات میں مل سکتی ہے: " The Realm Component "۔ یعنی ہم اپنی ویب ایپلیکیشن کے وسائل میں JAAS لاگ ان کنفیگ سیٹنگ رکھ سکتے ہیں اور Tomcat Context کی بدولت ہم اسے استعمال کر سکیں گے۔ یہ فائل ClassLoader کے لیے بطور وسیلہ دستیاب ہونی چاہیے، اس لیے اس کا راستہ اس طرح ہونا چاہیے: \src\main\resources\jaas.config آئیے اس فائل کے مواد کو ترتیب دیں:

JaasLogin {
    jaas.login.JaasLoginModule required debug=true;
};

غور طلب ہے کہ context.xmlیہاں اور میں ایک ہی نام استعمال ہوا ہے۔ یہ لاگ ان موڈیول میں سیکیورٹی کے دائرے کا نقشہ بناتا ہے۔ لہذا، Tomcat سیاق و سباق نے ہمیں بتایا کہ کون سی کلاسز پرنسپلز کی نمائندگی کرتی ہیں، نیز کون سا LoginModule استعمال کرنا ہے۔ ہمیں بس اس لاگ ان موڈیول کو لاگو کرنا ہے۔ LoginModule شاید JAAS میں سب سے زیادہ دلچسپ چیزوں میں سے ایک ہے۔ باضابطہ دستاویزات لاگ ان موڈیول کو تیار کرنے میں ہماری مدد کرے گی: " Java Authentication and Authorization Service (JAAS): LoginModule Developer's Guide "۔ آئیے لاگ ان ماڈیول کو لاگو کرتے ہیں۔ آئیے ایک کلاس بنائیں جو انٹرفیس کو لاگو کرے LoginModule:

public class JaasLoginModule implements LoginModule {
}

سب سے پہلے ہم ابتدائی طریقہ کی وضاحت کرتے ہیں LoginModule:

private CallbackHandler handler;
private Subject subject;
@Override
public void initialize(Subject subject, CallbackHandler callbackHandler, <String, ?> sharedState, Map<String, ?> options) {
	handler = callbackHandler;
	this.subject = subject;
}

یہ طریقہ محفوظ کرے گا Subject، جس کی ہم مزید تصدیق کریں گے اور پرنسپلز کے بارے میں معلومات بھریں گے۔ ہم مستقبل کے استعمال کے لیے بھی بچت کریں گے CallbackHandler، جو ہمیں دیا گیا ہے۔ مدد سے، CallbackHandlerہم تھوڑی دیر بعد تصدیق کے موضوع کے بارے میں مختلف معلومات کی درخواست کر سکتے ہیں۔ CallbackHandlerآپ دستاویزات کے متعلقہ حصے میں اس کے بارے میں مزید پڑھ سکتے ہیں: " JAAS حوالہ گائیڈ: CallbackHandler "۔ loginاگلا، توثیق کا طریقہ عمل میں لایا جاتا ہے Subject۔ یہ تصدیق کا پہلا مرحلہ ہے:

@Override
public boolean login() throws LoginException {
	// Добавляем колбэки
	Callback[] callbacks = new Callback[2];
	callbacks[0] = new NameCallback("login");
	callbacks[1] = new PasswordCallback("password", true);
	// При помощи колбэков получаем через CallbackHandler логин и пароль
	try {
		handler.handle(callbacks);
		String name = ((NameCallback) callbacks[0]).getName();
		String password = String.valueOf(((PasswordCallback) callbacks[1]).getPassword());
		// Далее выполняем валидацию.
		// Тут просто для примера проверяем определённые значения
		if (name != null && name.equals("user123") && password != null && password.equals("pass123")) {
			// Сохраняем информацию, которая будет использована в методе commit
			// Не "пачкаем" Subject, т.к. не факт, что commit выполнится
			// Для примера проставим группы вручную, "хардcodeно".
			login = name;
			userGroups = new ArrayList<String>();
			userGroups.add("admin");
			return true;
		} else {
			throw new LoginException("Authentication failed");
		}
	} catch (IOException | UnsupportedCallbackException e) {
		throw new LoginException(e.getMessage());
	}
}

یہ ضروری ہے کہ loginہمیں تبدیل نہیں کرنا چاہئے Subject۔ ایسی تبدیلیاں صرف تصدیق کے طریقہ کار میں ہونی چاہئیں commit۔ اگلا، ہمیں کامیاب تصدیق کی تصدیق کا طریقہ بیان کرنا چاہیے:

@Override
public boolean commit() throws LoginException {
	userPrincipal = new UserPrincipal(login);
	subject.getPrincipals().add(userPrincipal);
	if (userGroups != null && userGroups.size() > 0) {
		for (String groupName : userGroups) {
			rolePrincipal = new RolePrincipal(groupName);
			subject.getPrincipals().add(rolePrincipal);
		}
	}
	return true;
}

طریقہ کو الگ کرنا عجیب لگ سکتا ہے loginاور commit. لیکن بات یہ ہے کہ لاگ ان ماڈیولز کو یکجا کیا جا سکتا ہے۔ اور کامیاب تصدیق کے لیے کئی لاگ ان ماڈیولز کا کامیابی سے کام کرنا ضروری ہو سکتا ہے۔ اور صرف اس صورت میں جب تمام ضروری ماڈیولز کام کر چکے ہوں، تب تبدیلیوں کو محفوظ کریں۔ یہ تصدیق کا دوسرا مرحلہ ہے۔ آئیے abortاور طریقوں کے ساتھ ختم کریں logout:

@Override
public boolean abort() throws LoginException {
	return false;
}
@Override
public boolean logout() throws LoginException {
	subject.getPrincipals().remove(userPrincipal);
	subject.getPrincipals().remove(rolePrincipal);
	return true;
}

اس طریقہ کو abortکہا جاتا ہے جب تصدیق کا پہلا مرحلہ ناکام ہوجاتا ہے۔ اس طریقہ کو logoutکہا جاتا ہے جب سسٹم لاگ آؤٹ ہوتا ہے۔ ہمارے کو لاگو کرنے Login Moduleاور اسے ترتیب دینے کے بعد Security Realm، اب ہمیں web.xmlاس حقیقت کی نشاندہی کرنے کی ضرورت ہے کہ ہم ایک مخصوص استعمال کرنا چاہتے ہیں Login Config:

<login-config>
  <auth-method>BASIC</auth-method>
  <realm-name>JaasLogin</realm-name>
</login-config>

ہم نے اپنے سیکورٹی دائرے کا نام بیان کیا اور تصدیق کا طریقہ - BASIC بیان کیا۔ یہ توثیق کی ان اقسام میں سے ایک ہے جو Servlet API میں سیکشن " 13.6 Authentication " میں بیان کی گئی ہے۔ رہ گیا n