OpenID Connect: הרשאה של יישומים פנימיים מהתאמה אישית לסטנדרטית

לפני מספר חודשים, הטמעתי שרת OpenID Connect לניהול גישה למאות מהיישומים הפנימיים שלנו. מהפיתוחים שלנו, נוחים בקנה מידה קטן יותר, עברנו לסטנדרט מקובל. גישה דרך השירות המרכזי מפשטת מאוד פעולות מונוטוניות, מפחיתה את עלות הטמעת הרשאות, מאפשרת למצוא פתרונות מוכנים רבים ולא לעצבן את המוח בעת פיתוח פתרונות חדשים. במאמר זה אדבר על המעבר הזה ועל המהמורות שהצלחנו למלא.

מזמן... איך הכל התחיל

לפני מספר שנים, כשהיו יותר מדי אפליקציות פנימיות לשליטה ידנית, כתבנו אפליקציה לשליטה בגישה בתוך החברה. זו הייתה אפליקציית Rails פשוטה שהתחברה למסד נתונים עם מידע על עובדים, שבו הוגדרה גישה לפונקציונליות שונות. במקביל העלינו את ה-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 הוא הבחירה והיישום של סוגי הרשאות, מה שנקרא מענקים. התרחיש הנוסף של אינטראקציה בין האפליקציה שנבחרה לשרת ההרשאה יהיה תלוי בהענקה שנבחרה. תכנית לדוגמה לבחירת המענק הנכון מוצגת באיור שלהלן.

עבור הבקשה הראשונה שלנו, השתמשנו במענק הנפוץ ביותר, קוד ההרשאה. ההבדל שלו מאחרים הוא שזהו שלושה שלבים, כלומר. עובר בדיקות נוספות. ראשית, המשתמש מגיש בקשה לאישור אישור, מקבל אסימון - קוד הרשאה, ואז עם האסימון הזה, כאילו עם כרטיס לנסיעה, מבקש אסימון גישה. כל האינטראקציה העיקרית של סקריפט ההרשאה הזה מבוססת על הפניות מחדש בין האפליקציה לשרת ההרשאות. תוכל לקרוא עוד על מענק זה כאן.

OAuth דבקה בתפיסה לפיה אסימוני הגישה המתקבלים לאחר ההרשאה צריכים להיות זמניים ורצוי להשתנות כל 10 דקות בממוצע. הענקת קוד ההרשאה היא אימות בן שלושה שלבים באמצעות הפניות מחדש, כל 10 דקות להפוך צעד כזה, למען האמת, היא לא המשימה הכי נעימה לעיניים. כדי לפתור בעיה זו יש מענק נוסף - Refresh Token, שגם בו השתמשנו בארצנו. הכל יותר קל כאן. במהלך אימות ממענק אחר, בנוסף לאסימון הגישה הראשי, מונפק עוד אחד - Refresh Token, שניתן להשתמש בו רק פעם אחת ואורך חייו לרוב ארוך בהרבה. עם Refresh Token זה, כאשר ה-TTL (Time to Live) של אסימון הגישה הראשי מסתיים, הבקשה לאסימון גישה חדש תגיע לנקודת הקצה של מענק נוסף. ה-Refresh Token בשימוש מאופס מיד לאפס. בדיקה זו היא דו-שלבית וניתן לבצע אותה ברקע, באופן בלתי מורגש למשתמש.

3) הגדר פורמטים מותאמים אישית של פלט נתונים

לאחר יישום המענקים שנבחרו, ההרשאה עובדת, ראוי להזכיר קבלת נתונים על משתמש הקצה. ל- OIDC יש נקודת קצה נפרדת עבור זה, שבה אתה יכול לבקש נתוני משתמש עם אסימון הגישה הנוכחי שלך ואם הוא מעודכן. ואם הנתונים של המשתמש לא משתנים לעתים קרובות כל כך, ואתה צריך לעקוב אחר אלה הנוכחיים פעמים רבות, אתה יכול להגיע לפתרון כמו JWT tokens. אסימונים אלה נתמכים גם על ידי התקן. אסימון JWT עצמו מורכב משלושה חלקים: כותרת (מידע על האסימון), מטען (כל הנתונים הדרושים) וחתימה (חתימה, האסימון חתום על ידי השרת ותוכלו לבדוק מאוחר יותר את מקור החתימה שלו).

ביישום OIDC, אסימון JWT נקרא id_token. ניתן לבקש אותו יחד עם אסימון גישה רגיל וכל מה שנותר הוא לאמת את החתימה. לשרת ההרשאה יש נקודת קצה נפרדת עבור זה עם חבורה של מפתחות ציבוריים בפורמט J.W.K.. ואם כבר מדברים על זה, ראוי להזכיר שיש נקודת קצה נוספת, שבהסתמך על התקן RFC5785 משקף את התצורה הנוכחית של שרת OIDC. הוא מכיל את כל כתובות נקודות הקצה (כולל הכתובת של טבעת המפתחות הציבורית המשמשת לחתימה), מותגים והיקפים נתמכים, אלגוריתמי הצפנה משומשים, מענקים נתמכים וכו'.

למשל בגוגל:

{
 "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 שיאפשר לכם לבצע באופן מלא את כל פעולות ההעברה הדרושות.

דוגמה נוספת למימוש מוסמך, מעניין, לדעתי, הוא אורי הידרה. זה מעניין כי זה מורכב ממרכיבים שונים. כדי להשתלב, תצטרך לקשר את שירות ניהול המשתמשים שלך לשירות ההרשאות שלהם ולהרחיב לפי הצורך.

Keycloak ואורי הידרה הם לא פתרונות המדף היחידים. עדיף לבחור יישום מאושר על ידי קרן OpenID. לפתרונות אלה יש בדרך כלל תג אישור OpenID.

אל תשכח גם מספקים בתשלום קיימים אם אינך רוצה לשמור על שרת ה-OIDC שלך. היום יש הרבה אפשרויות טובות.

מה הלאה

בעתיד הקרוב, אנחנו הולכים לסגור את התנועה לשירותים פנימיים בדרך אחרת. אנו מתכננים להעביר את ה-SSO הנוכחי שלנו במאזן באמצעות OpenResty ל-proxy המבוסס על OAuth. יש כאן כבר הרבה פתרונות מוכנים, למשל:
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