WEBVTT

00:00:00.000 --> 00:00:03.280
למעשה, רוב האנשים חושבים שזהות היא רק שם משתמש וסיסמה.

00:00:03.400 --> 00:00:09.260
אתה מקליד אותם, מקבל גישה וסיימת, אבל כשאתה עסק שנותן שירות ללקוחות, הזהות הופכת להרבה יותר מורכבת.

00:00:09.460 --> 00:00:15.600
מה קורה כשהאפליקציה שלך צריכה לאפשר לאלפי אנשים להירשם או להתחבר עם חשבון הגוגל שלהם במקום ליצור עוד סיסמה?

00:00:15.760 --> 00:00:20.180
ואיך אתה שומר על כל נתוני הלקוחות האלה מאובטחים בלי להרבב אותם עם ספריית העובדים שלך?

00:00:20.180 --> 00:00:23.780
זו בדיוק הבעיה שמיקרוסופט אינטרה אקסטרנל איי די נבנה כדי לפתור.

00:00:23.900 --> 00:00:27.160
הנה העניין, הוא מחליף את Azure DB2C לחלוטין.

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

00:00:35.080 --> 00:00:37.500
הדרך הישנה, מאגרי זהויות נפרדים.

00:00:37.680 --> 00:00:41.260
תארו לעצמכם שזה היה לפני 20 שנה ובניתם אפליקציה ללקוחות.

00:00:41.260 --> 00:00:48.800
אז, הייתם מפתחים מערכת התחברות משלכם, כותבים קוד לסיסמאות, מקימים מסעד נתונים להיחסון, ובונים תהליך שככתי סיסמה, הכל מאפס.

00:00:48.980 --> 00:00:54.180
זה עבד מצוין לאפליקציה קטנה עם כמה מאות משתמשים, אבל ככל שהאפליקציות גדלו, העניינים הסתבכו מהר מאוד.

00:00:54.340 --> 00:01:01.260
חברות היו צריכות לאפשר למשתמשים להתחבר עם גוגל או פייסבוק, הן היו צריכות אימות רב שלבי, והיו צריכות לנהל מיליוני חשבונות בלי שהכל יקרוס.

00:01:01.260 --> 00:01:03.720
לבנות את כל זה בעצמך, זה הפך לסיוט.

00:01:03.860 --> 00:01:06.860
התשובה הראשונה של מייקרוסופט הייתה Azure ADB2C.

00:01:07.060 --> 00:01:10.300
זה היה שירות זהות ללקוחות, ובזמנו הוא פתר בעיה אמיתית.

00:01:10.440 --> 00:01:11.760
אבל כאן התחילו הבעיות.

00:01:11.920 --> 00:01:17.000
הבעיה הכי גדולה הייתה משהו שנקרא מדיניות מותאמת אישית, Custom Policies, והמדיניות הזו נכתבה ב-XML.

00:01:17.180 --> 00:01:21.880
אם עבדתם אי פעם עם קבצי XML שנפרסים על מאות שורות, אתם יודעים בדיוק כמה זה כואב.

00:01:21.880 --> 00:01:26.140
קשה להגדרה, קשה לניפוי שגיאות, וכשמה שהוא נשבר, בהצלחה להבין למה.

00:01:26.220 --> 00:01:30.460
מעבר לזה, Azure ADB2C היה נפרד מפלטפורמת הזהות הראשית של מייקרוסופט.

00:01:30.580 --> 00:01:35.160
אז, אם כבר היה לכם Microsoft 365 או Azure AD עבור העובדים שלכם,

00:01:35.360 --> 00:01:37.660
B2C הרגיש כמו ללמוד מוצר חדש לגמרי.

00:01:37.840 --> 00:01:42.020
כפי שניתן לצפות, צוותי העית התקשו לתחזק אותו, מפתחים חששו לעבוד איתו,

00:01:42.220 --> 00:01:45.580
והלקוחות קיבלו חוויית הרשמה מסורבלת שגרמה להם לרצות לעזוב.

00:01:45.580 --> 00:01:48.560
מייקרוסופט הבינה שהם צריכים משהו פשוט ומאוחד יותר,

00:01:48.800 --> 00:01:51.460
וזה בדיוק מה שהפך ל-Microsoft Entra External ID.

00:01:51.640 --> 00:01:54.120
מה זה בעצם Microsoft Entra External ID?

00:01:54.280 --> 00:01:56.960
אז, מה זה בדיוק Microsoft Entra External ID?

00:01:57.120 --> 00:01:58.680
הנה ההגדרה הפשוטה ביותר.

00:01:58.840 --> 00:02:03.340
זהו שירות זהות בענן עבור משתמשים חיצוניים, לקוחות, שותפים ואורחים, לא עבור עובדים.

00:02:03.460 --> 00:02:04.500
תחשבו על זה ככה.

00:02:04.600 --> 00:02:06.500
דמיינו של החברה שלכם יש בניין משרדים.

00:02:06.660 --> 00:02:08.240
זהו הטננט של כוח העבודה שלכם.

00:02:08.240 --> 00:02:10.420
זה המקום שבו העובדים שלכם עובדים איפה שהשולחנות שלהם,

00:02:10.480 --> 00:02:11.880
ואיפה שהתגים שלהם מאפשרים להם להיכנס.

00:02:12.000 --> 00:02:13.640
Entra ID מנהל את הבניין הזה.

00:02:13.800 --> 00:02:16.240
עכשיו, תארו לעצמכם שאתם פותחים חנות ללקוחות,

00:02:16.360 --> 00:02:19.380
מרחב נפרד, עם כניסה משלו, חוקים משלו, והבטחה משלו.

00:02:19.540 --> 00:02:21.940
לקוחות לא משוטטים בחדר ההפסקה של העובדים,

00:02:22.140 --> 00:02:24.360
ועובדים לא ניגשים בטעות לחשבונות של לקוחות.

00:02:24.500 --> 00:02:25.580
זהו External ID.

00:02:25.820 --> 00:02:29.000
זהו חלק ממשפחת Microsoft Entra, אבל בגרסה שונה.

00:02:29.000 --> 00:02:32.660
הוא נבנה עבור CIEM, ניהול זהויות וגישה של לקוחות,

00:02:32.880 --> 00:02:35.280
והוא מטפל בכל מחזור החיים של משתמש חיצוני.

00:02:35.400 --> 00:02:39.820
הרשמה, התחברות, איפוס סיסמה, ניהול פרופיל, MFA, והנפקת הסימונים.

00:02:40.000 --> 00:02:43.940
הוא עובד עם פרוטוקולים סטנדרטיים כמו OOF 2.0, Open ID Connect ו-SML,

00:02:44.200 --> 00:02:45.980
כך שכמעט כל אפליקציה שתבנו תוכל להתחבר.

00:02:46.120 --> 00:02:48.780
אבל, הנה ההבדל הגדול מ-Azure ADB2C הישן.

00:02:48.920 --> 00:02:50.360
External ID הוא פשוט יותר.

00:02:50.540 --> 00:02:52.480
אין יותר מדיניות XML מותאמת אישית.

00:02:52.480 --> 00:02:55.520
במקום זאת, אתם מגדירים תהליכי משתמש ישירות במרכז הניהול.

00:02:55.620 --> 00:02:57.560
או שאתם משתמשים בתוספי עימות מותאמים אישית,

00:02:57.620 --> 00:02:59.760
שמתחברים ללוגיקת Hey Backend הקיימת שלכם.

00:02:59.880 --> 00:03:01.520
אותה עוצמה, פחות כאב ראש.

00:03:01.720 --> 00:03:03.340
שלושת מקרי השימוש העיקריים.

00:03:03.520 --> 00:03:05.460
אז איך בעצם משתמשים באקטרנל ID?

00:03:05.660 --> 00:03:07.280
ישנם שלושה תרחישים עיקריים.

00:03:07.460 --> 00:03:10.920
הם מכסים כמעט כל מצב שבו צריך לנהל מישהו שאינו עובד.

00:03:11.040 --> 00:03:14.200
נתחיל בנפוץ ביותר, זהות לקוח, או B2C.

00:03:14.200 --> 00:03:17.100
תארו לעצמכם שאתם בונים אפליקציה להזמנת פיצה.

00:03:17.160 --> 00:03:20.560
אתם צריכים שאנשים ירשמו, יבצעו הזמנות ויחזרו בשבוע הבא.

00:03:20.660 --> 00:03:23.960
אתם רוצים שהם יתחברו עם חשבון הגוגל שלהם במקום ליצור סיסמה נוספת,

00:03:24.100 --> 00:03:27.180
ואתם צריכים לאסוף את השם, מספר הטלפון והעדפות המשלוח שלהם.

00:03:27.340 --> 00:03:28.960
אקסטרנל ID מטפל בכל זה.

00:03:29.120 --> 00:03:31.700
אתם מקבלים תהליכי הרשמה והתחברות מובנים מראש.

00:03:31.860 --> 00:03:35.960
אתם מגדירים אילו מאפיינים לאסוף, שם, טלפון, או כל מה שתצטרכו.

00:03:35.960 --> 00:03:39.520
אתם מגדירים התחברות חברתית עם גוגל, פייסבוק או אפל.

00:03:39.700 --> 00:03:45.620
וכאשר משתמש מאומת, אקסטרנל ID מנפיק הסימון לאפליקציה שלכם כדי שהיא תדע מהאדם הזה.

00:03:45.840 --> 00:03:50.040
זהו התחליף לאזר אדי בי 2C, וזה המקום שבו רוב הארגונים מתחילים.

00:03:50.180 --> 00:03:53.340
תרחיש נוסף הוא שיתוף פעולה בין עסקים, או בי 2B.

00:03:53.520 --> 00:03:57.840
זה המצב שבו אתם צריכים לתת לשותפים או ספקים גישה לאפליקציות הפנימיות שלכם.

00:03:57.840 --> 00:04:01.820
אולי יש לכם אתר SharePoint ששותף הלוגיסטיקה החיצוני שלכם צריך לראות,

00:04:02.040 --> 00:04:04.880
או כלי לניהול פרויקטים שהמעצבים העצמאיים שלכם משתמשים בו.

00:04:05.000 --> 00:04:09.160
בתרחיש זה, אתם מזמינים אותם כמשתמשים עורכים בדייר, טננט, העובדים שלכם.

00:04:09.320 --> 00:04:13.920
אקסטרנל ID מטפל בדואר אלקטרוני ההזמנה, בתהליך המימוש שבו הם מקבלים את ההזמנה,

00:04:14.120 --> 00:04:16.440
ובמדיניות הגישה ששולטת במה שהם יכולים לראות.

00:04:16.580 --> 00:04:20.620
זה למעשה קיים כבר שנים כשיתוף פעולה בי 2B בתוך Azure AD,

00:04:20.620 --> 00:04:22.620
אך כעת זה חלק מטריאת האקסטרנל ID,

00:04:22.860 --> 00:04:25.840
כך שאתה מנהל את זה מאותו המקום שבו אתה מנהל את זהויות הלקוחות שלך.

00:04:25.960 --> 00:04:28.480
אחר כך ישנו Hey Machine to Machine או M2M.

00:04:28.660 --> 00:04:31.320
זה פחות גלוי למשתמשי קצה, אך חשוב באותה מידה.

00:04:31.460 --> 00:04:34.720
לפעמים שירות Hey Backend שלך צריך לתקשר עם API אחר,

00:04:34.940 --> 00:04:37.780
מאבד תשלומים, שירות ניתוח נתונים או מיקרו שירות פנימי.

00:04:37.900 --> 00:04:40.980
אין מעורבות של אדם, זו רק אפליקציה אחת שקורית לאחרת.

00:04:40.980 --> 00:04:45.180
אקסטרנל ID משתמש בתהליך ה-off 2.0 Client Credentials.

00:04:45.240 --> 00:04:48.220
השירות שלך מבצע אימות עצמי באמצעות מזהה לקוח וסוד,

00:04:48.420 --> 00:04:50.740
ומקבל הסימון כדי לקרוא לאפי-איי במורד הזרם.

00:04:50.920 --> 00:04:54.100
זה דורש את התוסף M2M Premium, כך שיש כאן מרכיב עלות,

00:04:54.320 --> 00:04:57.560
אך אם עליך להבטח תקשורת בין API לאפי-איי, זה מובנה בפנים.

00:04:57.760 --> 00:05:02.280
כעת, שלושת התרחישים האלו מכסים כמעט כל מצב של זהות חיצונית שתתכל בו,

00:05:02.280 --> 00:05:06.080
אך יש החלטה גדולה שעליך לקבל, וזה היכן המשתמשים האלו באמת חיים.

00:05:06.240 --> 00:05:09.320
מכיוון ש-אקסטרנל ID יכול לרוץ בשני מקומות שונים מאוד,

00:05:09.580 --> 00:05:11.060
דייר כוח עבודה מול דייר חיצוני.

00:05:11.220 --> 00:05:12.720
בוא נפרק את שתי האפשרויות.

00:05:12.900 --> 00:05:15.560
אקסטרנל ID יכול לרוץ בתוך דייר כוח העבודה הקיים שלך,

00:05:15.720 --> 00:05:17.580
או שהוא יכול לרוץ כדייר חיצוני נפרד לחלוטין.

00:05:17.580 --> 00:05:21.020
הם לא אותו הדבר, ובחירה לא נכונה עלולה לגרום לי בעיות בהמשך הדרך.

00:05:21.160 --> 00:05:23.100
נתחיל באפשרות של דייר כוח העבודה.

00:05:23.100 --> 00:05:26.160
לחברה שלך כבר יש דייר Entra ID עבור העובדים שלך.

00:05:26.320 --> 00:05:27.860
זהו דייר כוח העבודה שלך.

00:05:28.000 --> 00:05:31.200
אם תפעיל תכונה שנקראת הרשמה בשירות עצמי לאורחים בתוך הדייר הזה,

00:05:31.440 --> 00:05:34.660
משתמשים חיצוניים יוכלו להירשם ולהגיע לאותה ספרייה כמו העובדים שלך.

00:05:34.800 --> 00:05:37.760
החשבונות שלהם יושבים ממש ליד החשבון של המנכל שלך.

00:05:37.760 --> 00:05:41.800
עבור תרחישי B2B פשוטים יותר, כמו הזמנת קומץ שותפים לאתר SharePoint,

00:05:42.020 --> 00:05:44.020
ערבוב שלהם באותה ספרייה זה בסדר גמור.

00:05:44.180 --> 00:05:46.920
זה פשוט להגדרה, ואתה לא צריך לנהל דייר נפרד.

00:05:47.060 --> 00:05:48.220
אבל, הנה העניין.

00:05:48.380 --> 00:05:50.880
אם אתה בונה אפליקציה מול לקוחות עם אלפי משתמשים,

00:05:51.080 --> 00:05:54.320
אתה לא רוצה שהלקוחות האלו יחיו באותה ספרייה כמו העובדים שלך.

00:05:54.500 --> 00:05:55.480
זה סיכון הבטחה.

00:05:55.620 --> 00:05:57.960
עובד עלול בטעות להתעכל בנתוני לקוחות.

00:05:57.960 --> 00:06:01.500
שינוי הגדרה המיועד לעובדים עלול להשפיע על גישת הלקוחות.

00:06:01.620 --> 00:06:05.860
והמיתוג שלך לדפי כניסת לקוחות יהיה קשור לכל מה שהגדרת עבור החברה שלך.

00:06:06.040 --> 00:06:06.780
זה לא אידיאלי.

00:06:06.780 --> 00:06:08.820
החלופה היא אפשרות הדייר החיצוני.

00:06:09.000 --> 00:06:12.600
אתה יוצר ספרייה מבודדת וחדשה לגמרי במיוחד עבור זהויות לקוחות.

00:06:12.680 --> 00:06:13.700
אף עובד לא חי כאן.

00:06:13.900 --> 00:06:15.260
זהו מרחב נפרד לחלוטין.

00:06:15.460 --> 00:06:17.420
זוכרת אנלוגיית בניין המשרדי מקודם.

00:06:17.540 --> 00:06:19.540
דייר כוח העבודה הוא מתי החברה שלך.

00:06:19.540 --> 00:06:23.180
הדייר החיצוני הוא חנות התצוגה היהודית שאתה פותח עבור הלקוחות שלך.

00:06:23.300 --> 00:06:26.680
יש להם כניסה משלהם, חוקים משלהם, והבטחה משלהם.

00:06:26.800 --> 00:06:27.980
שום דבר לא מתערבב.

00:06:27.980 --> 00:06:30.140
אז, מהם היתרונות של דייר חיצוני?

00:06:30.280 --> 00:06:32.680
ראשית, אתם מקבלים מאגר משתמשים מבודד.

00:06:32.860 --> 00:06:35.600
נתוני לקוחות נשארים מופרדים לחלוטין מנתוני עובדים,

00:06:35.840 --> 00:06:37.720
מה שמפחיד סיכונים ומפשט את הציוט.

00:06:37.840 --> 00:06:39.660
שנית, אתם מקבלים מיתוג נפרד.

00:06:39.660 --> 00:06:43.780
ניתן להתאים אישית את המראה והתחושה של דפי ההתחברות עבור הלקוחות שלכם,

00:06:43.960 --> 00:06:45.360
מבלי להשפיע על דייר הארגון.

00:06:45.480 --> 00:06:48.520
שלישית, אתם מקבלים API אימות מקורי לאפליקציות מובייל,

00:06:48.520 --> 00:06:52.160
המאפשר בניית משקי כניסה מותאמים אישית באפליקציות iOS או Android,

00:06:52.320 --> 00:06:55.000
ללא הפניות דפדפן, ללא תצוגות אינטרנט מסורבלות.

00:06:55.120 --> 00:06:57.280
ורביעית, אתם מקבלים תמחור מבוסס מהו,

00:06:57.420 --> 00:06:58.500
משתמשים פעילים חודשיים.

00:06:58.500 --> 00:07:01.400
משלמים רק על משתמשים שביצעו אימות בפועל בחודש נתון,

00:07:01.620 --> 00:07:04.200
מה שמתרחב באופן טבעי עם צמיחת הלקוחות שלכם.

00:07:04.300 --> 00:07:05.520
אז מתי בוחרים במה?

00:07:05.680 --> 00:07:06.440
זה די פשוט.

00:07:06.600 --> 00:07:09.060
אם אתם בונים אפליקציית B2C עם אלפי לקוחות,

00:07:09.260 --> 00:07:10.940
לכו על דייר חיצוני External Tenant.

00:07:11.140 --> 00:07:14.060
זו הגישה המומלצת ועבורה תוכנן External ID.

00:07:14.240 --> 00:07:17.100
אם אתם רק מזמינים שותפים לגשת למשאבים פנימיים,

00:07:17.400 --> 00:07:19.080
אפשרות דייר כוח האדם מספיקה.

00:07:19.080 --> 00:07:22.040
המפתח הוא להבין את ההבדל לפני שמתחילים לבנות,

00:07:22.280 --> 00:07:24.840
כי מעבר מאחד לשני בהמשך אינות ראיאלי.

00:07:25.340 --> 00:07:27.580
אבטחה, MFA וגישה מותנית.

00:07:27.700 --> 00:07:29.420
עכשיו, בואו נדבר על אבטחה.

00:07:29.540 --> 00:07:32.240
אם אתם מתכוונים לאפשר ללקוחות להיכנס לאפליקציה שלכם,

00:07:32.440 --> 00:07:34.420
עליכם לוודא שהאנשים הלא נכונים לא ייכנסו.

00:07:34.420 --> 00:07:39.520
External ID כולל את אותה מאפייני הבטחה ברמה ארגונית ש-Entra ID מציע לעובדים.

00:07:39.700 --> 00:07:43.520
זה אומר עימות רב שלבי, גישה מותנית ומדיניות מבוססת סיכונים.

00:07:43.520 --> 00:07:46.240
עבור MFA יש לכם כרגע שתי אפשרויות.

00:07:46.440 --> 00:07:48.380
קוד גישה חד פעמי במייל הוא בחינם.

00:07:48.540 --> 00:07:51.720
המערכת שולחת קוד למייל של המשתמש ומקליד אותו, וזהו.

00:07:51.840 --> 00:07:54.040
קוד גישה חד פעמי ב-SMS עובד באותו אופן,

00:07:54.200 --> 00:07:56.220
אך נשלח לטלפון שלהם ויש עלויות מפעיל.

00:07:56.360 --> 00:07:59.280
נקודה חשובה, אין עדיין תמיכה ב-Microsoft Authenticator.

00:07:59.480 --> 00:08:02.480
זו מגבלה נוכחית, וזה משהו שמייקרוסופט כנראה עובדת עליו.

00:08:02.640 --> 00:08:04.240
אבל כרגע, זה אימייל או SMS.

00:08:04.620 --> 00:08:07.200
גישה מותנית היא המקום שבו דברים הופכים למעניינים.

00:08:07.200 --> 00:08:12.120
ניתן להגדיר חוקים כמו דרישת MFA כאשר רמת סיכון ההתחברות בינונית ומעלה,

00:08:12.380 --> 00:08:14.680
או חסימת גישה ממדינות שאיננו פועלים בהן.

00:08:14.820 --> 00:08:17.920
המערכת מעריכה כל ניסיון התחברות בזמן אמת.

00:08:17.920 --> 00:08:21.440
אם מי שהוא מנסה להתחבר ממיקום או מכשיר שנראים חשודים,

00:08:21.660 --> 00:08:26.560
היא יכולה להעלות אוטומטית את דרישות ההבטחה ללא צורך שתבנו את הלוגיקה הזו בעצמכם.

00:08:26.560 --> 00:08:30.400
אבל יש פיצ'ר אחד שבולט במיוחד, אימות מדורג, Step Up Authentication.

00:08:30.580 --> 00:08:31.480
הנה איך זה עובד.

00:08:31.640 --> 00:08:35.680
דמיינו שמשתמש נכנס לאפליקציה שלכם רק עם סיסמה כדי לעיין בכתלוג המוצרים.

00:08:35.880 --> 00:08:37.520
זה בסדר לפעילויות בסיכון נמוך.

00:08:37.740 --> 00:08:41.860
אבל כשהם מנסים לצפות בהיסטוריית התשלומים או להוריד חשבונית, תרצו אימות נוסף.

00:08:41.860 --> 00:08:46.740
באמצעות אימות מדורג, Step Up, ניתן לדרוש אימות רב-גורמי, MFA, רק עבור חלקים ספציפיים באפליקציה.

00:08:46.860 --> 00:08:49.760
המשתמש לא יתבקש להזדהות עד שינסה לגשת למידע רגיש.

00:08:49.760 --> 00:08:55.180
הכל מנוהל מאחורי הקלעים על ידי External ID באמצעות רכיב שנקרא הקשר אימות Authentication Context.

00:08:55.320 --> 00:08:59.900
אתם מגדירים אילו חלקים באפליקציה דורשים אבטחה נוספת, והמערכת מטפלת בכל השאר.

00:08:59.900 --> 00:09:04.540
המשתמש נהנה מחוויה חלקה בגלישה בסיסית, אך המידע הרגיש נשאר מוגן.

00:09:04.940 --> 00:09:06.380
מיתוג וחוויית משתמש

00:09:06.380 --> 00:09:12.600
שליטה במיתוג היא אחת הסיבות העיקריות לכך שארגונים בוחרים באקסטרנל ID במקום לבנות מערכת התחברות משלהם.

00:09:12.720 --> 00:09:15.900
אתם מקבלים שליטה מלאה על המראה והתחושה של דפי ההרשמה וההתחברות,

00:09:16.580 --> 00:09:20.000
העלאת לוגו, הגדרת צבעי רקע, הוספת אייקון לחרטיסיית הדפדפן,

00:09:20.240 --> 00:09:23.640
והתאמת הכותרת והתחתית עם קישורים למדיניות הפרטיות ותנאי השירות.

00:09:23.640 --> 00:09:28.860
אם תרצו שליטה רבה יותר, תוכלו להעלות קובץ CSS מותאם אישית כדי לשנות גופנים, צבעי כפתורים ופריסה.

00:09:28.980 --> 00:09:31.840
זה המותג שלכם, הצבעים שלכם, הכל לפי החלטתכם.

00:09:31.940 --> 00:09:33.560
כאן העניינים נהיים מעט מורכבים.

00:09:33.720 --> 00:09:36.680
המיתוג הוא גלובלי לכל דייר, טננט, ולא לכל אפליקציה בנפרד.

00:09:36.800 --> 00:09:41.760
לכן, אם יש לכם מספר אפליקציות, למשל פורטל לקוחות ואפליקציית מובייל, כולן יחלקו את אותם דפים ממותגים.

00:09:41.760 --> 00:09:44.120
לא ניתן להעניק לכל אפליקציה מראה ייחודי משלה.

00:09:44.240 --> 00:09:49.380
ב-Azure AD B2C הישן ניתן היה לבצע מיתוג לכל אפליקציה, אך External ID עדיין לא תומך בכך.

00:09:49.520 --> 00:09:52.900
מגבלה נוספת היא שלא ניתן להתאים אישית הודעות שגיאה בדפי ההתחברות.

00:09:53.060 --> 00:09:57.980
אם מי שהוא יקליד כתובת אימייל לא קיימת, הוא יראה הודעה כמו, לא הצלחנו למצוא חשבון עם כתובת אימייל זו.

00:09:58.080 --> 00:09:59.720
ואת הטקסט הזה לא ניתן לשנות.

00:09:59.720 --> 00:10:06.160
עבור חלק מהארגונים זה בסדר, אך עבור אחרים, במיוחד בתעשיות מוסדרות או עם שפת מותג קפדנית, זו בעיה אמיתית.

00:10:06.160 --> 00:10:08.220
אפליקציות מובייל מקבלות אפשרות טובה יותר.

00:10:08.420 --> 00:10:12.260
לאקסטרנל ID יש ממשק API לאימות מקורי, ניטיב עבור iOS ואנדרואיד.

00:10:12.400 --> 00:10:17.720
במקום להפנות משתמשים לדף התחברות מבוסס דפדפן, ניתן לבנות מסקי התחברות מותאמים אישית בתוך האפליקציה.

00:10:17.840 --> 00:10:20.320
ללא הפניות לדפדפן, ללא דפי אינטרנט מסורבלים.

00:10:20.320 --> 00:10:24.040
המשתמש נשאר באפליקציה שלכם לאורך כל התהליך, ואתם שולטים בכל פיקסל.

00:10:24.040 --> 00:10:28.720
זו חוויה הרבה יותר חלקה, וזה אחד הפיאטשרים שמעולם לא היו קיימים ב-Azure AD B2C.

00:10:28.880 --> 00:10:30.760
הגירה מ-Azure AD B2C

00:10:30.760 --> 00:10:34.860
אם אתם כבר משתמשים ב-Azure AD B2C, בטח תהיתם מה זה אומר עבורכם.

00:10:35.000 --> 00:10:38.820
הנה העניין, מייקרוסופט תמשיך לתמוך ב-B2C לפחות עד שנת 2030.

00:10:39.160 --> 00:10:43.120
לכן, הדיירים הקיימים שלכם לא יפסיקו לעבוד מחר, אך תכונות חדשות לא התווספו.

00:10:43.120 --> 00:10:48.200
כל החדשנות מפתחות גישה, פסקיז, אימות מקורי, הגנה מפני הונאות בלעדית, לאקסטרנל ID.

00:10:48.400 --> 00:10:50.740
אתם נמצאים על פלטפורמה שלמעשה קפואה בזמן.

00:10:50.920 --> 00:10:55.740
מייקרוסופט פרסמה כלי הגירה והנחיות רשמיים, וישנם שני מסלולים בהתאם להיקף הפעילות שלכם.

00:10:55.880 --> 00:11:03.120
עבור דיירים, טנאנטס, עם פחות מ-5 מיליון אובייקטי ספרייה, משתמשים, קבוצות ומאפיינים מותאמים אישית, ההגירה הסטנדרטית היא פשוטה יחסית.

00:11:03.120 --> 00:11:05.020
זה עובד כמו העברה בין דיירים.

00:11:05.200 --> 00:11:11.120
יוצרים דייר אקסטרנל ID חדש, מעבירים את המשתמשים ואת אישורי הגישה שלהם, ואז מעבירים את היישומים.

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

00:11:18.760 --> 00:11:24.080
עבור דיירים גדולים יותר עם מעל 5 מיליון אובייקטי ספרייה, קיים מצב תאימות בהיקף גבוה, או HSC.

00:11:24.080 --> 00:11:29.060
במצב זה, Azure AD B2C ו-External ID פועלים זה לצד זה באותו הדייר.

00:11:29.200 --> 00:11:34.200
נקודות הקצה הקיימות של B2C נשארות פעילות בזמן שאתם מעבירים את היישומים בהדרגה.

00:11:34.360 --> 00:11:39.040
זה מיועד לארגונים שלא יכולים להעביר מיליוני משתמשים בין לילה, אך זה מגיע עם פשרות.

00:11:39.100 --> 00:11:44.540
ללא ספקי זהות חברתיים, ללא מפתחות גישה, פסקיז, גישה מותנית מוגבלת וחלק מהתכונות פשוט אינן זמינות.

00:11:44.620 --> 00:11:47.080
תחשבו על זה כאסטרטגיית גישור, לא כפתרון קבוע.

00:11:47.080 --> 00:11:50.840
עכשיו, שינוי משמעותי. מדיניות מותאמת אישית, Custom Policies, אינה קיימת יותר.

00:11:50.980 --> 00:11:57.080
אם בניתם תהליכי אימות מורכבים באמצעות מסגרת ניהול הזהויות מבוססת ה-XML של Azure AD B2C, הם לא יעבדו באקסטרנל ID.

00:11:57.240 --> 00:12:01.440
תצטרכו לבנות מחדש את הלוגיקה הזו באמצעות זרימות משתמש והרחבות אימות מותאמות אישית.

00:12:01.540 --> 00:12:06.040
אין כלי קסם שממיר את ה-XML שלכם לפורמט החדש. פשוט תצטרכו לעשות את העבודה.

00:12:06.200 --> 00:12:07.560
אז, הנה השורה התחתונה.

00:12:07.560 --> 00:12:12.140
אם אתם מתחילים היום מ-0, השתמשו באקסטרנל ID. אין סיבה אפילו להסתכל על B2C.

00:12:12.280 --> 00:12:15.680
אם יש לכם דייר B2C קיים, התחילו לתכנן את ההגירה שלכם עכשיו.

00:12:15.860 --> 00:12:22.640
יש לכם זמן עד 2030, אבל המתנה לדקה ה-90 אומרת שתמהרו לבצע הגירה מורכבת תוך ניסיון לשמור על האפליקציות הקיימות פועלות.

00:12:22.720 --> 00:12:28.120
התחילו בקטן, בחרו יישום אחד, העבירו אותו, בדקו אותו, לימדו מהתהליך, ואז עשו את השאר.

00:12:28.240 --> 00:12:29.920
חוויית מפתח ואוטומציה.

00:12:29.920 --> 00:12:36.800
מייקרוסופט באמת התמקדה בהפיכת אקסטרנל ID לקל עם מפתחים, וזה שינוי עצום מהמדיניות המותאמת האישית של B2C הישן.

00:12:36.960 --> 00:12:41.540
אתם מכירים את קבצי ה-XML האלה שנמתחו על פני מאות שורות ונשברו אם שכחתם סוגריים אחד?

00:12:41.700 --> 00:12:46.320
זה נעלם. יש הרחבה ל-Visual Studio Code בשם Microsoft Entra External ID.

00:12:46.500 --> 00:12:54.060
לאחר האימות, תוכלו לסייר בדייר שלכם, לצפות מזרימות משתמש, להוריד אותן כקבצי JSON, ואפילו להציג תצוגה המקדימה של המיתוג, הכל מבלי לעזוב את האורך.

00:12:59.920 --> 00:13:05.160
כמעט כל משיו ב-External ID, זרימות משתמש, רישומי אפליקציות ומיתוג ניתנים לניהול תכנותי.

00:13:05.300 --> 00:13:10.440
זה אומר שניתן לבצע אוטומציה להגדרת הדייר בצינורות ה-C, CD שלכם באמצעות PowerShell או קריאות REST.

00:13:10.620 --> 00:13:15.560
צרו דייר חדש, הגדירו זרימות משתמשים, רשמו את האפליקציה וקבו מיתוג, הכל מתוך סקריפט.

00:13:15.560 --> 00:13:18.440
אם אתם מנהלים סביבות מרובות, זה חוסך המון זמן.

00:13:18.600 --> 00:13:21.560
תוספי אימות מותאמים אישית הם המקום שבו נמצא הכוח האמיתי.

00:13:21.700 --> 00:13:26.420
במקום XML מורכב, אתם מרחיבים את זרימות האימות עם קריאות HTTP פשוטות ל-Azure Functions.

00:13:26.580 --> 00:13:28.740
ישנם ארבעה אירועים שאפשר להתחבר עליהם.

00:13:28.900 --> 00:13:34.140
התחלת הנפקת אסימון מאפשרת להוסיף תביעות מותאמות אישית להסימונים, כמו תפקידים או פרטי דרגת נאמנות.

00:13:34.140 --> 00:13:39.800
התחלת ושליחת איסוף מאפיינים מאפשרות לאמת או למלא מראש נתוני הרשמה על ידי קריאה לבקאנד שלכם.

00:13:39.940 --> 00:13:43.440
ואימייל OTP שנשלח מאפשר לכם להתאים אישית את הודעות האימות.

00:13:43.440 --> 00:13:47.200
זו אותה דמישות שהייתה ב-B2C, אבל במודל שכל מפתח יכול לעבוד איתו.

00:13:47.320 --> 00:13:48.740
יש מגבלות שצריך להכיר.

00:13:48.900 --> 00:13:54.060
עדיין אין התראות Microsoft Graph, לכן אי אפשר להפעיל אוטומטית זרימת עבודה כשמשתמש חדש נרשם.

00:13:54.060 --> 00:13:58.820
חלק מההגדרות עדיין דורשות ביצוע ידני במרכז הניהול, ואין דף עריכת פרופיל מובנה.

00:13:58.900 --> 00:14:04.340
אם אתם רוצים שמשתמשים יעדכנו את המידע שלהם, עליכם לבנות את הדף הזה באפליקציה ולקרוא לגרף API בעצמכם.

00:14:04.440 --> 00:14:05.420
אבל הכיוון ברור.

00:14:05.420 --> 00:14:08.840
Microsoft רוצה ש-External ID יהיה ניתן לאוטומציה מלאה.

00:14:08.960 --> 00:14:10.860
זה מקל על הניהול בקנה מידע גדול.

00:14:10.980 --> 00:14:18.240
אז עכשיו אתם יודעים, Microsoft Entra External ID הוא התחליף המודרני ל-Azure DB2C, מאוחד תחת המותג Entra.

00:14:18.380 --> 00:14:25.540
שלושת מקרי הבוחן זהות לקוח, שיתוף פעולה עם שותפים ומכונה למכונה מכסים כמעט כל צורך בזהות חיצונית שתתקלו בו.

00:14:25.660 --> 00:14:30.320
וההחלטה המרכזית היא האם להשתמש בדייר כוח העבודה שלכם או ליצור דייר חיצוני נפרד.

00:14:30.320 --> 00:14:33.720
עבור אפליקציות הפונות ללקוחות, הפרדה היא כמעט תמיד עדיפה.

00:14:33.860 --> 00:14:36.120
זהות היא דלת הכניסה לאפליקציה שלכם.

00:14:36.300 --> 00:14:41.820
ביצוע נכון, מאובטח, ממותג ופשוט משפיע ישירות על אמון המשתמשים ועל צמיחת העסק.

00:14:42.020 --> 00:14:48.340
שיעורי הבית שלכם, גשו Entra.Microsoft.com, צרו דייר חיצוני ונסו את מדריך ההתחלה המהירה.

00:14:48.440 --> 00:14:51.260
הוא יוביל אתכם דרך הגדרת אפליקציה לדוגמה תוך דקות.

00:14:51.260 --> 00:14:55.300
הרשמו לערוץ לעוד הסברים בשפה פשוטה על פלטפורמת הזהויות של מייקרוסופט.