מבוא ל- Java SASL

ג'אווה טופ

רק הכרזתי על החדש למד אביב קורס, המתמקד ביסודות האביב 5 ומגף האביב 2:

>> בדוק את הקורס

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

במדריך זה נעבור על יסודות האימות הפשוט ושכבת האבטחה (SASL). נבין כיצד Java תומכת באימוץ SASL לאבטחת תקשורת.

בתהליך נשתמש בתקשורת פשוטה של ​​לקוחות ושרתים ונאבטח אותה באמצעות SASL.

2. מה זה SASL?

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

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

2.1. היכן SASL להשתלב?

ביישום, אנו עשויים להשתמש ב- SMTP כדי לשלוח דוא"ל ולהשתמש ב- LDAP כדי לגשת לשירותי ספריות. אך כל אחד מהפרוטוקולים הללו עשוי לתמוך במנגנון אימות אחר, כמו Digest-MD5 או Kerberos.

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

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

2.2. איך SASL עֲבוֹדָה?

עכשיו, כשראינו היכן SASL משתלב בתכנית האבטחה הכוללת, בואו נבין איך זה עובד.

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

זֶה החלפה יכולה להמשיך למספר איטרציות ולבסוף מסתיים כאשר השרת לא מציב אתגר נוסף.

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

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

3. תמיכה ב- SASL בג'אווה

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

3.1. ממשק API של Java SASL

ממשקי המפתח שיש לשים לב אליהם, כחלק מהחבילה "javax.security.sasl", הם SaslServer ו SaslClient.

SaslServer מייצג את המנגנון בצד השרת של SASL.

בואו נראה איך נוכל ליצור א SaslServer:

SaslServer ss = Sasl.createSaslServer (מנגנון, פרוטוקול, שם שרת, אביזרים, callbackHandler);

אנו משתמשים בכיתת המפעל סאסל להסית SaslServer. השיטה createSaslServer מקבל מספר פרמטרים:

  • מַנגָנוֹן - השם הרשום של IANA של מנגנון נתמך ב- SASL
  • נוהל - שם הפרוטוקול שעבורו מתבצע אימות
  • שם שרת - שם המארח המלא של השרת
  • אביזרים - קבוצה של מאפיינים המשמשים לתצורת חילופי האימות
  • callbackHandler - מטפל להתקשרות חוזרת שישמש את המנגנון שנבחר לקבלת מידע נוסף

מתוך האמור לעיל, רק השניים הראשונים הם חובה, והשאר בטלים.

SaslClient מייצג את מנגנון צד הלקוח של SASL. בואו נראה איך נוכל ליצור א SaslClient:

SaslClient sc = Sasl.createSaslClient (מנגנונים, authenticId, פרוטוקול, שרת שם, אביזרים, callbackHandler);

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

עם זאת, ישנם כמה הבדלים עדינים:

  • מנגנונים - הנה, זו רשימה של מנגנונים לנסות
  • הרשאה מזהה - זהו זיהוי תלוי פרוטוקול שישמש לאישור

שאר הפרמטרים דומים במשמעותם ובאופציונליות שלהם.

3.2. ספק אבטחת Java SASL

מתחת ל- API של Java SASL נמצאים המנגנונים האמיתיים המספקים את תכונות האבטחה. ה יישום מנגנונים אלה ניתן על ידי ספקי אבטחה רשום ב- Java Cryptography Architecture (JCA).

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

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

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

4. SASL באמצעות דוגמה

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

4.1. לקוח ושרת CallbackHandler

כפי שראינו קודם, עלינו לספק יישומים של CallbackHandler ל SaslServer ו SaslClient. עַכשָׁיו, CallbackHandler הוא ממשק פשוט המגדיר שיטה אחת - ידית. שיטה זו מקבלת מערך של התקשר חזרה.

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

בואו נראה איך נוכל להגדיר א CallbackHandler לשרת, מלכתחילה:

מחלקה ציבורית ServerCallbackHandler מיישמת CallbackHandler {@Override ידית חלל ציבורית (Callback [] cbs) זורקת IOException, UupportedCallbackException {עבור (Callback cb: cbs) {if (cb instanceof AuthorizeCallback) {AuthorizeCallback ac = (AuthorizeCallback) cb; // בצע פעולת אישור ספציפית ליישום ac.setAuthorized (true); } אחר אם (מופע cb של NameCallback) {NameCallback nc = (NameCallback) cb; // אסוף את שם המשתמש באופן ספציפי ליישום nc.setName ("שם משתמש"); } אחר אם (מופע cb של PasswordCallback) {PasswordCallback pc = (PasswordCallback) cb; // אסוף סיסמה באופן ספציפי ליישום pc.setPassword ("סיסמה" .toCharArray ()); } אחרת אם (cb מופע של RealmCallback) {RealmCallback rc = (RealmCallback) cb; // אוספים נתוני ממלכה באופן ספציפי ליישום rc.setText ("myServer"); }}}}

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

מחלקה ציבורית ClientCallbackHandler מיישם CallbackHandler {@Override ידית חלל ציבורית (Callback [] cbs) זורקת IOException, UnsupportedCallbackException {עבור (Callback cb: cbs) {if (cb instanceof NameCallback) {NameCallback nc = (NameCallback) cb; // אסוף את שם המשתמש באופן ספציפי ליישום nc.setName ("שם משתמש"); } אחרת אם (cb למשל של PasswordCallback) {PasswordCallback pc = (PasswordCallback) cb; // אסוף סיסמה באופן ספציפי ליישום pc.setPassword ("סיסמה" .toCharArray ()); } אחרת אם (cb מופע של RealmCallback) {RealmCallback rc = (RealmCallback) cb; // אסוף נתוני תחום באופן ספציפי ליישום rc.setText ("myServer"); }}}}

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

4.2. אימות SASL

אז כתבנו את הלקוח והשרת שלנו CallbackHandler. התווסף לנו SaslClient ו SaslServer למנגנון DIGEST-MD5.

זה הזמן לראות אותם בפעולה:

@ מבחן הריק פומבי שניתן Handlers_whenStarted_thenAutenticationWorks () זורק אתגר SaslException {byte []; תגובת בתים []; אתגר = saslServer.evaluateResponse (בית חדש [0]); תגובה = saslClient.evaluateChallenge (אתגר); אתגר = saslServer.evaluateResponse (תגובה); תגובה = saslClient.evaluateChallenge (אתגר); assertTrue (saslServer.isComplete ()); assertTrue (saslClient.isComplete ()); }

בואו ננסה להבין מה קורה כאן:

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

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

4.3. SASL תקשורת מאובטחת

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

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

מחרוזת qop = (מחרוזת) saslClient.getNegotiatedProperty (Sasl.QOP); assertEquals ("auth-conf", qop);

פה, QOP מייצג את איכות ההגנה. זה משהו שהלקוח והשרת מנהלים משא ומתן במהלך האימות. ערך של "auth-int" מציין אימות ושלמות. אמנם, ערך של "auth-conf" מעיד על אימות, שלמות וסודיות.

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

בואו נראה כיצד נוכל לאבטח תקשורת יוצאת אצל הלקוח:

בייט [] יוצא = "Baeldung" .getBytes (); בתים [] secureOutgoing = saslClient.wrap (יוצא, 0, יוצא. אורך); // שלח מאבטח יוצא לשרת דרך הרשת

ובאופן דומה, השרת יכול לעבד תקשורת נכנסת:

// קבל מאבטח נכנסות מהלקוח דרך בית הרשת [] נכנס = saslServer.unwrap (מאובטח נכנס, 0, netIn.length); assertEquals ("Baeldung", מחרוזת חדשה (נכנסת, StandardCharsets.UTF_8));

5. SASL בעולם האמיתי

אז עכשיו יש לנו הבנה הוגנת של מה זה SASL וכיצד להשתמש בו ב- Java. אבל, בדרך כלל, לא לשם כך נשתמש ב- SASL, לפחות בשגרה היומיומית שלנו.

כפי שראינו קודם, SASL מיועד בעיקר לפרוטוקולים כמו LDAP ו- SMTP. אם כי, יותר ויותר יישומים ומגיעים עם SASL - למשל, קפקא. אז איך נשתמש ב- SASL לאימות עם שירותים כאלה?

נניח שהגדרנו את Kafka Broker עבור SASL עם PLAIN כמנגנון הנבחר. PLAIN פשוט אומר שהוא מאמת באמצעות שילוב של שם משתמש וסיסמה בטקסט רגיל.

בואו נראה כעת כיצד נוכל להגדיר לקוח ג'אווה לשימוש ב- SASL / PLAIN לאימות מול מתווך קפקא.

ראשית אנו מספקים תצורת JAAS פשוטה, "kafka_jaas.conf":

KafkaClient {org.apache.kafka.common.security.plain.PlainLoginModule דרוש שם משתמש = "שם משתמש" סיסמה = "סיסמה"; };

אנו משתמשים בתצורת JAAS זו בעת הפעלת JVM:

-Djava.security.auth.login.config = kafka_jaas.conf

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

security.protocol = SASL_SSL sasl.mechanism = רגיל

זה כל מה שיש בזה. זה רק חלק קטן מתצורות הלקוח של קפקא. מלבד PLAIN, קפקא תומך גם ב- GSSAPI / Kerberos לצורך אימות.

6. SASL בהשוואה

למרות ש- SASL יעיל למדי במתן דרך נייטרלית לאימות ואבטחת תקשורת לקוחות ושרתים. למרות זאת, SASL אינו הפיתרון היחיד הקיים בעניין זה.

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

  • סיומת שקע Java מאובטח (JSSE): JSSE היא קבוצת חבילות בג'אווה המיישמת שכבת Secure Sockets Layer (SSL) עבור Java. הוא מספק הצפנת נתונים, אימות לקוח ושרת, ושלמות הודעות. בניגוד ל- SASL, JSSE מסתמכת על תשתית מפתח ציבורי (PKI) שתעבוד. לפיכך, SASL מסתדר כגמיש וקל משקל JSSE.
  • Java GSS API (JGSS): JGGS הוא מחייב שפת Java לממשק תכנות יישומי שירות אבטחה כללי (GSS-API). GSS-API הוא תקן IETF ליישומים לגשת לשירותי אבטחה. בג'אווה, תחת GSS-API, Kerberos הוא המנגנון היחיד הנתמך. Kerberos שוב דורשת תשתית Kerberised כדי לעבוד. בהשוואה ל- SASL, כאן עדיין, האפשרויות מוגבלות ומשקל כבד.

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

7. מסקנה

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

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

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

תחתית Java

רק הכרזתי על החדש למד אביב קורס, המתמקד ביסודות האביב 5 ומגף האביב 2:

>> בדוק את הקורס

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