SSO על ארכיטקטורת שירות מיקרו. אנו משתמשים ב-Keycloak. חלק 1

בכל חברה גדולה, ו-X5 Retail Group אינה יוצאת דופן, ככל שהיא מתפתחת, מספר הפרויקטים הדורשים הרשאת משתמש גדל. עם הזמן, נדרש מעבר חלק של משתמשים מאפליקציה אחת לאחרת, ולאחר מכן יש צורך להשתמש בשרת Single-Sing-On (SSO) יחיד. אבל מה לגבי כאשר ספקי זהות כגון AD או אחרים שאין להם תכונות נוספות כבר נמצאים בשימוש בפרויקטים שונים. סוג של מערכות בשם "מתווכי זיהוי" יגיע לעזרה. הפונקציונליים ביותר הם הנציגים שלו, כמו Keycloak, ניהול Gravitee Access וכו'. לרוב, מקרי שימוש יכולים להיות שונים: אינטראקציה עם מכונה, השתתפות משתמשים וכו'. הפתרון חייב לתמוך בפונקציונליות גמישה וניתנת להרחבה שיכולה לשלב את כל הדרישות באחת, ופתרונות כאלה לחברה שלנו יש כעת מתווך אינדיקציות - Keycloak.

Keycloak הוא מוצר זהות ובקרת גישה בקוד פתוח המתוחזק על ידי RedHat. זהו הבסיס למוצרי החברה באמצעות SSO - RH-SSO.

מושגים בסיסיים

לפני שתתחיל להתמודד עם פתרונות וגישות, עליך להחליט במונחים וברצף של תהליכים:

זיהוי הוא הליך לזיהוי נושא לפי המזהה שלו (במילים אחרות, זוהי ההגדרה של שם, כניסה או מספר).

אימות - זהו הליך אימות (המשתמש נבדק עם סיסמה, המכתב נבדק בחתימה אלקטרונית וכו')

הרשאה - זוהי מתן גישה למשאב (לדוגמה, לדואר אלקטרוני).

גלימת מפתח של מתווך זהות

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

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

פונקציונליות בסיסית הנתמכת על ידי Keycloak:

• כניסה יחידה ויציאה יחידה עבור יישומי דפדפן.
• תמיכה ב-OpenID/OAuth 2.0/SAML.
• תיווך זהות - אימות באמצעות ספקי זהות חיצוניים OpenID Connect או SAML.
• התחברות חברתית - תמיכה בגוגל, GitHub, Facebook, Twitter לזיהוי משתמש.
• User Federation - סנכרון של משתמשים משרתי LDAP ו-Active Directory ושאר ספקי זהות.
• Kerberos bridge - שימוש בשרת Kerberos לאימות משתמש אוטומטי.
• מסוף ניהול - לניהול אחיד של הגדרות ואפשרויות פתרון דרך האינטרנט.
• מסוף ניהול חשבונות - לניהול עצמי של פרופיל המשתמש.
• התאמה אישית של הפתרון על בסיס הזהות הארגונית של החברה.
• אימות 2FA - תמיכה ב-TOTP/HOTP באמצעות Google Authenticator או FreeOTP.
• זרימות התחברות - רישום עצמי של משתמש, שחזור ואיפוס סיסמה, ואחרים אפשריים.
• ניהול הפעלות - מנהלי מערכת יכולים לנהל הפעלות משתמשים מנקודה אחת.
• Token Mappers - קשירת תכונות משתמש, תפקידים ושאר תכונות נדרשות לאסימונים.
• ניהול מדיניות גמיש על פני תחום, יישומים ומשתמשים.
• תמיכת CORS - למתאמי לקוח יש תמיכת CORS מובנית.
• ממשקי ספקי שירות (SPI) - מספר רב של SPIs המאפשרים התאמה אישית של היבטים שונים של השרת: זרימות אימות, ספקי זהות, מיפוי פרוטוקולים ועוד.
• מתאמי לקוח ליישומי JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• תמיכה בעבודה עם יישומים שונים התומכים בספריית OpenID Connect Relying Party או ספריית ספק שירות SAML 2.0.
• ניתן להרחבה באמצעות תוספים.

עבור תהליכי CI / CD, כמו גם אוטומציה של תהליכי ניהול ב-Keycloak, ניתן להשתמש ב- REST API / JAVA API. התיעוד זמין באופן אלקטרוני:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
API של JAVA https://www.keycloak.org/docs-api/8.0/javadocs/index.html

ספקי זהות ארגונית (On-Premise)

יכולת לאמת משתמשים באמצעות שירותי User Federation.

ניתן להשתמש גם באימות מעבר - אם משתמשים מבצעים אימות מול תחנות עבודה עם Kerberos (LDAP או AD), אז ניתן לאמת אותם אוטומטית ל-Keycloak ללא צורך להזין שוב את שם המשתמש והסיסמה שלהם.

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

רשימת ה-DBMS הנתמכים נרחבת וכוללת: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle ואחרים. הנבדקים ביותר עד כה הם Oracle 12C Release1 RAC ואשכול Galera 3.12 עבור MariaDB 10.1.19.

ספקי זהות - התחברות חברתית

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

אפשר להשתמש בספקי OpenID/SAML Identity לאימות משתמשים.

תרחישי הרשאה אופייניים באמצעות OAuth2 ב-Keycloak

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

זרימה מרומזת - בשימוש על ידי יישומי נייד או אינטרנט (אפליקציות הפועלות במכשיר של המשתמש).

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

Implicit Flow אינו תומך באסימוני רענון אסימון גישה.

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

מפרט OAuth2 מתואר ב
RFC-6749
RFC-8252
RFC-6819

אסימון JWT והיתרונות שלו

JWT (JSON Web Token) הוא תקן פתוח (https://tools.ietf.org/html/rfc7519) המגדיר דרך קומפקטית ומסוגלת להעברת מידע בצורה מאובטחת בין הצדדים כאובייקט JSON.

לפי התקן, האסימון מורכב משלושה חלקים בפורמט בסיס-64, מופרדים בנקודות. החלק הראשון נקרא header, שמכיל את סוג האסימון ואת שם אלגוריתם ה-hash להשגת חתימה דיגיטלית. החלק השני מאחסן את המידע הבסיסי (משתמש, תכונות וכו'). החלק השלישי הוא החתימה הדיגיטלית.

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

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

היתרונות העיקריים של שימוש בארכיטקטורת שירות מיקרו:

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

אסימון JWT - הרכב

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

סוג האסימון מאוחסן במקש "טייפ". מתעלמים מהמפתח 'סוג' ב-JWT. אם המפתח "typ" קיים, הערך שלו חייב להיות JWT כדי לציין שאובייקט זה הוא JSON Web Token.

המפתח השני "alg" מגדיר את האלגוריתם המשמש להצפנת האסימון. זה צריך להיות מוגדר ל-HS256 כברירת מחדל. הכותרת מקודדת ב-base64.

{ "alg": "HS256", "type": "JWT"}
מטען (תוכן) - המטען מאחסן כל מידע שצריך לבדוק. כל מפתח במטען מכונה "תביעה". לדוגמה, ניתן להיכנס לאפליקציה רק ​​בהזמנה (פרומו סגור). כשאנחנו רוצים להזמין מישהו להשתתף, אנחנו שולחים לו מכתב הזמנה. חשוב לבדוק שכתובת המייל שייכת למי שמקבל את ההזמנה ולכן נכלול כתובת זו במטען, לשם כך אנו שומרים אותה במפתח "מייל"

{ "אימייל": "[מוגן בדוא"ל]"}

מפתחות במטען יכולים להיות שרירותיים. עם זאת, יש כמה שמורות:

• iss (מנפיק) - מזהה את האפליקציה שממנה נשלח האסימון.
• sub (Subject) - מגדיר את נושא האסימון.
• aud (קהל) הוא מערך של מחרוזות או URI תלויי-רישיות המהווה רשימה של הנמענים של אסימון זה. כאשר הצד המקבל מקבל JWT עם המפתח הנתון, עליו לבדוק את נוכחותו של עצמו בנמענים - אחרת תתעלם מהאסימון.
• exp (זמן תפוגה) - מציין מתי יפוג האסימון. תקן JWT דורש מכל היישומים שלו לדחות אסימונים שפג תוקפם. מפתח exp חייב להיות חותמת זמן בפורמט יוניקס.
• nbf (Not Before) הוא זמן בפורמט יוניקס שקובע את הרגע שבו האסימון הופך לתקף.
• iat (הונפק ב) - מפתח זה מייצג את הזמן שבו האסימון הופק וניתן להשתמש בו כדי לקבוע את גיל ה-JWT. מפתח iat חייב להיות חותמת זמן בפורמט יוניקס.
• Jti (מזהה JWT) - מחרוזת המגדירה את המזהה הייחודי של אסימון זה, תלוי רישיות.

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

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

{"alg":"RSA1_5","payload":"A128CBC-HS256"}

בניית ארכיטקטורת אשכולות של Keycloak Failover

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

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

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

הדוגמה הפשוטה ביותר של התקנה סובלנית לתקלות.

מהם היתרונות של שימוש באשכול יחיד:

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

מה לחפש כשמתכננים אשכול

DBMS

Keycloak משתמש במערכת ניהול מסד נתונים לאחסון: ממלכות, לקוחות, משתמשים וכו'.
מגוון רחב של DBMS נתמך: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak מגיע עם מסד נתונים יחסי מובנה משלו. מומלץ להשתמש בסביבות לא עמוסות - כמו סביבות פיתוח.

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

מטמון מבוזר (Infinspan)

כדי שהאשכול יפעל כהלכה, נדרש סנכרון נוסף של סוגי המטמונים הבאים באמצעות JBoss Data Grid:

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

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

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

עבודה - משמש רק לשליחת הודעות לא חוקיות בין צמתי אשכול ומרכזי נתונים.

הפעלות משתמש - משמשות לאחסון נתונים על הפעלות משתמש שתקפות למשך הפעלת הדפדפן של המשתמש. המטמון חייב לעבד בקשות HTTP ממשתמש הקצה ומהאפליקציה.

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

איזון עומסים

מאזן העומס הוא נקודת הכניסה היחידה ל-keycloak וחייב לתמוך בהפעלות דביקות.

שרתי יישומים

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

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

מקור: www.habr.com