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

לבנות את כל זה בעצמך, זה הפך לסיוט. התשובה הראשונה של מייקרוסופט הייתה Azure ADB2C. זה היה שירות זהות ללקוחות, ובזמנו הוא פתר בעיה אמיתית. אבל כאן התחילו הבעיות. הבעיה הכי גדולה הייתה משהו שנקרא מדיניות מותאמת אישית, Custom Policies, והמדיניות הזו נכתבה ב-XML. אם עבדתם אי פעם עם קבצי XML שנפרסים על מאות שורות, אתם יודעים בדיוק כמה זה כואב. קשה להגדרה, קשה לניפוי שגיאות, וכשמה שהוא נשבר, בהצלחה להבין למה. מעבר לזה, Azure ADB2C היה נפרד מפלטפורמת הזהות הראשית של מייקרוסופט. אז, אם כבר היה לכם Microsoft 365 או Azure AD עבור העובדים שלכם, B2C הרגיש כמו ללמוד מוצר חדש לגמרי. כפי שניתן לצפות, צוותי העית התקשו לתחזק אותו, מפתחים חששו לעבוד איתו, והלקוחות קיבלו חוויית הרשמה מסורבלת שגרמה להם לרצות לעזוב. מייקרוסופט הבינה שהם צריכים משהו פשוט ומאוחד יותר, וזה בדיוק מה שהפך ל-Microsoft Entra External ID. מה זה בעצם Microsoft Entra External ID? אז, מה זה בדיוק Microsoft Entra External ID? הנה ההגדרה הפשוטה ביותר.

זהו שירות זהות בענן עבור משתמשים חיצוניים, לקוחות, שותפים ואורחים, לא עבור עובדים. תחשבו על זה ככה. דמיינו של החברה שלכם יש בניין משרדים. זהו הטננט של כוח העבודה שלכם. זה המקום שבו העובדים שלכם עובדים איפה שהשולחנות שלהם, ואיפה שהתגים שלהם מאפשרים להם להיכנס. Entra ID מנהל את הבניין הזה. עכשיו, תארו לעצמכם שאתם פותחים חנות ללקוחות, מרחב נפרד, עם כניסה משלו, חוקים משלו, והבטחה משלו. לקוחות לא משוטטים בחדר ההפסקה של העובדים, ועובדים לא ניגשים בטעות לחשבונות של לקוחות. זהו External ID. זהו חלק ממשפחת Microsoft Entra, אבל בגרסה שונה. הוא נבנה עבור CIEM, ניהול זהויות וגישה של לקוחות, והוא מטפל בכל מחזור החיים של משתמש חיצוני. הרשמה, התחברות, איפוס סיסמה, ניהול פרופיל, MFA, והנפקת הסימונים. הוא עובד עם פרוטוקולים סטנדרטיים כמו OOF 2.0, Open ID Connect ו-SML, כך שכמעט כל אפליקציה שתבנו תוכל להתחבר. אבל, הנה ההבדל הגדול מ-Azure ADB2C הישן. External ID הוא פשוט יותר. אין יותר מדיניות XML מותאמת אישית.

במקום זאת, אתם מגדירים תהליכי משתמש ישירות במרכז הניהול. או שאתם משתמשים בתוספי עימות מותאמים אישית, שמתחברים ללוגיקת Hey Backend הקיימת שלכם. אותה עוצמה, פחות כאב ראש. שלושת מקרי השימוש העיקריים. אז איך בעצם משתמשים באקטרנל ID? ישנם שלושה תרחישים עיקריים. הם מכסים כמעט כל מצב שבו צריך לנהל מישהו שאינו עובד. נתחיל בנפוץ ביותר, זהות לקוח, או B2C. תארו לעצמכם שאתם בונים אפליקציה להזמנת פיצה. אתם צריכים שאנשים ירשמו, יבצעו הזמנות ויחזרו בשבוע הבא. אתם רוצים שהם יתחברו עם חשבון הגוגל שלהם במקום ליצור סיסמה נוספת, ואתם צריכים לאסוף את השם, מספר הטלפון והעדפות המשלוח שלהם. אקסטרנל ID מטפל בכל זה. אתם מקבלים תהליכי הרשמה והתחברות מובנים מראש. אתם מגדירים אילו מאפיינים לאסוף, שם, טלפון, או כל מה שתצטרכו. אתם מגדירים התחברות חברתית עם גוגל, פייסבוק או אפל. וכאשר משתמש מאומת, אקסטרנל ID מנפיק הסימון לאפליקציה שלכם כדי שהיא תדע מהאדם הזה. זהו התחליף לאזר אדי בי 2C, וזה המקום שבו רוב הארגונים מתחילים.

תרחיש נוסף הוא שיתוף פעולה בין עסקים, או בי 2B. זה המצב שבו אתם צריכים לתת לשותפים או ספקים גישה לאפליקציות הפנימיות שלכם. אולי יש לכם אתר SharePoint ששותף הלוגיסטיקה החיצוני שלכם צריך לראות, או כלי לניהול פרויקטים שהמעצבים העצמאיים שלכם משתמשים בו. בתרחיש זה, אתם מזמינים אותם כמשתמשים עורכים בדייר, טננט, העובדים שלכם. אקסטרנל ID מטפל בדואר אלקטרוני ההזמנה, בתהליך המימוש שבו הם מקבלים את ההזמנה, ובמדיניות הגישה ששולטת במה שהם יכולים לראות. זה למעשה קיים כבר שנים כשיתוף פעולה בי 2B בתוך Azure AD, אך כעת זה חלק מטריאת האקסטרנל ID, כך שאתה מנהל את זה מאותו המקום שבו אתה מנהל את זהויות הלקוחות שלך. אחר כך ישנו Hey Machine to Machine או M2M. זה פחות גלוי למשתמשי קצה, אך חשוב באותה מידה. לפעמים שירות Hey Backend שלך צריך לתקשר עם API אחר, מאבד תשלומים, שירות ניתוח נתונים או מיקרו שירות פנימי. אין מעורבות של אדם, זו רק אפליקציה אחת שקורית לאחרת. אקסטרנל ID משתמש בתהליך ה-off 2.0 Client Credentials.

השירות שלך מבצע אימות עצמי באמצעות מזהה לקוח וסוד, ומקבל הסימון כדי לקרוא לאפי-איי במורד הזרם. זה דורש את התוסף M2M Premium, כך שיש כאן מרכיב עלות, אך אם עליך להבטח תקשורת בין API לאפי-איי, זה מובנה בפנים. כעת, שלושת התרחישים האלו מכסים כמעט כל מצב של זהות חיצונית שתתכל בו, אך יש החלטה גדולה שעליך לקבל, וזה היכן המשתמשים האלו באמת חיים. מכיוון ש-אקסטרנל ID יכול לרוץ בשני מקומות שונים מאוד, דייר כוח עבודה מול דייר חיצוני. בוא נפרק את שתי האפשרויות. אקסטרנל ID יכול לרוץ בתוך דייר כוח העבודה הקיים שלך, או שהוא יכול לרוץ כדייר חיצוני נפרד לחלוטין. הם לא אותו הדבר, ובחירה לא נכונה עלולה לגרום לי בעיות בהמשך הדרך. נתחיל באפשרות של דייר כוח העבודה. לחברה שלך כבר יש דייר Entra ID עבור העובדים שלך. זהו דייר כוח העבודה שלך. אם תפעיל תכונה שנקראת הרשמה בשירות עצמי לאורחים בתוך הדייר הזה, משתמשים חיצוניים יוכלו להירשם ולהגיע לאותה ספרייה כמו העובדים שלך. החשבונות שלהם יושבים ממש ליד החשבון של המנכל שלך.

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

שנית, אתם מקבלים מיתוג נפרד. ניתן להתאים אישית את המראה והתחושה של דפי ההתחברות עבור הלקוחות שלכם, מבלי להשפיע על דייר הארגון. שלישית, אתם מקבלים API אימות מקורי לאפליקציות מובייל, המאפשר בניית משקי כניסה מותאמים אישית באפליקציות iOS או Android, ללא הפניות דפדפן, ללא תצוגות אינטרנט מסורבלות. ורביעית, אתם מקבלים תמחור מבוסס מהו, משתמשים פעילים חודשיים. משלמים רק על משתמשים שביצעו אימות בפועל בחודש נתון, מה שמתרחב באופן טבעי עם צמיחת הלקוחות שלכם. אז מתי בוחרים במה? זה די פשוט. אם אתם בונים אפליקציית B2C עם אלפי לקוחות, לכו על דייר חיצוני External Tenant. זו הגישה המומלצת ועבורה תוכנן External ID. אם אתם רק מזמינים שותפים לגשת למשאבים פנימיים, אפשרות דייר כוח האדם מספיקה. המפתח הוא להבין את ההבדל לפני שמתחילים לבנות, כי מעבר מאחד לשני בהמשך אינות ראיאלי. אבטחה, MFA וגישה מותנית. עכשיו, בואו נדבר על אבטחה. אם אתם מתכוונים לאפשר ללקוחות להיכנס לאפליקציה שלכם, עליכם לוודא שהאנשים הלא נכונים לא ייכנסו.

External ID כולל את אותה מאפייני הבטחה ברמה ארגונית ש-Entra ID מציע לעובדים. זה אומר עימות רב שלבי, גישה מותנית ומדיניות מבוססת סיכונים. עבור MFA יש לכם כרגע שתי אפשרויות. קוד גישה חד פעמי במייל הוא בחינם. המערכת שולחת קוד למייל של המשתמש ומקליד אותו, וזהו. קוד גישה חד פעמי ב-SMS עובד באותו אופן, אך נשלח לטלפון שלהם ויש עלויות מפעיל. נקודה חשובה, אין עדיין תמיכה ב-Microsoft Authenticator. זו מגבלה נוכחית, וזה משהו שמייקרוסופט כנראה עובדת עליו. אבל כרגע, זה אימייל או SMS. גישה מותנית היא המקום שבו דברים הופכים למעניינים. ניתן להגדיר חוקים כמו דרישת MFA כאשר רמת סיכון ההתחברות בינונית ומעלה, או חסימת גישה ממדינות שאיננו פועלים בהן. המערכת מעריכה כל ניסיון התחברות בזמן אמת. אם מי שהוא מנסה להתחבר ממיקום או מכשיר שנראים חשודים, היא יכולה להעלות אוטומטית את דרישות ההבטחה ללא צורך שתבנו את הלוגיקה הזו בעצמכם. אבל יש פיצ'ר אחד שבולט במיוחד, אימות מדורג, Step Up Authentication. הנה איך זה עובד. דמיינו שמשתמש נכנס לאפליקציה שלכם רק עם סיסמה כדי לעיין בכתלוג המוצרים.

זה בסדר לפעילויות בסיכון נמוך. אבל כשהם מנסים לצפות בהיסטוריית התשלומים או להוריד חשבונית, תרצו אימות נוסף. באמצעות אימות מדורג, Step Up, ניתן לדרוש אימות רב-גורמי, MFA, רק עבור חלקים ספציפיים באפליקציה. המשתמש לא יתבקש להזדהות עד שינסה לגשת למידע רגיש. הכל מנוהל מאחורי הקלעים על ידי External ID באמצעות רכיב שנקרא הקשר אימות Authentication Context. אתם מגדירים אילו חלקים באפליקציה דורשים אבטחה נוספת, והמערכת מטפלת בכל השאר. המשתמש נהנה מחוויה חלקה בגלישה בסיסית, אך המידע הרגיש נשאר מוגן. מיתוג וחוויית משתמש שליטה במיתוג היא אחת הסיבות העיקריות לכך שארגונים בוחרים באקסטרנל ID במקום לבנות מערכת התחברות משלהם. אתם מקבלים שליטה מלאה על המראה והתחושה של דפי ההרשמה וההתחברות, העלאת לוגו, הגדרת צבעי רקע, הוספת אייקון לחרטיסיית הדפדפן, והתאמת הכותרת והתחתית עם קישורים למדיניות הפרטיות ותנאי השירות. אם תרצו שליטה רבה יותר, תוכלו להעלות קובץ CSS מותאם אישית כדי לשנות גופנים, צבעי כפתורים ופריסה. זה המותג שלכם, הצבעים שלכם, הכל לפי החלטתכם.

כאן העניינים נהיים מעט מורכבים. המיתוג הוא גלובלי לכל דייר, טננט, ולא לכל אפליקציה בנפרד. לכן, אם יש לכם מספר אפליקציות, למשל פורטל לקוחות ואפליקציית מובייל, כולן יחלקו את אותם דפים ממותגים. לא ניתן להעניק לכל אפליקציה מראה ייחודי משלה. ב-Azure AD B2C הישן ניתן היה לבצע מיתוג לכל אפליקציה, אך External ID עדיין לא תומך בכך. מגבלה נוספת היא שלא ניתן להתאים אישית הודעות שגיאה בדפי ההתחברות. אם מי שהוא יקליד כתובת אימייל לא קיימת, הוא יראה הודעה כמו, לא הצלחנו למצוא חשבון עם כתובת אימייל זו. ואת הטקסט הזה לא ניתן לשנות. עבור חלק מהארגונים זה בסדר, אך עבור אחרים, במיוחד בתעשיות מוסדרות או עם שפת מותג קפדנית, זו בעיה אמיתית. אפליקציות מובייל מקבלות אפשרות טובה יותר. לאקסטרנל ID יש ממשק API לאימות מקורי, ניטיב עבור iOS ואנדרואיד. במקום להפנות משתמשים לדף התחברות מבוסס דפדפן, ניתן לבנות מסקי התחברות מותאמים אישית בתוך האפליקציה. ללא הפניות לדפדפן, ללא דפי אינטרנט מסורבלים. המשתמש נשאר באפליקציה שלכם לאורך כל התהליך, ואתם שולטים בכל פיקסל.

זו חוויה הרבה יותר חלקה, וזה אחד הפיאטשרים שמעולם לא היו קיימים ב-Azure AD B2C. הגירה מ-Azure AD B2C אם אתם כבר משתמשים ב-Azure AD B2C, בטח תהיתם מה זה אומר עבורכם. הנה העניין, מייקרוסופט תמשיך לתמוך ב-B2C לפחות עד שנת 2030. לכן, הדיירים הקיימים שלכם לא יפסיקו לעבוד מחר, אך תכונות חדשות לא התווספו. כל החדשנות מפתחות גישה, פסקיז, אימות מקורי, הגנה מפני הונאות בלעדית, לאקסטרנל ID. אתם נמצאים על פלטפורמה שלמעשה קפואה בזמן. מייקרוסופט פרסמה כלי הגירה והנחיות רשמיים, וישנם שני מסלולים בהתאם להיקף הפעילות שלכם. עבור דיירים, טנאנטס, עם פחות מ-5 מיליון אובייקטי ספרייה, משתמשים, קבוצות ומאפיינים מותאמים אישית, ההגירה הסטנדרטית היא פשוטה יחסית. זה עובד כמו העברה בין דיירים. יוצרים דייר אקסטרנל ID חדש, מעבירים את המשתמשים ואת אישורי הגישה שלהם, ואז מעבירים את היישומים. מייקרוסופט מספקת כלים לייצוב ואיבו משתמשים בחמות גדולה, וניתן להשתמש בהגירת סיסמאות בזמן אמת כדי לצמצם שיבושים במהלך המעבר. עבור דיירים גדולים יותר עם מעל 5 מיליון אובייקטי ספרייה, קיים מצב תאימות בהיקף גבוה, או HSC.

במצב זה, Azure AD B2C ו-External ID פועלים זה לצד זה באותו הדייר. נקודות הקצה הקיימות של B2C נשארות פעילות בזמן שאתם מעבירים את היישומים בהדרגה. זה מיועד לארגונים שלא יכולים להעביר מיליוני משתמשים בין לילה, אך זה מגיע עם פשרות. ללא ספקי זהות חברתיים, ללא מפתחות גישה, פסקיז, גישה מותנית מוגבלת וחלק מהתכונות פשוט אינן זמינות. תחשבו על זה כאסטרטגיית גישור, לא כפתרון קבוע. עכשיו, שינוי משמעותי. מדיניות מותאמת אישית, Custom Policies, אינה קיימת יותר. אם בניתם תהליכי אימות מורכבים באמצעות מסגרת ניהול הזהויות מבוססת ה-XML של Azure AD B2C, הם לא יעבדו באקסטרנל ID. תצטרכו לבנות מחדש את הלוגיקה הזו באמצעות זרימות משתמש והרחבות אימות מותאמות אישית. אין כלי קסם שממיר את ה-XML שלכם לפורמט החדש. פשוט תצטרכו לעשות את העבודה. אז, הנה השורה התחתונה. אם אתם מתחילים היום מ-0, השתמשו באקסטרנל ID. אין סיבה אפילו להסתכל על B2C. אם יש לכם דייר B2C קיים, התחילו לתכנן את ההגירה שלכם עכשיו. יש לכם זמן עד 2030, אבל המתנה לדקה ה-90 אומרת שתמהרו לבצע הגירה מורכבת תוך ניסיון לשמור על האפליקציות הקיימות פועלות.

התחילו בקטן, בחרו יישום אחד, העבירו אותו, בדקו אותו, לימדו מהתהליך, ואז עשו את השאר. חוויית מפתח ואוטומציה. מייקרוסופט באמת התמקדה בהפיכת אקסטרנל ID לקל עם מפתחים, וזה שינוי עצום מהמדיניות המותאמת האישית של B2C הישן. אתם מכירים את קבצי ה-XML האלה שנמתחו על פני מאות שורות ונשברו אם שכחתם סוגריים אחד? זה נעלם. יש הרחבה ל-Visual Studio Code בשם Microsoft Entra External ID. לאחר האימות, תוכלו לסייר בדייר שלכם, לצפות מזרימות משתמש, להוריד אותן כקבצי JSON, ואפילו להציג תצוגה המקדימה של המיתוג, הכל מבלי לעזוב את האורך.

כמעט כל משיו ב-External ID, זרימות משתמש, רישומי אפליקציות ומיתוג ניתנים לניהול תכנותי. זה אומר שניתן לבצע אוטומציה להגדרת הדייר בצינורות ה-C, CD שלכם באמצעות PowerShell או קריאות REST. צרו דייר חדש, הגדירו זרימות משתמשים, רשמו את האפליקציה וקבו מיתוג, הכל מתוך סקריפט. אם אתם מנהלים סביבות מרובות, זה חוסך המון זמן. תוספי אימות מותאמים אישית הם המקום שבו נמצא הכוח האמיתי. במקום XML מורכב, אתם מרחיבים את זרימות האימות עם קריאות HTTP פשוטות ל-Azure Functions. ישנם ארבעה אירועים שאפשר להתחבר עליהם. התחלת הנפקת אסימון מאפשרת להוסיף תביעות מותאמות אישית להסימונים, כמו תפקידים או פרטי דרגת נאמנות. התחלת ושליחת איסוף מאפיינים מאפשרות לאמת או למלא מראש נתוני הרשמה על ידי קריאה לבקאנד שלכם. ואימייל OTP שנשלח מאפשר לכם להתאים אישית את הודעות האימות. זו אותה דמישות שהייתה ב-B2C, אבל במודל שכל מפתח יכול לעבוד איתו. יש מגבלות שצריך להכיר. עדיין אין התראות Microsoft Graph, לכן אי אפשר להפעיל אוטומטית זרימת עבודה כשמשתמש חדש נרשם.

חלק מההגדרות עדיין דורשות ביצוע ידני במרכז הניהול, ואין דף עריכת פרופיל מובנה. אם אתם רוצים שמשתמשים יעדכנו את המידע שלהם, עליכם לבנות את הדף הזה באפליקציה ולקרוא לגרף API בעצמכם. אבל הכיוון ברור. Microsoft רוצה ש-External ID יהיה ניתן לאוטומציה מלאה. זה מקל על הניהול בקנה מידע גדול. אז עכשיו אתם יודעים, Microsoft Entra External ID הוא התחליף המודרני ל-Azure DB2C, מאוחד תחת המותג Entra. שלושת מקרי הבוחן זהות לקוח, שיתוף פעולה עם שותפים ומכונה למכונה מכסים כמעט כל צורך בזהות חיצונית שתתקלו בו. וההחלטה המרכזית היא האם להשתמש בדייר כוח העבודה שלכם או ליצור דייר חיצוני נפרד. עבור אפליקציות הפונות ללקוחות, הפרדה היא כמעט תמיד עדיפה. זהות היא דלת הכניסה לאפליקציה שלכם. ביצוע נכון, מאובטח, ממותג ופשוט משפיע ישירות על אמון המשתמשים ועל צמיחת העסק. שיעורי הבית שלכם, גשו Entra.Microsoft.com, צרו דייר חיצוני ונסו את מדריך ההתחלה המהירה. הוא יוביל אתכם דרך הגדרת אפליקציה לדוגמה תוך דקות. הרשמו לערוץ לעוד הסברים בשפה פשוטה על פלטפורמת הזהויות של מייקרוסופט.