මාස කිහිපයකට පෙර මම අපගේ අභ්‍යන්තර යෙදුම් සිය ගණනක් සඳහා ප්‍රවේශය කළමනාකරණය කිරීමට OpenID Connect සේවාදායකයක් ක්රියාත්මක කරමින් සිටියෙමි. කුඩා පරිමාණයෙන් පහසු වූ අපගේම වර්ධනයන්ගෙන් අපි සාමාන්යයෙන් පිළිගත් ප්‍රමිතියකට ගියෙමු. මධ්‍යම සේවාවක් හරහා ප්රවේශ වීම ඒකාකාරී මෙහෙයුම් සැලකිය යුතු ලෙස සරල කරයි, අවසර ක්රියාත්මක කිරීමේ පිරිවැය අඩු කරයි, බොහෝ සූදානම් කළ විසඳුම් සොයා ගැනීමට සහ නව ඒවා සංවර්ධනය කිරීමේදී ඔබේ මොළය අවුල් නොකරන්න. මෙම ලිපියෙන් මම මෙම සංක්‍රාන්තිය සහ අපට පහර දීමට සමත් වූ ගැටිති ගැන කතා කරමි.
බොහෝ කලකට පෙර ... සියල්ල ආරම්භ වූ තැන
වසර කිහිපයකට පෙර, අභ්‍යන්තර යෙදුම් අතින් කළමනාකරණය කිරීමට නොහැකි වූ විට, අපි සමාගම තුළ ප්‍රවේශය පාලනය කිරීමට යෙදුමක් ලිව්වෙමු. එය විවිධ ක්‍රියාකාරකම් සඳහා ප්‍රවේශය වින්‍යාස කර ඇති සේවකයින් පිළිබඳ තොරතුරු සහිත දත්ත සමුදායකට සම්බන්ධ වූ සරල රේල්ස් යෙදුමකි. ඒ අතරම, අපි පළමු SSO දියත් කළෙමු, එය සේවාලාභියාගේ සහ බලයලත් සේවාදායකයේ ටෝකන සත්‍යාපනය මත පදනම් වූ අතර, ටෝකනය පරාමිති කිහිපයක් සමඟ සංකේතාත්මක ආකාරයෙන් සම්ප්‍රේෂණය කර බලයලත් සේවාදායකයේ සත්‍යාපනය කරන ලදී. සෑම අභ්‍යන්තර යෙදුමකටම සැලකිය යුතු තාර්කික ස්ථරයක් විස්තර කිරීමට සිදු වූ අතර සේවක දත්ත සමුදායන් බලයලත් සේවාදායකය සමඟ සම්පුර්ණයෙන්ම සමමුහුර්ත කර ඇති බැවින් මෙය වඩාත් පහසු විකල්පය නොවේ.
ටික වේලාවකට පසු, මධ්‍යගත බලය පැවරීමේ කාර්යය සරල කිරීමට අපි තීරණය කළෙමු. SSO ශේෂය වෙත මාරු කරන ලදී. OpenResty ආධාරයෙන්, ටෝකන පරීක්ෂා කරන, ඉල්ලීම කුමන යෙදුම වෙත යන්න දැන සිටි සහ එහි ප්‍රවේශය තිබේදැයි පරීක්ෂා කළ හැකි අච්චුවක් Lua වෙත එක් කරන ලදී. මෙම ප්‍රවේශය අභ්‍යන්තර යෙදුම් වෙත ප්‍රවේශය පාලනය කිරීමේ කාර්යය බෙහෙවින් සරල කළේය - එක් එක් යෙදුමේ කේතයේ අමතර තර්ක විස්තර කිරීමට තවදුරටත් අවශ්ය නොවීය. එහි ප්‍රතිඵලයක් වශයෙන්, අපි ගමනාගමනය බාහිරව වසා දැමූ නමුත්, යෙදුමම අවසරය ගැන කිසිවක් දැන සිටියේ නැත.
කෙසේ වෙතත්, එක් ගැටළුවක් නොවිසඳී පැවතුනි. සේවක තොරතුරු අවශ්ය යෙදුම් ගැන කුමක් කිව හැකිද? අවසර දීමේ සේවාව සඳහා API ලිවීමට හැකි විය, නමුත් එවිට ඔබට එවැනි එක් එක් යෙදුම සඳහා අමතර තර්ක එකතු කිරීමට සිදුවේ. ඊට අමතරව, අපගේ අභ්‍යන්තර අවසර සේවාදායකය මත තවදුරටත් OpenSource වෙත පරිවර්තනය කිරීම කෙරෙහි අවධානය යොමු කර ඇති අපගේ ස්වයං-ලිඛිත යෙදුමක් මත යැපීම ඉවත් කිරීමට අපට අවශ්ය විය. අපි ඒ ගැන වෙන වෙලාවක කියන්නම්. ගැටළු දෙකටම විසඳුම OAuth විය.
සාමාන්යයෙන් පිළිගත් සම්මතයන් කරා
OAuth යනු පැහැදිලි, සාමාන්යයෙන් පිළිගත් අවසර ප්‍රමිතියකි, නමුත් එහි ක්‍රියාකාරීත්වය පමණක් ප්‍රමාණවත් නොවන බැවින්, OpenID Connect (OIDC) වහාම සලකා බලන ලදී. OIDC යනු විවෘත සත්‍යාපන ප්‍රමිතියේ තුන්වන ක්රියාත්මක කිරීම වන අතර එය OAuth 2.0 ප්‍රොටෝකෝලයේ (විවෘත අවසර ප්‍රොටෝකෝලය) සුපිරි කට්ටලයක් බවට පරිණාමය වී ඇත. මෙම විසඳුම අවසාන පරිශීලකයා පිළිබඳ දත්ත නොමැතිකම පිළිබඳ ගැටළුව විසඳන අතර, අවසර සැපයුම්කරු වෙනස් කිරීමට ද හැකි වේ.
කෙසේ වෙතත්, අපි නිශ්චිත සැපයුම්කරුවෙකු තෝරා නොගත් අතර අපගේ පවතින අවසර සේවාදායකය සඳහා OIDC සමඟ ඒකාබද්ධ කිරීම එක් කිරීමට තීරණය කළෙමු. අවසාන පරිශීලක අවසරය අනුව OIDC ඉතා නම්‍යශීලී බව මෙම තීරණයට සහාය විය. මේ අනුව, ඔබගේ වත්මන් අවසර සේවාදායකය මත OIDC සහාය ක්රියාත්මක කිරීමට හැකි විය.
අපගේම OIDC සේවාදායකය ක්රියාත්මක කිරීමට අපගේ මාර්ගය
1) දත්ත අවශ්ය පෝරමයට ගෙන එන්න
OIDC ඒකාබද්ධ කිරීම සඳහා, වත්මන් පරිශීලක දත්ත සම්මතයට තේරුම් ගත හැකි ආකෘතියකට ගෙන ඒම අවශ්ය වේ. OIDC හි මෙය හිමිකම් ලෙස හැඳින්වේ. වෙළඳ නාම යනු පරිශීලක දත්ත ගබඩාවේ (නම, විද්‍යුත් තැපෑල, දුරකථනය, ආදිය) අවසාන ක්ෂේත්‍ර වේ. පවතී , සහ මෙම ලැයිස්තුවේ ඇතුළත් නොවන සියල්ල චාරිත්ර ලෙස සලකනු ලැබේ. එබැවින්, ඔබට දැනට පවතින OIDC සපයන්නෙකු තෝරා ගැනීමට අවශ්ය නම් ඔබ අවධානය යොමු කළ යුතු පළමු කරුණ වන්නේ නව මුද්දර පහසුවෙන් අභිරුචිකරණය කිරීමේ හැකියාවයි.
ලකුණු සමූහය පහත උප කුලකයට ඒකාබද්ධ වේ - විෂය පථය. අවසර දීමේදී, විෂය පථයෙන් සමහර ලකුණු අවශ්ය නොවූවත්, ප්‍රවේශය ඉල්ලා සිටින්නේ නිශ්චිත ලකුණු වෙත නොව, විෂය පථ වෙතය.
2) අවශ්ය ප්‍රදාන ක්රියාත්මක කරන ලදී
OIDC ඒකාබද්ධතාවයේ මීළඟ කොටස වන්නේ ප්‍රදාන ලෙස හැඳින්වෙන අවසර වර්ග තෝරා ගැනීම සහ ක්රියාත්මක කිරීමයි. තෝරාගත් යෙදුම සහ බලයලත් සේවාදායකය අතර අන්තර්ක්‍රියා පිළිබඳ වැඩිදුර දර්ශනය තෝරාගත් ප්‍රදානය මත රඳා පවතී. නිවැරදි දීමනාව තෝරාගැනීම සඳහා ආසන්න යෝජනා ක්‍රමයක් පහත රූපයේ දැක්වේ.
අපගේ පළමු යෙදුම සඳහා, අපි වඩාත් පොදු ප්‍රදානය භාවිතා කළෙමු - බලය පැවරීමේ කේතය. අනෙක් ඒවාට වඩා එහි වෙනස වන්නේ එය පියවර තුනකි, i.e. අතිරේක පරීක්ෂණයකට භාජනය වේ. පළමුව, පරිශීලකයා අවසර දීමේ අවසරය සඳහා ඉල්ලීමක් කරයි, අවසර කේත ටෝකනයක් ලබා ගනී, පසුව මෙම ටෝකනය සමඟ, ගමන් ටිකට් පතක් මෙන්, ප්රවේශ ටෝකනයක් ඉල්ලා සිටී. මෙම බලය පැවරීමේ අවස්ථාවෙහි සියලුම ප්‍රධාන අන්තර්ක්‍රියා යෙදුම සහ බලයලත් සේවාදායකය අතර යළි-යොමුවීම් මත පදනම් වේ. ඔබට මෙම දීමනාව ගැන වැඩිදුර කියවිය හැකිය .
OAuth අනුමැතියෙන් පසු ලැබෙන ප්රවේශ ටෝකන තාවකාලික විය යුතු අතර සාමාන්යයෙන් සෑම විනාඩි 10කට වරක්ම වෙනස් විය යුතුය යන සංකල්පයට අනුගත වේ. බලය පැවරීමේ කේතය ප්‍රදානය යනු යළි-යොමුවීම් හරහා පියවර තුනක සත්‍යාපනයකි; සෑම මිනිත්තු 10 කට වරක් එවැනි පියවරක් සිදු කිරීම, අවංකව කිවහොත්, ඇසට වඩාත්ම ප්‍රසන්න කාර්යය නොවේ. මෙම ගැටළුව විසඳීම සඳහා, තවත් ප්‍රදානයක් ඇත - Refresh Token, අපි ද භාවිතා කළෙමු. මෙහි සෑම දෙයක්ම සරලයි. වෙනත් ප්‍රදානයකින් සත්‍යාපනය කිරීමේදී, ප්‍රධාන ප්රවේශ ටෝකනයට අමතරව, තවත් එකක් නිකුත් කරනු ලැබේ - එක් වරක් පමණක් භාවිතා කළ හැකි Refresh Token, රීතියක් ලෙස, එහි ජීවිත කාලය සැලකිය යුතු ලෙස දිගු වේ. මෙම නැවුම් ටෝකනය සමඟ, ප්‍රධාන ප්රවේශ ටෝකනයේ TTL (සජීවී කිරීමට කාලය) අවසන් වූ විට, නව ප්රවේශ ටෝකනයක් සඳහා ඉල්ලීමක් වෙනත් ප්‍රදානයක අවසාන ලක්ෂ්‍යයට පැමිණේ. භාවිතා කරන ලද නැවුම් ටෝකනය වහාම බිංදුවට යළි පිහිටුවනු ලැබේ. මෙම චෙක්පත දෙපියවර වන අතර පරිශීලකයාගේ අවධානයට ලක් නොවී පසුබිමේ සිදු කළ හැක.
3) වින්‍යාසගත පරිශීලක දත්ත ප්‍රතිදාන ආකෘති
තෝරාගත් ප්‍රදාන ක්රියාත්මක කළ පසු, අවසරය ක්රියාත්මක වේ, අවසාන පරිශීලක දත්ත ලැබීම ගැන සඳහන් කිරීම වටී. OIDC හට මේ සඳහා වෙනම අන්ත ලක්ෂ්යයක් ඇත, එහිදී ඔබට ඔබගේ වර්තමාන ප්රවේශ ටෝකනය සමඟ සහ එය යාවත්කාලීන නම් පරිශීලක දත්ත ඉල්ලා සිටිය හැක. ඒවගේම යූසර් ඩේටා එහෙම නිතර වෙනස් නොවුණත් දැනට තියෙන ඒවට කීප සැරයක් යන්න ඕන නම් JWT ටෝකන් වගේ විසඳුමකට එන්න පුළුවන්. මෙම ටෝකන සම්මතයෙන් ද සහාය දක්වයි. JWT ටෝකනය කොටස් තුනකින් සමන්විත වේ: ශීර්ෂකය (ටෝකනය පිළිබඳ තොරතුරු), ගෙවීම (අවශ්ය ඕනෑම දත්තයක්) සහ අත්සන (අත්සන, ටෝකනය සේවාදායකය විසින් අත්සන් කර ඇති අතර අනාගතයේදී ඔබට එහි අත්සනෙහි මූලාශ්රය පරීක්ෂා කළ හැකිය).
OIDC ක්රියාත්මක කිරීමේදී, JWT ටෝකනය id_token ලෙස හැඳින්වේ. එය සාමාන්‍ය ප්රවේශ ටෝකනයක් සමඟ ඉල්ලා සිටිය හැකි අතර ඉතිරිව ඇත්තේ අත්සන සත්‍යාපනය කිරීම පමණි. මෙම කාර්යය සඳහා, බලයලත් සේවාදායකයට ආකෘතියේ පොදු යතුරු පොකුරක් සහිත වෙනම අන්ත ලක්ෂ්යයක් ඇත . මේ ගැන කතා කිරීම, සම්මතය මත පදනම් වූ තවත් අවසාන ලක්ෂ්යයක් ඇති බව සඳහන් කිරීම වටී 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 විවෘත ප්‍රමිතියක් බැවින්, දැනට පවතින සැපයුම්කරුවෙකු හෝ සේවාදායක ක්රියාත්මක කිරීමක් තෝරා ගැනීමේ විකල්පය අපට දැන් තිබේ. අපි Keycloak උත්සාහ කළෙමු, එය වින්‍යාස කිරීමට ඉතා පහසු විය; යෙදුම් පැත්තේ සම්බන්ධතා වින්‍යාසයන් සැකසීමෙන් සහ වෙනස් කිරීමෙන් පසුව, එය යාමට සූදානම්ය. යෙදුම් පැත්තේ, ඉතිරිව ඇත්තේ සම්බන්ධතා වින්‍යාසයන් වෙනස් කිරීම පමණි.
පවතින විසඳුම් ගැන කතා කරනවා
අපගේ සංවිධානය තුළ, පළමු OIDC සේවාදායකය ලෙස, අපි අවශ්ය පරිදි පරිපූරණය කරන ලද අපගේම ක්රියාත්මක කිරීමක් එකතු කළෙමු. වෙනත් සූදානම් කළ විසඳුම් පිළිබඳ සවිස්තරාත්මක පරීක්ෂණයකින් පසුව, මෙය මතභේදාත්මක කරුණක් බව අපට පැවසිය හැකිය. අපගේම සේවාදායකය ක්රියාත්මක කිරීමේ තීරණය මෙහෙයවනු ලැබුවේ අවශ්ය ක්‍රියාකාරීත්වය නොමැතිකම මෙන්ම සමහර සේවාවන් සඳහා විවිධ අභිරුචි අවසරයන් අඩංගු පැරණි පද්ධතියක් තිබීම සහ දැනටමත් සේවකයින් පිළිබඳ දත්ත විශාල ප්‍රමාණයක් ගබඩා කර තිබීම සම්බන්ධයෙන් සපයන්නන්ගේ කනස්සල්ලෙනි. . කෙසේ වෙතත්, සූදානම් කළ ක්රියාත්මක කිරීම් වලදී, ඒකාබද්ධ කිරීම සඳහා පහසුව ඇත. උදාහරණයක් ලෙස, Keycloak සතුව තමන්ගේම පරිශීලක කළමනාකරණ පද්ධතියක් ඇති අතර දත්ත කෙලින්ම එහි ගබඩා කර ඇති අතර ඔබේ පරිශීලකයින් එහි ගෙනයාම අපහසු නොවනු ඇත. මෙම කාර්යය සඳහා, Keycloak සතුව API එකක් ඇති අතර එමඟින් ඔබට අවශ්ය සියලුම හුවමාරු ක්‍රියා සම්පූර්ණයෙන්ම සිදු කිරීමට ඉඩ සලසයි.
සහතික කළ, රසවත්, මගේ මතය අනුව, ක්රියාත්මක කිරීම සඳහා තවත් උදාහරණයක් Ory Hydra වේ. එය විවිධ සංරචක වලින් සමන්විත වන නිසා එය සිත්ගන්නා සුළුය. ඒකාබද්ධ කිරීමට, ඔබට ඔබේ පරිශීලක කළමනාකරණ සේවාව ඔවුන්ගේ අවසර සේවාවට සම්බන්ධ කර අවශ්ය පරිදි පුළුල් කිරීමට අවශ්ය වනු ඇත.
Keycloak සහ Ory Hydra එකම සූදානම් කළ විසඳුම් නොවේ. OpenID පදනම විසින් සහතික කරන ලද ක්රියාත්මක කිරීමක් තෝරාගැනීම වඩාත් සුදුසුය. මෙම විසඳුම්වලට සාමාන්යයෙන් OpenID සහතික කිරීමේ ලාංඡනයක් ඇත.
ඔබට ඔබේ OIDC සේවාදායකය තබා ගැනීමට අවශ්ය නැතිනම් දැනට පවතින ගෙවන සපයන්නන් ගැන අමතක නොකරන්න. අද බොහෝ හොඳ විකල්ප තිබේ.
ඊළඟට කුමක්ද
නුදුරු අනාගතයේදී, අපි වෙනත් ආකාරයකින් අභ්‍යන්තර සේවාවන් සඳහා ගමනාගමනය වසා දමන්නෙමු. අපි OAuth මත පදනම් වූ ප්‍රොක්සියකට OpenResty භාවිතා කරමින් balancer මත අපගේ වත්මන් SSO සංක්‍රමණය කිරීමට සැලසුම් කරමු. මෙහි බොහෝ සූදානම් කළ විසඳුම් ද ඇත, උදාහරණයක් ලෙස:
අතිරේක ද්රව්ය
- JWT ටෝකන පරීක්ෂා කිරීම සඳහා හොඳ සේවාවක්
- සහතික කළ OIDC ක්රියාත්මක කිරීම් ලැයිස්තුව
මූලාශ්රය: www.habr.com