Federation Services

תמלול ההרצאה: Federation Services

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

1. 00:06

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

2. 00:32

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

3. 00:42

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

4. 00:56

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

5. 01:22

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

6. 01:34

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

7. 01:46

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

8. 01:55

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

9. 02:19

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

10. 02:38

    לכל Trust ו-Trust נפתח פורט RPC, פורט LDAP TCP AP, זה הסוג שלו. לכל Trust ו-Trust פורט כזה נפתח. אפשר לראות פה דוגמא של חומות האש, שימו לב לחומת אש אידיאלית פה מצד ימין, שמיוצגת בסמן ירוק, אפשר ממש לראות אותה, שהפורטים המינימליים שפתוחים בה זה פורט 53 ל-DNS, פורט 25 ל-SMTP,

11. 03:02

    פורט 80 לתקשורת HTP, תקשורת אינטרנט רגילה ופורט 443 לתקשורת אינטרנט מאובטחת SSL. בעוד שמצד שמאל ניתן לראות חומת אש שבה הוגדר Trust.

12. 03:13

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

13. 03:29

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

14. 03:39

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

15. 04:00

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

16. 04:19

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

17. 04:32

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

18. 04:43

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

19. 05:00

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

20. 05:15

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

21. 05:31

    הרי מה היו הבעיות? פתחנו פורטים מיותרים? מאגר הנתונים הפנימי נחשף לחברות אחרות? קושי ניהולי? אז מה בעצם נבצע פה?

22. 05:41

    אנחנו נאפשר סוג של Trust מיוחד שנקרא "Federation Trust" ואנחנו נשתמש בפורטים שכבר פתוחים בחומת האש.

23. 05:48

    תשימו לב פה מצד שמאל למטה, חומת האש שיש עליה "Federation Trust" שימו לב, אותם פורטים דפולטים פתוחים, לא פתחנו שום פורט נוסף. למה?

24. 05:57

    כי ה-Trust שמוגדר על ידי פדרשן, על ידי שירות הפדרציה שנקרא פדרשן טראסט, עובד דרך HTTP. ויותר נכון להגיד HTTPS כי הכל מוצפן והכל מוגן.

25. 06:11

    אז תחשבו על זה Trust over HTTP. דבר מאוד מאוד מדליק. אתה לא פותח פורטים מיותרים בfirewall, יש לך פורט אחד לכל הפדרשן טראסט, וזה פורט שכבר by default פתוח.

26. 06:23

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

27. 06:44

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

28. 07:03

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

29. 07:15

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

30. 07:40

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

31. 07:55

    איך בעצם התעלמו מכל החסרונות האלה? כמו שאמרנו אין דבר כזה יש מאין אז באמת כל הקונספט פה מורכב מדבר שנקרא B2B Business to Business Partnership שותפות מעסק לעסק במקרה שלנו כמובן זה תחת ה-IDFS שני החלקים העיקריים שגורמים לכסף הזה להתרחש דבר מאוד יפה ומאוד פשוט Resource Organization ו-Account Organization

32. 08:20

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

33. 08:41

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

34. 08:58

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

35. 09:20

    עכשיו, כמו שאפשר לראות פה בתרשים, שימו לב, ארגון המשאבים, Resource Organization, Practically Comm, זה חברה בפני עצמה, היא Account Organization, זה אומר ארגון שמכיל חשבונות, חברה בפני עצמה, E-Docum הוא גם Account Organization,

36. 09:35

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

37. 09:51

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

38. 10:29

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

39. 10:53

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

40. 11:10

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

41. 11:29

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

42. 11:38

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

43. 11:58

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

44. 12:17

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

45. 12:31

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

46. 12:39

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

47. 13:00

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

48. 13:11

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

49. 13:39

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

50. 14:01

    Windows Token Best Agent עושה אותו דבר בדיוק אבל הוא נועד לאפליקציות ישנות לפעמים יש אפליקציות שהן לא יכולות לעבוד עם ה-Klyware Agents כי זה נועד לאפליקציות .NET האפליקציות הישנות האלה, מה שהן יכולות לעשות זה להסתמך על Windows Token Based Agent הוא בעצם עושה סוג של התחזות

51. 14:20

    ומביא את זה לאותן אפליקציות ברמה שהן יכולות להבין בדיוק מה הדרישה, מצד אין משתמש וכן הלאה זה נועד לאפליקציות ישנות, לא סביר שתיתקלו בזה אבל אם יש לכם אפליקציות ישנות אפשר להתקין את ה-Tat Roll הזה גם אז איך בעצם זה עובד?

52. 14:37

    בואו עכשיו, אחרי שדיברנו שיש לנו Account Organization, יש לנו Resource Organization שמכיל את המשאבים דיברנו שיש שרתי פרוקסי, אמרנו שיש איזה שרת ווב עם ה-climeware agent שלנו, שמכיל בעצם את היכולת לפענח מה המשתמש רוצה,