OpenID কানেক্ট: কাস্টম থেকে স্ট্যান্ডার্ড পর্যন্ত অভ্যন্তরীণ অ্যাপ্লিকেশনের অনুমোদন

কয়েক মাস আগে, আমি আমাদের শত শত অভ্যন্তরীণ অ্যাপ্লিকেশনের অ্যাক্সেস পরিচালনা করার জন্য একটি OpenID কানেক্ট সার্ভার বাস্তবায়ন করছিলাম। আমাদের নিজস্ব উন্নয়ন থেকে, একটি ছোট স্কেলে সুবিধাজনক, আমরা একটি সাধারণভাবে স্বীকৃত মানতে চলে এসেছি। কেন্দ্রীয় পরিষেবার মাধ্যমে অ্যাক্সেস একঘেয়ে ক্রিয়াকলাপগুলিকে ব্যাপকভাবে সহজ করে, অনুমোদনগুলি বাস্তবায়নের খরচ হ্রাস করে, আপনাকে অনেকগুলি প্রস্তুত-তৈরি সমাধান খুঁজে বের করতে দেয় এবং নতুনগুলি বিকাশ করার সময় আপনার মস্তিষ্ককে তাক করে না। এই নিবন্ধে, আমি এই রূপান্তর এবং আমরা পূরণ করতে পরিচালিত বাধাগুলি সম্পর্কে কথা বলব।

অনেক দিন আগে... সব কিভাবে শুরু হয়েছিল

কয়েক বছর আগে, যখন ম্যানুয়াল নিয়ন্ত্রণের জন্য অনেক অভ্যন্তরীণ অ্যাপ্লিকেশন ছিল, আমরা কোম্পানির মধ্যে অ্যাক্সেস নিয়ন্ত্রণ করার জন্য একটি অ্যাপ্লিকেশন লিখেছিলাম। এটি একটি সাধারণ রেল অ্যাপ্লিকেশন যা কর্মীদের সম্পর্কে তথ্য সহ একটি ডাটাবেসের সাথে সংযুক্ত ছিল, যেখানে বিভিন্ন কার্যকারিতার অ্যাক্সেস কনফিগার করা হয়েছিল। একই সময়ে, আমরা প্রথম SSO উত্থাপন করেছি, যা ক্লায়েন্ট এবং অনুমোদন সার্ভারের দিক থেকে টোকেনগুলির যাচাইকরণের উপর ভিত্তি করে, টোকেনটি এনক্রিপ্ট করা আকারে বিভিন্ন পরামিতি সহ প্রেরণ করা হয়েছিল এবং অনুমোদন সার্ভারে যাচাই করা হয়েছিল। এটি সবচেয়ে সুবিধাজনক বিকল্প ছিল না, যেহেতু প্রতিটি অভ্যন্তরীণ অ্যাপ্লিকেশনকে যুক্তির একটি উল্লেখযোগ্য স্তর বর্ণনা করতে হয়েছিল এবং কর্মচারী ডাটাবেসগুলি অনুমোদন সার্ভারের সাথে সম্পূর্ণরূপে সিঙ্ক্রোনাইজ করা হয়েছিল।

কিছু সময়ের পরে, আমরা কেন্দ্রীভূত অনুমোদনের কাজটি সহজ করার সিদ্ধান্ত নিয়েছি। SSO ব্যালেন্সারে স্থানান্তরিত হয়েছিল। OpenResty-এর সাহায্যে, Lua-এ একটি টেমপ্লেট যোগ করা হয়েছিল যা টোকেন চেক করে, জানতে পারে কোন অ্যাপ্লিকেশনে অনুরোধ করা যাচ্ছে এবং সেখানে অ্যাক্সেস আছে কিনা তা পরীক্ষা করতে পারে। এই পদ্ধতিটি অভ্যন্তরীণ অ্যাপ্লিকেশনগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করার কাজটিকে ব্যাপকভাবে সরল করেছে - প্রতিটি অ্যাপ্লিকেশনের কোডে, অতিরিক্ত যুক্তি বর্ণনা করার আর প্রয়োজন ছিল না। ফলস্বরূপ, আমরা বাহ্যিকভাবে ট্র্যাফিক বন্ধ করে দিয়েছি, এবং অ্যাপ্লিকেশনটি নিজেই অনুমোদন সম্পর্কে কিছুই জানত না।

তবে একটি সমস্যা অমীমাংসিত রয়ে গেছে। কর্মীদের সম্পর্কে তথ্যের প্রয়োজন এমন অ্যাপ্লিকেশনগুলির সম্পর্কে কী? অনুমোদন পরিষেবার জন্য একটি API লেখা সম্ভব ছিল, কিন্তু তারপরে আপনাকে এই জাতীয় প্রতিটি অ্যাপ্লিকেশনের জন্য অতিরিক্ত যুক্তি যোগ করতে হবে। উপরন্তু, আমরা আমাদের অভ্যন্তরীণ অনুমোদন সার্ভারে ওপেনসোর্সে অনুবাদের জন্য ভবিষ্যতে ভিত্তিক আমাদের স্ব-লিখিত অ্যাপ্লিকেশনগুলির একটির উপর নির্ভরতা থেকে মুক্তি পেতে চেয়েছিলাম। আমরা অন্য কোনো সময় এটি সম্পর্কে কথা হবে. উভয় সমস্যার সমাধান ছিল OAuth.

সাধারণ মানদণ্ডে

OAuth হল একটি বোধগম্য, সাধারণত স্বীকৃত অনুমোদনের মান, কিন্তু যেহেতু শুধুমাত্র এর কার্যকারিতা যথেষ্ট নয়, তারা অবিলম্বে OpenID Connect (OIDC) বিবেচনা করতে শুরু করে। OIDC নিজেই ওপেন অথেন্টিকেশন স্ট্যান্ডার্ডের তৃতীয় বাস্তবায়ন, যা OAuth 2.0 প্রোটোকলের (একটি ওপেন অথরাইজেশন প্রোটোকল) উপর একটি অ্যাড-অনে প্রবাহিত হয়েছে। এই সমাধানটি শেষ ব্যবহারকারী সম্পর্কে ডেটার অভাবের সমস্যাটি বন্ধ করে দেয় এবং অনুমোদন প্রদানকারীকে পরিবর্তন করাও সম্ভব করে তোলে।

যাইহোক, আমরা একটি নির্দিষ্ট প্রদানকারী নির্বাচন করিনি এবং আমাদের বিদ্যমান অনুমোদন সার্ভারের জন্য OIDC-এর সাথে একীকরণ যোগ করার সিদ্ধান্ত নিয়েছি। এই সিদ্ধান্তের পক্ষে সত্য যে OIDC শেষ ব্যবহারকারী অনুমোদনের ক্ষেত্রে খুবই নমনীয়। এইভাবে, আপনার বর্তমান অনুমোদন সার্ভারে OIDC সমর্থন বাস্তবায়ন করা সম্ভব হয়েছে।

আমাদের নিজস্ব OIDC সার্ভার বাস্তবায়নের উপায়

1) পছন্দসই ফর্ম তথ্য আনা

OIDC সংহত করার জন্য, বর্তমান ব্যবহারকারীর ডেটা এমন একটি ফর্মে আনতে হবে যা স্ট্যান্ডার্ড দ্বারা বোধগম্য হয়। OIDC-তে এটাকে দাবি করা হয়। দাবিগুলি মূলত ব্যবহারকারীর ডাটাবেসের চূড়ান্ত ক্ষেত্র (নাম, ইমেল, ফোন, ইত্যাদি)। বিদ্যমান স্ট্যাম্পের স্ট্যান্ডার্ড তালিকা, এবং এই তালিকায় অন্তর্ভুক্ত নয় এমন সবকিছুই কাস্টম হিসাবে বিবেচিত হয়৷ অতএব, আপনি যদি একটি বিদ্যমান OIDC প্রদানকারী বেছে নিতে চান তবে প্রথম যে বিষয়টিতে আপনাকে মনোযোগ দিতে হবে তা হল নতুন ব্র্যান্ডের সুবিধাজনক কাস্টমাইজেশনের সম্ভাবনা।

হলমার্কের গ্রুপটি নিম্নলিখিত উপসেটে মিলিত হয়েছে - স্কোপ। অনুমোদনের সময়, অ্যাক্সেসের অনুরোধ করা হয় নির্দিষ্ট ব্র্যান্ডগুলিতে নয়, তবে স্কোপে, এমনকি যদি স্কোপের কিছু ব্র্যান্ডের প্রয়োজন না হয়।

2) প্রয়োজনীয় অনুদান বাস্তবায়ন

OIDC ইন্টিগ্রেশনের পরবর্তী অংশ হল অনুমোদনের ধরন নির্বাচন এবং বাস্তবায়ন, তথাকথিত অনুদান। নির্বাচিত অ্যাপ্লিকেশন এবং অনুমোদন সার্ভারের মধ্যে মিথস্ক্রিয়া পরবর্তী দৃশ্যকল্প নির্বাচিত অনুদানের উপর নির্ভর করবে। সঠিক অনুদান বেছে নেওয়ার জন্য একটি অনুকরণীয় স্কিম নীচের চিত্রে দেখানো হয়েছে।

আমাদের প্রথম আবেদনের জন্য, আমরা সর্বাধিক সাধারণ অনুদান, অনুমোদন কোড ব্যবহার করেছি। অন্যদের থেকে এর পার্থক্য হল এটি একটি তিন-পদক্ষেপ, অর্থাৎ অতিরিক্ত পরীক্ষা চলছে। প্রথমে, ব্যবহারকারী অনুমোদনের অনুমতির জন্য একটি অনুরোধ করে, একটি টোকেন পায় - অনুমোদন কোড, তারপরে এই টোকেন দিয়ে, যেন ভ্রমণের জন্য একটি টিকিট সহ, একটি অ্যাক্সেস টোকেনের অনুরোধ করে। এই অনুমোদন স্ক্রিপ্টের সমস্ত প্রধান মিথস্ক্রিয়া অ্যাপ্লিকেশন এবং অনুমোদন সার্ভারের মধ্যে পুনঃনির্দেশের উপর ভিত্তি করে। আপনি এই অনুদান সম্পর্কে আরও পড়তে পারেন এখানে.

OAuth এই ধারণাটিকে মেনে চলে যে অনুমোদনের পরে প্রাপ্ত অ্যাক্সেস টোকেনগুলি অস্থায়ী হওয়া উচিত এবং গড়ে প্রতি 10 মিনিটে পরিবর্তন করা উচিত৷ অনুমোদন কোড অনুদান হল পুনঃনির্দেশের মাধ্যমে একটি তিন-পদক্ষেপ যাচাইকরণ, প্রতি 10 মিনিটে এমন একটি পদক্ষেপ চালু করা, সত্যি বলতে, চোখের জন্য সবচেয়ে আনন্দদায়ক কাজ নয়। এই সমস্যা সমাধানের জন্য, আরেকটি অনুদান রয়েছে - রিফ্রেশ টোকেন, যা আমরা আমাদের দেশেও ব্যবহার করেছি। এখানে সবকিছু সহজ। অন্য একটি অনুদান থেকে যাচাইয়ের সময়, প্রধান অ্যাক্সেস টোকেন ছাড়াও, আরেকটি জারি করা হয় - রিফ্রেশ টোকেন, যা শুধুমাত্র একবার ব্যবহার করা যেতে পারে এবং এর জীবনকাল সাধারণত অনেক বেশি হয়। এই রিফ্রেশ টোকেনের সাথে, যখন প্রধান অ্যাক্সেস টোকেনের TTL (টাইম টু লাইভ) শেষ হবে, তখন একটি নতুন অ্যাক্সেস টোকেনের অনুরোধ অন্য অনুদানের শেষ পয়েন্টে আসবে। ব্যবহৃত রিফ্রেশ টোকেন অবিলম্বে শূন্যে রিসেট করা হয়। এই চেকটি দ্বি-পদক্ষেপ এবং ব্যাকগ্রাউন্ডে সঞ্চালিত হতে পারে, ব্যবহারকারীর কাছে অজ্ঞাতভাবে।

3) কাস্টম ডেটা আউটপুট ফর্ম্যাট সেট আপ করুন

নির্বাচিত অনুদানগুলি বাস্তবায়িত হওয়ার পরে, অনুমোদন কাজ করে, এটি শেষ ব্যবহারকারী সম্পর্কে ডেটা পাওয়ার কথা উল্লেখ করার মতো। OIDC এর জন্য একটি পৃথক এন্ডপয়েন্ট রয়েছে, যেখানে আপনি আপনার বর্তমান অ্যাক্সেস টোকেন সহ ব্যবহারকারীর ডেটা অনুরোধ করতে পারেন এবং যদি এটি আপ টু ডেট থাকে। এবং যদি ব্যবহারকারীর ডেটা প্রায়শই পরিবর্তিত না হয়, এবং আপনাকে অনেকবার বর্তমানগুলি অনুসরণ করতে হবে, আপনি JWT টোকেনগুলির মতো একটি সমাধানে আসতে পারেন। এই টোকেনগুলিও মান দ্বারা সমর্থিত। JWT টোকেন নিজেই তিনটি অংশ নিয়ে গঠিত: হেডার (টোকেন সম্পর্কে তথ্য), পেলোড (যেকোনো প্রয়োজনীয় ডেটা) এবং স্বাক্ষর (স্বাক্ষর, টোকেনটি সার্ভার দ্বারা স্বাক্ষরিত হয় এবং আপনি পরে এটির স্বাক্ষরের উত্স পরীক্ষা করতে পারেন)।

OIDC বাস্তবায়নে, JWT টোকেনকে id_token বলা হয়। এটি একটি সাধারণ অ্যাক্সেস টোকেনের সাথে অনুরোধ করা যেতে পারে এবং যা বাকি আছে তা হল স্বাক্ষর যাচাই করা। অনুমোদন সার্ভারের ফরম্যাটে একগুচ্ছ পাবলিক কী সহ এর জন্য একটি পৃথক এন্ডপয়েন্ট রয়েছে জেডব্লিউকে. এবং এই কথা বলতে গেলে, এটি উল্লেখ করার মতো যে আরেকটি শেষ বিন্দু আছে, যা স্ট্যান্ডার্ডের উপর ভিত্তি করে RFC5785 OIDC সার্ভারের বর্তমান কনফিগারেশন প্রতিফলিত করে। এটিতে সমস্ত এন্ডপয়েন্ট ঠিকানা রয়েছে (স্বাক্ষর করার জন্য ব্যবহৃত পাবলিক কী রিংয়ের ঠিকানা সহ), সমর্থিত ব্র্যান্ড এবং স্কোপ, ব্যবহৃত এনক্রিপশন অ্যালগরিদম, সমর্থিত অনুদান ইত্যাদি।

উদাহরণস্বরূপ Google এ:

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
 "token_endpoint": "https://oauth2.googleapis.com/token",
 "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
 "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 "response_types_supported": [
  "code",
  "token",
  "id_token",
  "code token",
  "code id_token",
  "token id_token",
  "code token id_token",
  "none"
 ],
 "subject_types_supported": [
  "public"
 ],
 "id_token_signing_alg_values_supported": [
  "RS256"
 ],
 "scopes_supported": [
  "openid",
  "email",
  "profile"
 ],
 "token_endpoint_auth_methods_supported": [
  "client_secret_post",
  "client_secret_basic"
 ],
 "claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "locale",
  "name",
  "picture",
  "sub"
 ],
 "code_challenge_methods_supported": [
  "plain",
  "S256"
 ],
 "grant_types_supported": [
  "authorization_code",
  "refresh_token",
  "urn:ietf:params:oauth:grant-type:device_code",
  "urn:ietf:params:oauth:grant-type:jwt-bearer"
 ]
}

এইভাবে, id_token ব্যবহার করে, আপনি টোকেনের পেলোডে সমস্ত প্রয়োজনীয় হলমার্ক স্থানান্তর করতে পারেন এবং ব্যবহারকারীর ডেটা অনুরোধ করার জন্য প্রতিবার অনুমোদন সার্ভারের সাথে যোগাযোগ করতে পারবেন না। এই পদ্ধতির অসুবিধা হল যে সার্ভার থেকে ব্যবহারকারীর ডেটাতে পরিবর্তন অবিলম্বে আসে না, তবে একটি নতুন অ্যাক্সেস টোকেন সহ।

বাস্তবায়ন ফলাফল

সুতরাং, আমাদের নিজস্ব OIDC সার্ভার বাস্তবায়ন এবং অ্যাপ্লিকেশনের দিকে এটির সাথে সংযোগগুলি কনফিগার করার পরে, আমরা ব্যবহারকারীদের সম্পর্কে তথ্য স্থানান্তরের সমস্যার সমাধান করেছি।
যেহেতু OIDC একটি ওপেন স্ট্যান্ডার্ড, তাই আমাদের কাছে একটি বিদ্যমান প্রদানকারী বা সার্ভার বাস্তবায়ন বেছে নেওয়ার বিকল্প রয়েছে। আমরা কীক্লোক চেষ্টা করেছি, যা কনফিগার করার জন্য খুব সুবিধাজনক বলে প্রমাণিত হয়েছে, অ্যাপ্লিকেশন সাইডে সংযোগ কনফিগারেশন সেট আপ এবং পরিবর্তন করার পরে, এটি যেতে প্রস্তুত। অ্যাপ্লিকেশনের দিকে, যা অবশিষ্ট থাকে তা হল সংযোগ কনফিগারেশন পরিবর্তন করা।

বিদ্যমান সমাধান সম্পর্কে কথা বলা

আমাদের সংস্থার মধ্যে, প্রথম OIDC সার্ভার হিসাবে, আমরা আমাদের নিজস্ব বাস্তবায়ন একত্রিত করেছি, যা প্রয়োজন অনুসারে পরিপূরক ছিল। অন্যান্য প্রস্তুত-তৈরি সমাধানগুলির বিশদ পর্যালোচনার পরে, আমরা বলতে পারি যে এটি একটি মূল বিষয়। তাদের নিজস্ব সার্ভার বাস্তবায়নের সিদ্ধান্তের পক্ষে, প্রয়োজনীয় কার্যকারিতার অনুপস্থিতিতে প্রদানকারীদের পক্ষ থেকে উদ্বেগ ছিল, সেইসাথে একটি পুরানো সিস্টেমের উপস্থিতি যেখানে কিছু পরিষেবার জন্য বিভিন্ন কাস্টম অনুমোদন ছিল এবং বেশ কিছু কর্মীদের সম্পর্কে তথ্য ইতিমধ্যে সংরক্ষিত ছিল. যাইহোক, রেডিমেড বাস্তবায়নে, একীকরণের সুবিধা রয়েছে। উদাহরণ স্বরূপ, Keycloak এর নিজস্ব ইউজার ম্যানেজমেন্ট সিস্টেম আছে এবং ডেটা সরাসরি এতে সংরক্ষণ করা হয় এবং সেখানে আপনার ব্যবহারকারীদের অতিক্রম করা কঠিন হবে না। এটি করার জন্য, কীক্লোকের একটি API রয়েছে যা আপনাকে সমস্ত প্রয়োজনীয় স্থানান্তর ক্রিয়াগুলি সম্পূর্ণরূপে সম্পাদন করতে দেয়।

একটি প্রত্যয়িত, আকর্ষণীয়, আমার মতে, বাস্তবায়নের আরেকটি উদাহরণ হল ওরি হাইড্রা। এটি আকর্ষণীয় কারণ এটি বিভিন্ন উপাদান নিয়ে গঠিত। সংহত করার জন্য, আপনাকে আপনার ব্যবহারকারী ব্যবস্থাপনা পরিষেবাকে তাদের অনুমোদন পরিষেবার সাথে লিঙ্ক করতে হবে এবং প্রয়োজন অনুসারে প্রসারিত করতে হবে।

কীক্লোক এবং ওরি হাইড্রা একমাত্র অফ-দ্য-শেল্ফ সমাধান নয়। OpenID ফাউন্ডেশন দ্বারা প্রত্যয়িত একটি বাস্তবায়ন নির্বাচন করা ভাল। এই সমাধানগুলিতে সাধারণত একটি OpenID সার্টিফিকেশন ব্যাজ থাকে।

আপনি যদি আপনার OIDC সার্ভার রাখতে না চান তাহলে বিদ্যমান অর্থ প্রদানকারীর কথাও ভুলবেন না। আজ অনেক ভাল বিকল্প আছে।

পরবর্তী কি

অদূর ভবিষ্যতে, আমরা অন্যভাবে অভ্যন্তরীণ পরিষেবাগুলিতে ট্রাফিক বন্ধ করতে যাচ্ছি। আমরা OAuth ভিত্তিক একটি প্রক্সিতে OpenResty ব্যবহার করে ব্যালেন্সারে আমাদের বর্তমান SSO স্থানান্তর করার পরিকল্পনা করছি। এখানে ইতিমধ্যে অনেক রেডিমেড সমাধান রয়েছে, উদাহরণস্বরূপ:
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

অতিরিক্ত উপকরণ

jwt.io - JWT টোকেন যাচাই করার জন্য ভাল পরিষেবা
openid.net/developers/certified - প্রত্যয়িত OIDC বাস্তবায়নের তালিকা

উত্স: www.habr.com