streamalism.org

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

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

לבסוף נראה כיצד להשתמש בתוסף Spring Security Kerberos ליצירת יישומים המופעלים עבור Kerberos עם SPNEGO.

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

2. הבנת קרברוס

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

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

2.1. מקרה פשוט לשימוש עבור Kerberos

בואו נערוך מצב היפותטי כדי להדגים זאת.

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

איך קרברוס יכול לעזור לנו כאן? Kerberos מציגה צד שלישי בשם Key Distribution Center (KDC), שיש לו אמון הדדי עם כל צומת ברשת. בואו נראה איך זה יכול לעבוד במקרה שלנו:

2.2. היבטים עיקריים בפרוטוקול Kerberos

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

אמנם דיון מפורט בפרוטוקול Kerberos אינו אפשרי כאן, בואו נעבור כמה היבטים בולטים:

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

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

3. הבנת SPNEGO

SPNEGO מייצג מנגנון משא ומתן פשוט ומוגן GSS-API. ממש שם! בואו נראה קודם מה מייצג GSS-API. ממשק התוכנית ליישום שירותי אבטחה כללי (GSS-API) אינו אלא תקן IETF ללקוח ולשרת לתקשר בצורה מאובטחת וספקית-אגנוסטית.

SPNEGO הוא חלק מ- GSS-API ללקוח ולשרת לניהול משא ומתן לבחירת מנגנון האבטחה לשימוש, למשל, Kerberos או NTLM.

4. למה אנחנו צריכים SPNEGO עם קרברוס?

כפי שראינו בפרק הקודם, Kerberos הוא פרוטוקול אימות רשת טהור הפועל בעיקר בשכבת התחבורה (TCP / UDP). אמנם זה טוב למקרי שימוש רבים, אך זה לא נוגע לדרישות עבור האינטרנט המודרני. אם יש לנו יישום הפועל על הפשטה גבוהה יותר, כמו HTTP, לא ניתן להשתמש ישירות ב- Kerberos.

כאן SPNEGO נעזרת בעזרתנו. במקרה של יישום אינטרנט, התקשורת מתרחשת בעיקר בין דפדפן אינטרנט כמו Chrome לבין שרת אינטרנט כמו Tomcat המארח את יישום האינטרנט באמצעות HTTP. אם הם מופעלים, הם יכולים לנהל משא ומתן על Kerberos כמנגנון אבטחה באמצעות SPNEGO ולהחליף כרטיסים כאסימונים של SPNEGO באמצעות HTTP.

אז איך זה משנה את התרחיש שלנו שהוזכר קודם? בואו נחליף את לקוח הדואר הפשוט שלנו בדפדפן אינטרנט ובשרת דואר ביישום אינטרנט:

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

• מכונת הלקוח מאמתת כנגד KDC ושומרת במטמון את ה- TGT
• דפדפן האינטרנט במחשב הלקוח מוגדר לשימוש ב- SPNEGO וב- Kerberos
• יישום האינטרנט מוגדר גם לתמיכה ב- SPNEGO וב- Kerberos
• יישום אינטרנט מעמיד אתגר "משא ומתן" לדפדפן האינטרנט שמנסה לגשת למשאב מוגן
• כרטיס שירות עטוף כאסימון SPNEGO ומוחלף ככותרת HTTP

5. דרישות

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

5.1. הגדרת KDC

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

• MIT הופך את היישום של Kerberos v5 לזמין עבור מספר מערכות הפעלה
• Apache Kerby הוא סיומת ל- Apache Directory, המספק קישור Java Kerberos
• Windows Server ממיקרוסופט תומך ב- Kerberos v5 בגיבוי מקורי על ידי Active Directory
• ל- Heimdel יש יישום של Kerberos v5

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

5.2. הגדרת משתמשים ב- KDC

עלינו להקים שני משתמשים - או, כפי שהם מכנים זאת, מנהלים - ב- KDC. אנו יכולים להשתמש בכלי שורת הפקודה "קדמין" למטרה זו. נניח שיצרנו ממלכה בשם "baeldung.com" במסד הנתונים של KDC והתחברנו ל- "kadmin" עם משתמש בעל הרשאות מנהל.

ניצור את המשתמש הראשון שלנו, אותו אנו רוצים לאמת מדפדפן אינטרנט, עם:

$ kadmin: addprinc -randkey kchandrakant -pw סיסמה המנהל "[דוא"ל מוגן]" נוצר.

נצטרך גם לרשום את יישום האינטרנט שלנו ב- KDC:

$ kadmin: addprinc -randkey HTTP / [סיסמה מוגנת באמצעות דואר אלקטרוני] -pw עיקרון "HTTP / [מוגן באמצעות דוא"ל]" נוצר.

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

עלינו לייצא את זה גם כקובץ keytab כדי להפוך אותו לזמין ליישום האינטרנט:

$ kadmin: ktadd -k baeldung.keytab HTTP / [מוגן בדוא"ל]

זה אמור לתת לנו קובץ בשם "baeldung.keytab".

5.3. תצורת דפדפן

עלינו לאפשר לדפדפן האינטרנט בו אנו משתמשים כדי לגשת למשאב מוגן ביישום האינטרנט עבור תוכנית האימות "משא ומתן". למרבה המזל, מרבית דפדפני האינטרנט המודרניים כמו Chrome תומכים ב"משא ומתן "כערכת אימות כברירת מחדל.

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

5.4. תצורת דומיין

מובן שאולי אין לנו תחומים בפועל לבדיקת יישום האינטרנט שלנו. אך למרבה הצער, איננו יכולים להשתמש ב- localhost או 127.0.0.1 או בכל כתובת IP אחרת עם אימות Kerberos. עם זאת, יש לכך פיתרון קל, הכולל הגדרת ערכים בקובץ "מארחים" כמו:

demo.kerberos.bealdung.com 127.0.0.1

6. אביב להצלתנו!

לבסוף, מאחר שהבהיר לנו את היסודות, הגיע הזמן לבדוק את התיאוריה. אך האם לא יהיה מסורבל ליצור יישום אינטרנט התומך ב- SPNEGO וב- Kerberos? לא אם אנו משתמשים באביב. לאביב יש הרחבה של Kerberos כחלק מ- Spring Security התומך ב- SPNEGO עם Kerberos בצורה חלקה.

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

6.1. תלות Maven

הדבר הראשון שעלינו להגדיר הם התלות:

 org.springframework.security.kerberos spring-security-kerberos-web $ {kerberos.extension.version} org.springframework.security.kerberos spring-security-kerberos-client $ {kerberos.extension.version} 

תלות זו זמינה להורדה ממייבען סנטרל.

6.2. תצורות SPNEGO

ראשית, SPNEGO משולב באבטחת אביב כ- לְסַנֵן ב HTTPS אבטחה:

התצורה הריקה מוגנת @Override (HttpSecurity http) זורקת חריג {http.authorizeRequests () .anyRequest () .authenticated () .and () .addFilterBefore (spnegoAuthenticationProcessingFilter (authenticationManagerBean ()), BasicAuthenticationFilter.class. }

זה מראה רק את החלק הנדרש להגדרת תצורת SPNEGO לְסַנֵן ואינו שלם HTTPS אבטחה תצורה, אותה יש להגדיר בהתאם לדרישות האבטחה של היישום.

בשלב הבא עלינו לספק את ה- SPNEGO לְסַנֵן כפי ש אפונה:

@Bean ציבורי SpnegoAuthenticationProcessingFilter spnegoAuthenticationProcessingFilter (AuthenticationManager authenticationManager) {SpnegoAuthenticationProcessingFilter filter = new SpnegoAuthenticationProcessingFilter (); filter.setAuthenticationManager (authenticationManager); מסנן החזרה; }

6.3. תצורות Kerberos

בנוסף, אנו יכולים להגדיר את Kerberos על ידי הוספה אימות ספק ל AuthenticationManagerBuilder באבטחת אביב:

תצורת הריק המוגנת על ידי @Override (AuthenticationManagerBuilder auth) זורקת Exception {auth .authenticationProvider (kerberosAuthenticationProvider ()) .authenticationProvider (kerberosServiceAuthenticationProvider ()); }

הדבר הראשון שעלינו לספק הוא Kerberos אימות ספק כ אפונה. זהו יישום של אימות ספקוכאן קבענו SunJaasKerberosClient כ KerberosClient:

@Bean ציבורי KerberosAuthenticationProvider kerberosAuthenticationProvider () {KerberosAuthenticationProvider provider = חדש KerberosAuthenticationProvider (); לקוח SunJaasKerberosClient = SunJaasKerberosClient חדש (); provider.setKerberosClient (לקוח); provider.setUserDetailsService (userDetailsService ()); ספק החזר; }

לאחר מכן, עלינו לספק א KerberosServiceAuthenticationProvider כ אפונה. זהו הכיתה המאמתת כרטיסי שירות של Kerberos או אסימוני SPNEGO:

@Bean ציבורי KerberosServiceAuthenticationProvider kerberosServiceAuthenticationProvider () {KerberosServiceAuthenticationProvider ספק = חדש KerberosServiceAuthenticationProvider (); provider.setTicketValidator (sunJaasKerberosTicketValidator ()); provider.setUserDetailsService (userDetailsService ()); ספק החזר; }

לבסוף, עלינו לספק א SunJaasKerberosTicketValidator כ אפונה. זהו יישום של KerberosTicketValidator ומשתמש במודול הכניסה של SUN JAAS:

@Bean ציבורי SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator () {SunJaasKerberosTicketValidator ticketValidator = SunJaasKerberosTicketValidator חדש (); ticketValidator.setServicePrincipal ("HTTP / [דוא"ל מוגן]"); ticketValidator.setKeyTabLocation (FileSystemResource חדש ("baeldung.keytab")); כרטיס חזרה מאמת; }

6.4. פרטי המשתמש

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

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

6.5. הפעלת האפליקציה

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

היישום אמור להיות מסוגל לעבד אותו באמצעות האישורים בקובץ keytab ולהגיב באימות מוצלח.

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

7. שימוש מעשי ב- SPNEGO וב- Kerberos

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

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

8. מסקנה

לסיכום, במדריך זה הבנו את היסודות של פרוטוקול האימות של Kerberos. דנו גם ב- SPNEGO כחלק מ- GSS-API וכיצד נוכל להשתמש בו בכדי להקל על אימות מבוסס Kerberos ביישום אינטרנט באמצעות HTTP. יתר על כן, ניסינו לבנות יישום אינטרנט קטן המנצל את התמיכה המובנית של Spring Security ב- SPNEGO עם Kerberos.

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

כמו תמיד, ניתן למצוא את הקוד ב- GitHub.