streamalism.org

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

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

במדריך זה נבין את ה- API של Generic Security Service (GSS API) וכיצד נוכל ליישם אותו ב- Java. נראה כיצד נוכל לאבטח תקשורת רשת באמצעות ה- API של GSS בג'אווה.

בתהליך ניצור רכיבי לקוח ושרת פשוטים, ונאבטח אותם באמצעות GSS API.

2. מה זה שב"כ API?

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

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

2.1. למה אנחנו צריכים שב"כ API?

מנגנוני אבטחה כמו Kerberos, NTLM ו- Digest-MD5 שונים לגמרי ביכולותיהם וביישומם. בדרך כלל, יישום התומך באחד ממנגנונים אלה מוצא די מרתיע לעבור לאחר.

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

2.2. איך שב"כ עבודת API?

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

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

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

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

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

Java תומכת ב- GSS API כחלק מהחבילה "org.ietf.jgss". שם החבילה עשוי להיראות מוזר. זה בגלל ש כריכות Java עבור GSS API מוגדרות במפרט IETF. המפרט עצמו אינו תלוי במנגנון האבטחה.

אחד ממנגנוני האבטחה הפופולריים של Java GSS הוא Kerberos v5.

3.1. ממשק API של Java GSS

בואו ננסה להבין כמה ממשקי ה- API העיקריים שבונים Java GSS:

• GSSContext מקפל את הקשר האבטחה של GSS API ומספק שירותים זמינים במסגרת ההקשר
• אישורי GSS עוטף את אישורי ה- API של GSS עבור ישות הדרושה בכדי לבסס את הקשר האבטחה
• GSSName מקפל את הישות העיקרית של ה- GSS API המספקת הפשטה עבור מרחב שמות שונה המשמש את המנגנונים הבסיסיים

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

• GSSManager משמש כמעמד המפעל עבור שיעורים חשובים אחרים של GSS API כמו GSSName, אישורי GSS, ו GSSContext
• אויד מייצג את מזהי האובייקטים האוניברסאליים (OID) שהם מזהים היררכיים המשמשים ב- GSS API לזיהוי מנגנונים ותבניות שם
• MessageProp עוטף מאפיינים כדי לציין GSSContext בדברים כמו איכות ההגנה (QoP) וסודיות להחלפת נתונים
• ChannelBinding מקפל את המידע המחייב של ערוץ אופציונלי המשמש לחיזוק האיכות בה ניתן אימות של ישות עמיתים

3.2. ספק אבטחת GSS של Java

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

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

יש ספק GSS המוגדר כברירת מחדל שנשלח עם JDK. עם זאת, ישנם ספקי GSS ספציפיים אחרים עם מנגנוני אבטחה בהם נוכל להשתמש. ספק אחד כזה הוא IBM Java GSS. עלינו לרשום ספק אבטחה כזה ב- JCA כדי שנוכל להשתמש בהם.

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

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

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

4.1. הקשר GSS ללקוח ולשרת

ראשית, נצטרך לכונן GSSContext, הן בשרת והן בצד הלקוח של הבקשה.

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

מנהל GSSManager = GSSManager.getInstance (); מחרוזת serverPrinciple = "HTTP / [מוגן בדוא"ל]"; GSSName serverName = manager.createName (serverPrinciple, null); Oid krb5Oid = Oid חדש ("1.2.840.113554.1.2.2"); GSSContext clientContext = manager.createContext (serverName, krb5Oid, (GSSCredential) null, GSSContext.DEFAULT_LIFETIME); clientContext.requestMutualAuth (נכון); clientContext.requestConf (נכון); clientContext.requestInteg (נכון);

יש כאן די הרבה דברים, בואו נפרק אותם:

• אנו מתחילים ביצירת מופע של ה- GSSManager
• ואז אנו משתמשים במופע זה כדי ליצור GSSContext, עובר לאורך:
  • א GSSName מייצג את מנהל השרת, הערה שם הראשי הספציפי של קרברוס פה
  • ה אויד של מנגנון השימוש, Kerberos v5 כאן
  • אישורי היוזם, ריק כאן פירושו שישמשו אישורי ברירת מחדל
  • את כל החיים עבור ההקשר הקבוע
• לבסוף, אנו מתכוננים ההקשר לאימות הדדי, סודיות ושלמות נתונים

באופן דומה עלינו להגדיר את ההקשר בצד השרת:

מנהל GSSManager = GSSManager.getInstance (); GSSContext serverContext = manager.createContext ((GSSCredential) null);

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

4.2. אימות API של GSS

למרות שיצרנו את השרת ואת צד הלקוח GSSContextשים לב שהם לא הוקמו בשלב זה.

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

// בצד הלקוח clientToken = clientContext.initSecContext (בית חדש [0], 0, 0); sendToServer (clientToken); // זה אמור להישלח דרך הרשת // בשרת Token בצד השרת = serverContext.acceptSecContext (clientToken, 0, clientToken.length); sendToClient (serverToken); // זה אמור להישלח דרך הרשת // חזרה בצד הלקוח clientContext.initSecContext (serverToken, 0, serverToken.length);

זה סוף סוף הופך את ההקשר לשני הקצוות:

assertTrue (serverContext.isEstablished ()); assertTrue (clientContext.isEstablished ());

4.3. תקשורת מאובטחת של GSS API

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

// בצד הלקוח בתים [] messageBytes = "Baeldung" .getBytes (); MessageProp clientProp = MessageProp חדש (0, נכון); בתא [] clientToken = clientContext.wrap (messageBytes, 0, messageBytes.length, clientProp); sendToClient (serverToken); // זה אמור להישלח דרך הרשת // בצד השרת MessageProp serverProp = MessageProp חדש (0, שקר); בתים [] בתים = serverContext.unwrap (clientToken, 0, clientToken.length, serverProp); מחרוזת מחרוזת = מחרוזת חדשה (בתים); assertEquals ("Baeldung", מחרוזת);

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

• MessageProp משמש הלקוח להגדרת ה- לַעֲטוֹף שיטה וליצור את האסימון
• השיטה לַעֲטוֹף מוסיף גם MIC קריפטוגרפי של הנתונים, ה- MIC מאוגד כחלק מהאסימון
• אסימון זה נשלח לשרת (אולי באמצעות שיחת רשת)
• השרת ממנף MessageProp שוב כדי להגדיר את לְגוֹלֵל שיטה ולקבל נתונים בחזרה
• כמו כן, השיטה לְגוֹלֵל מאמת את ה- MIC עבור הנתונים שהתקבלו, ומבטיח את שלמות הנתונים

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

4.4. הגדרת Kerberos לדוגמא

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

עם זאת, לדוגמא שלנו, לא נשתמש ישירות באימות מבוסס JAAS. נאפשר לקרברוס לקבל אישורים ישירות, במקרה שלנו באמצעות קובץ keytab. יש פרמטר מערכת JVM כדי להשיג זאת:

-Djavax.security.auth.useSubjectCredsOnly = false

עם זאת, ברירות המחדל של יישום Kerberos שמספקת Sun Microsystem מסתמכת על JAAS לספק אימות.

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

com.sun.security.jgss.initiate {com.sun.security.auth.module.Krb5LoginModule דרוש useKeyTab = true keyTab = example.keytab principal = "client / localhost" storeKey = true; }; com.sun.security.jgss.accept {com.sun.security.auth.module.Krb5LoginModule דרוש useKeyTab = true keyTab = example.keytab storeKey = true principal = "HTTP / localhost"; };

תצורה זו היא ישר קדימה, שם הגדרנו את Kerberos כמודול הכניסה הנדרש עבור היוזם וגם עבור המקבל. בנוסף, הגדרנו להשתמש במנהלים המתאימים מקובץ keytab. אנו יכולים להעביר את תצורת JAAS זו ל- JVM כפרמטר מערכת:

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

הנה, ההנחה היא שיש לנו גישה ל- KDC של Kerberos. ב- KDC הקמנו את המנהלים הנדרשים וקיבלנו את קובץ keytab לשימוש, נניח "Example.keytab".

בנוסף, אנו זקוקים לקובץ התצורה של Kerberos המפנה אל KDC הימני:

[libdefaults] default_realm = EXAMPLE.COM udp_preference_limit = 1 [realms] EXAMPLE.COM = {kdc = localhost: 52135}

תצורה פשוטה זו מגדירה KDC הפועל ביציאה 52135 עם תחום ברירת מחדל כ- EXAMPLE.COM. אנו יכולים להעביר את זה ל- JVM כפרמטר מערכת:

-Djava.security.krb5.conf = krb5.conf

4.5. הפעלת הדוגמא

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

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

java -Djava.security.krb5.conf = krb5.conf \ -Djavax.security.auth.useSubjectCredsOnly = false \ -Djava.security.auth.login.config = login.conf \ com.baeldung.jgss.JgssUnitTest

זה מספיק כדי ש- Kerberos יבצע את האימות עם אישורי keytab ו- GSS כדי לבסס את ההקשרים.

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

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

• שֶׁלָה נמצא בשימוש נרחב ב- SASL כמנגנון אבטחה, במיוחד כאשר קרברוס הוא מנגנון הבחירה הבסיסי. Kerberos הוא מנגנון אימות שנמצא בשימוש נרחב, במיוחד ברשת ארגונית. זה ממש שימושי למנף תשתית Kerberised כדי לאמת יישום חדש. לפיכך, ה- API של GSS מגשר יפה על הפער הזה.
• זה גם משמש בצמידות עם SPNEGO לנהל משא ומתן על מנגנון אבטחה כאשר אחד לא ידוע מראש. בהקשר זה, SPNEGO הוא מנגנון פסאודו של GSS API במובן מסוים. זה נתמך באופן נרחב בכל הדפדפנים המודרניים מה שהופך אותם מסוגלים למנף אימות מבוסס Kerberos.

6. API של GSS בהשוואה

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

בואו נבין מה עוד יש לג'אווה להציע וכיצד הם משווים מול GSS API:

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

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

7. מסקנה

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

יתר על כן, ראינו גם מה הם היישומים המעשיים של GSS API ומהן החלופות הקיימות ב- Java.

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

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