מדריך מהיר לשימוש ב- UAA של יציקת ענן

1. סקירה כללית

חשבון משתמש ואימות של Cloud Foundry (CF UAA) הוא שירות ניהול ואישור זהויות. ליתר דיוק, זהו ספק OAuth 2.0 המאפשר אימות והנפקת אסימונים ליישומי לקוח.

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

אך לפני כן, הבה נבהיר את תפקידה של UAA במסגרת הרשאת OAuth 2.0.

2. Cloud Foundry UAA ו- OAuth 2.0

נתחיל בהבנת האופן בו UAA מתייחסת למפרט OAuth 2.0.

המפרט OAuth 2.0 מגדיר ארבעה משתתפים שיכולים להתחבר זה לזה: בעל משאבים, שרת משאבים, לקוח ושרת הרשאות.

כספקית OAuth 2.0, UAA ממלאת את תפקיד ה- שרת הרשאות. זה אומר המטרה העיקרית שלה היא הנפקת אסימוני גישה עבור לָקוּחַ יישומים ואימות אסימונים אלה עבור שרת משאביםס.

כדי לאפשר את האינטראקציה של משתתפים אלה עלינו להקים תחילה שרת UAA ואז ליישם שני יישומים נוספים: האחד כלקוח והשני כשרת משאבים.

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

3. הגדרת שרת UAA

ראשון, נתקין את UAA ונאכלס אותו בכמה נתוני הדגמה.

לאחר ההתקנה נרשום יישום לקוח בשם לקוח אינטרנט. לאחר מכן ניצור משתמש בשם מערער עם שני תפקידים, resource.read ו resource.write.

3.1. הַתקָנָה

UAA היא יישום אינטרנט של Java שניתן להריץ בכל מיכל servlet תואם. במדריך זה נשתמש בטומקט.

בואו ונמשיך הורד את מלחמת UAA והפקד אותה בטומקט שלנו פְּרִיסָה:

wget -O $ CATALINA_HOME / webapps / uaa.war \ //search.maven.org/remotecontent?filepath=org/cloudfoundry/identity/cloudfoundry-identity-uaa/4.27.0/cloudfoundry-identity-uaa-4.27.0. מִלחָמָה

אבל לפני שנתחיל, נצטרך להגדיר את מקור הנתונים ואת צמד המפתחות של JWS.

3.2. תצורה נדרשת

כברירת מחדל, UAA קורא תצורה מ- uaa.yml על מסלול הכיתה שלה. אבל מאז הרגע הורדנו את מִלחָמָה קובץ, עדיף לנו לספר ל- UAA מיקום מותאם אישית במערכת הקבצים שלנו.

אנחנו יכולים לעשות זאת על ידי הגדרת ה- UAA_CONFIG_PATH תכונה:

ייצא UAA_CONFIG_PATH = ~ / .uaa

לחלופין, אנו יכולים להגדיר CLOUD_FOUNDRY_CONFIG_PATH. לחלופין, אנו יכולים לציין מיקום מרוחק באמצעות UAA_CONFIG_URL.

לאחר מכן נוכל להעתיק את התצורה הנדרשת של UAA לנתיב התצורה שלנו:

wget -qO- //raw.githubusercontent.com/cloudfoundry/uaa/4.27.0/uaa/src/main/resources/required_configuration.yml \> $ UAA_CONFIG_PATH / uaa.yml

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

3.3. קביעת תצורה של מקור הנתונים

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

לצורך הדרכה זו, אנו נשתמש ב- HSQLDB:

ייצא SPRING_PROFILES = "ברירת מחדל, hsqldb"

כמובן, מכיוון שמדובר ביישום Boot Boot, נוכל גם לציין זאת ב uaa.yml כמו אביב.פרופילים תכונה.

3.4. קביעת תצורה של זוג המפתח של JWS

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

OpenSSL הופך את זה לפשוט:

openssl genrsa -out חתימת key.pem 2048 openssl rsa -in חיתום key.pem -pubout -out verificationkey.pem

שרת ההרשאה יעשה זאת סִימָן ה- JWT עם המפתח הפרטי, ושרת הלקוחות ומשאבי המשאבים שלנו יעשו זאת תאשר את החתימה הזו עם המפתח הציבורי.

נצא אותם אליהם JWT_TOKEN_SIGNING_KEY ו JWT_TOKEN_VERIFICATION_KEY:

ייצא JWT_TOKEN_SIGNING_KEY = $ (חתום לחתום.פם) ייצא JWT_TOKEN_VERIFICATION_KEY = $ (אימות חתול.פם) 

שוב, נוכל לציין את אלה ב uaa.yml דרך ה- מפתח jwt.token.signing ו מפתח jwt.token.verification נכסים.

3.5. הקמת UAA

לבסוף, בואו נתחיל את הדברים:

$ CATALINA_HOME / bin / catalina.sh לרוץ

בשלב זה, עלינו שיהיה לנו שרת UAA עובד // localhost: 8080 / uaa.

אם נלך ל // localhost: 8080 / uaa / infoואז נראה מידע בסיסי על ההפעלה

3.6. התקנת לקוח שורת הפקודה של UAA

לקוח שורת הפקודה CF UAA הוא הכלי העיקרי לניהול UAA, אך כדי להשתמש בו, עלינו להתקין את רובי קודם:

sudo apt להתקין rubygems פנינה להתקין cf-uaac

ואז נוכל להגדיר uaac להצביע על מופע הריצה של UAA:

יעד uaac // localhost: 8080 / uaa

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

3.7. אכלוס לקוחות ומשתמשים המשתמשים ב- UAAC

עכשיו שיש לנו uaac מותקן, בואו לאכלס את UAA בכמה נתוני הדגמה. לכל הפחות נצטרך: א לָקוּחַ, א מִשׁתַמֵשׁ, ו resource.read ו resource.write קבוצות.

אז כדי לבצע כל ניהול, נצטרך לאמת את עצמנו. אנו בוחרים את מנהל המחדל המשלוח עם UAA, שיש לו הרשאות ליצור לקוחות, משתמשים וקבוצות אחרים:

לקוח אסימון uaac קבל אדמיניסטרציה של מנהל מערכת

(כמובן, אנחנו בהחלט צריכים לשנות חשבון זה - דרך הקובץ oauth-clients.xml - לפני המשלוח!)

בעיקרון, אנו יכולים לקרוא פקודה זו כ: "תן לי אֲסִימוֹן, באמצעות לָקוּחַ אישורים עם client_id של מנהל ו סecret של מנהיג סוד“.

אם הכל ילך כשורה, נראה הודעת הצלחה:

הושג האסימון בהצלחה באמצעות מענק אישורי לקוח.

האסימון מאוחסן ב uaacהמדינה.

עכשיו, פועל כ מנהל, אנו יכולים לרשום לקוח בשם לקוח אינטרנט עם הוסף לקוח:

לקוח uaac להוסיף webappclient -s webappclientsecret \ - שם WebAppClient \ --scope resource.read, resource.write, openid, profile, email, address, phone \ --authorized_grant_types authorisation_code, refresh_token, client_credentials, password \ --authorities משאב \ - redirect_uri // localhost: 8081 / login / oauth2 / code / uaa

כמו כן, אנו יכולים לרשום משתמש בשם מערער עם משתמש הוסף:

משתמש uaac הוסף appuser -p appusersecret --emails [דוא"ל מוגן]

לאחר מכן נוסיף שתי קבוצות - resource.read ו resource.write - שימוש עם הוסף קבוצה:

קבוצת uaac הוסף resource.read קבוצת uaac הוסף resource.write

ולבסוף, נקצה את הקבוצות האלה מערער עם חבר הוסף:

חבר uaac הוסף resource.read appuser חבר uaac הוסף resource.write

פאי! אז מה שעשינו עד כה הוא:

  • UAA מותקן ומוגדר
  • מוּתקָן uaac
  • נוסף לקוח הדגמה, משתמשים וקבוצות

אז בואו נזכור את פיסות המידע הללו ונקפוץ לשלב הבא.

4. לקוח OAuth 2.0

בחלק הזה, נשתמש באביב אתחול ליצירת יישום לקוח OAuth 2.0.

4.1. הגדרת יישום

נתחיל בגישה ל- Spring Initializr וניצור יישום אינטרנט של Spring Boot. אנו בוחרים רק את אינטרנט ו לקוח OAuth2 רכיבים:

 org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-oauth2-client 

בדוגמה זו השתמשנו בגרסה 2.1.3 של Spring Boot.

הַבָּא, עלינו לרשום את הלקוח שלנו, webappלָקוּחַ.

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

#registration spring.security.oauth2.client.registration.uaa.client-id = webappclient spring.security.oauth2.client.registration.uaa.client-secret = webappclientsecret spring.security.oauth2.client.registration.uaa.scope = resource.read, resource.write, openid, profile #provider spring.security.oauth2.client.provider.uaa.issuer-uri = // localhost: 8080 / uaa / oauth / token

לקבלת מידע נוסף אודות מאפיינים אלה, נוכל לעיין במסמכי Java לרישום ולפולי הספק.

ומכיוון שאנחנו כבר משתמשים בנמל 8080 עבור UAA, בואו נריץ את זה ב- 8081:

server.port = 8081

4.2. התחברות

עכשיו אם ניגש ל- /התחברות נתיב, עלינו לקבל רשימה של כל הלקוחות הרשומים. במקרה שלנו, יש לנו רק לקוח רשום אחד:

לחיצה על הקישור תנתב אותנו לדף הכניסה של UAA:

הנה, בואו נכנס עם appuser / appusersecret.

הגשת הטופס אמורה להפנות אותנו לטופס אישור שבו המשתמש יכול לאשר או למנוע גישה ללקוח שלנו:

המשתמש יכול להעניק אילו הרשאות הוא רוצה. לענייננו, נבחר הכל למעט משאב: כתוב.

כל מה שהמשתמש יבדוק יהיו היקפי אסימון הגישה המתקבל.

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

{"jti": "f228d8d7486942089ff7b892c796d3ac", "sub": "0e6101d8-d14b-49c5-8c33-fc12d8d1cc7d", "scope": ["resource.read", "openid", "profile"], "client_id": " webappclient "// תביעות נוספות}

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

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

לשרת המשאבים שהושלם יהיו שני ממשקי API מוגנים: אחד הדורש את ה- resource.read היקף ואחר שדורש resource.write.

מה שנראה זה הלקוח, באמצעות היקפים שהענקנו, יוכל להתקשר ל - לקרוא ממשק API אך לא לִכתוֹב.

5. שרת משאבים

שרת המשאבים מארח את המשאבים המוגנים של המשתמש.

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

5.1. הגדרת יישום

כדי ליצור את שרת המשאבים שלנו, נשתמש שוב ב- Spring Initializr כדי ליצור יישום אינטרנט של Spring Boot. הפעם, נבחר באפשרות אינטרנט ו שרת משאבים OAuth2 רכיבים:

 org.springframework.boot spring-boot-starter-oauth2-resource-server org.springframework.boot spring-boot-starter-web 

כמו ביישום הלקוח, אנו משתמשים בגרסה 2.1.3 של Spring Boot.

השלב הבא הוא לציין את המיקום של CF UAA הפועל ב- application.properties קוֹבֶץ:

spring.security.oauth2.resourceserver.jwt.issuer-uri = // localhost: 8080 / uaa / oauth / token

כמובן, בואו לבחור גם כאן נמל חדש. 8082 יעבוד בסדר:

server.port = 8082

וזה הכל! עלינו להחזיק שרת משאבי עבודה וכברירת מחדל, כל הבקשות ידרוש אסימון גישה חוקי ב- הרשאה כּוֹתֶרֶת.

5.2. הגנה על ממשקי API של שרת משאבים

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

נוסיף a RestController עם שתי נקודות קצה, אחת מורשית למשתמשים שיש להם את resource.read היקף והשני למשתמשים שיש להם היקף resource.write:

@GetMapping ("/ read") ציבורי לקרוא מחרוזת (מנהל ראשי) {להחזיר "שלום לכתוב:" + principal.getName (); } @GetMapping ("/ write") ציבורי לכתוב מחרוזת (מנהל ראשי) {להחזיר "שלום לכתוב:" + principal.getName (); }

הַבָּא, נעקוף את תצורת Boot Boot המוגדרת כברירת מחדל כדי להגן על שני המשאבים:

המחלקה הציבורית @EnableWebSecurity OAuth2ResourceServerSecurityConfiguration מרחיבה את WebSecurityConfigurerAdapter {@Override מוגן ריק (HttpSecurity http) זורק חריגה {http.authorizeRequests () .antMatchers ("/ read / **"). HasAuthority ("SCOPE." כתוב / ** "). hasAuthority (" SCOPE_resource.write ") .anyRequest (). מאומת (). ו- () .oauth2ResourceServer (). jwt (); }}

שים לב שהקידומים שסופקו באסימון הגישה מוקדמים עם תְחוּם_ כאשר הם מתורגמים לבטחון אביב הוענק רשות.

5.3. בקשת משאב מוגן מלקוח

מיישום הלקוח, אנו נקרא לשני המקורות המוגנים באמצעות RestTemplate. לפני הגשת הבקשה, אנו מאחזרים את אסימון הגישה מההקשר ומוסיפים אותו ל- הרשאה כּוֹתֶרֶת:

פרטי מחרוזת callResourceServer (OAuth2AuthenticationToken authenticationToken, URL String) {OAuth2AuthorizedClient oAuth2AuthorizedClient = this.authorizedClientService. loadAuthorizedClient (authenticationToken.getAuthorizedClientRegistrationId (), authenticationToken.getName ()); OAuth2AccessToken oAuth2AccessToken = oAuth2AuthorizedClient.getAccessToken (); כותרות HttpHeaders = HttpHeaders חדשות (); headers.add ("Authorization", "Bearer" + oAuth2AccessToken.getTokenValue ()); // תגובת תשובת תשומת נקודת קצה למשאבים; }

שים לב, עם זאת, שנוכל להסיר את הפלטה הזו אם אנו משתמשים בה WebClient במקום RestTemplate.

לאחר מכן נוסיף שתי שיחות לנקודות הקצה של שרת המשאבים:

@ GetMapping ("/ read") ציבורי לקרוא מחרוזת (OAuth2AuthenticationToken authenticationToken) {String url = remoteResourceServer + "/ read"; החזר callResourceServer (authenticationToken, url); } @GetMapping ("/ write") כתיבת מחרוזות ציבורית (OAuth2AuthenticationToken authenticationToken) {String url = remoteResourceServer + "/ write"; החזר callResourceServer (authenticationToken, url); }

כצפוי, השיחה של /לקרוא API יצליח, אך לא ה- /לִכתוֹב אחד. מצב HTTP 403 אומר לנו שהמשתמש אינו מורשה.

6. מסקנה

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

קוד המקור המלא של הדוגמאות זמין באתר Github.


$config[zx-auto] not found$config[zx-overlay] not found