הגדרת האינטגרציה עם Okta

סקירה כללית

Okta יכולה לספק פעילות מנורמלת של מחזור חיי משתמשים, אימות, MFA ופעילות ניהולית. הדוגמאות שנבדקו כוללות:

account.locked — חשבון ננעל
mfa.factor.activated — הפעלת גורמי MFA נוספים
auth.login.failed — כשל בכניסה

שתי שיטות החיבור קוראות את אותם שני זרמי נתונים — ספריית המשתמשים (/api/v1/users) ויומן המערכת (/api/v1/logs). ראו כיצד נתוני אינטגרציה הופכים לאותות.

בחירת שיטת חיבור

	Okta (SSWS)	Okta (OAuth 2.0)
אישור גישה	אסימון API שאתם יוצרים ב-Admin Console	מזהה לקוח ו-JWK פרטי שאתם מפיקים ורושמים
הגדרה	שלושה שלבים, ללא צורך ביצירת חומר מפתחות	תשעה שלבים, כולל זוג מפתחות RSA
תפקיד מנהל נדרש	מנהל לקריאה בלבד, המוקצה לבעלים של האסימון	מנהל לקריאה בלבד, המוקצה לאפליקציה
תוקף האסימון	מושבת לאחר 30 יום ללא שימוש	ללא תפוגה; אתם אחראים לרוטציה של זוג המפתחות
מתי להשתמש	זהו המסלול המומלץ לרוב הארגונים	מדיניות האבטחה שלכם אוסרת שימוש באסימוני API ארוכי טווח

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

אפשרות א׳ — אסימון API (SSWS)

מומלץ.

מה Living Security צריכה

אישור גישה	תיאור
מפתח API	אסימון API של Okta. תיבת הדו-שיח של החיבור מציגה את השדה הזה בשם מפתח API
תת-דומיין של הדייר	`<tenant>` בתוך `<tenant>.okta.com` — תת-הדומיין בלבד, ולא כתובת ה-URL המלאה

דרישות מוקדמות

עליכם להיות Super Administrator ב-Okta כדי ליצור משתמש חשבון שירות, להקצות תפקידי מנהל וליצור אסימוני API.

יצירת משתמש שיהיה הבעלים של האסימון

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

ב-Admin Console, עברו אל Directory → People.
לחצו על Add person וצרו משתמש כגון svc-livingsecurity@yourcompany.com.
הפעילו את החשבון.

הקצאת תפקיד מנהל לקריאה בלבד

הפלטפורמה קוראת בלבד. מתן הרשאות מעבר לקריאה מעניק לאסימון הרשאות שאינו משתמש בהן.

עברו אל Security → Administrators.
לחצו על Add administrator ובחרו את המשתמש מהשלב הקודם.
הקצו את התפקיד Read-only Administrator.
לחצו על Save.

ללא תפקיד מנהל, קריאות ל-Okta Management API מצליחות עם 200 OK ומחזירות רשימה ריקה. אין 403 שמצביע על כך שהתפקיד חסר — הזרמים פשוט נשארים ריקים.

יצירת אסימון ה-API

היכנסו ל-Admin Console כמשתמש חשבון השירות משלב 1. האסימון יורש את ההרשאות של החשבון שיוצר אותו.
עברו אל Security → API ופתחו את הכרטיסייה Tokens.
לחצו על Create token, תנו לו שם כגון Living Security Platform ולחצו על Create token.
העתיקו את ערך האסימון עכשיו — Okta מציגה אותו פעם אחת בלבד.

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

רשימת הכתובות שלמעלה רלוונטית רק אם ארגון ה-Okta שלכם מגביל גישה ל-API לפי network zone. ברוב הארגונים אין הגבלה כזו.

איתור תת-הדומיין של הדייר

כתובת ה-URL של ה-Admin Console נראית כך: https://acme-admin.okta.com. תת-הדומיין של הדייר הוא acme — ללא הסיומת -admin, ללא .okta.com וללא https://.

כעת אתם מחוברים ל-Okta (SSWS).

פתרון בעיות

401 Unauthorized

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

החיבור הצליח, אך כל הזרמים ריקים

לבעלים של האסימון אין תפקיד מנהל. הקצו את התפקיד Read-only Administrator לחשבון השירות (שלב 2) — כאשר התפקיד חסר, ה-API מחזיר 200 OK עם רשימה ריקה במקום שגיאה.

הסנכרונים נכשלים לאחר שינוי בצוות

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

אפשרות ב׳ — אפליקציית שירות OAuth 2.0

השתמשו בשיטה זו כאשר מדיניות האבטחה שלכם אינה מתירה אסימוני API ארוכי טווח. היא מחליפה את האסימון במזהה לקוח ובזוג מפתחות RSA שבבעלותכם. בפלטפורמה זהו האריח Okta (OAuth 2.0), תחת הגדרות → שילובי → קטלוג. כדי לבצע אימות מול Okta באמצעות Client Credentials, דרושים לכם הפריטים הבאים:

מזהה לקוח - מזהה ייחודי של אפליקציית API Services שלכם ב-Okta.
מפתח פרטי (JWK) - מפתח ה-RSA הפרטי בפורמט JSON Web Key, שהמפתח הציבורי שלו רשום באפליקציית Okta שלכם.
דומיין Okta - תת-הדומיין של דייר Okta שלכם בלבד (לדוגמה dev-12345678), ולא שם המארח המלא.
היקפי הרשאה (Scopes) - רשימה של היקפי הרשאה של Okta Management API, מופרדים ברווחים (לדוגמה okta.users.read okta.logs.read).

מדריך זה ילווה אתכם ביצירת אפליקציית API Services ב-Okta עם אימות private_key_jwt.

דרישות מוקדמות:

עליכם להיות בעלי חשבון Okta. ניתן להירשם לחשבון מפתחים חינמי בכתובת developer.okta.com.

שלב 1: יצירת אפליקציית Okta API Services

היכנסו ל-Okta Admin Console.
בסרגל הצד השמאלי, עברו אל Applications > Applications.
לחצו על Create App Integration.
בחרו API Services כשיטת הכניסה ולחצו על Next.

תנו שם לאפליקציה ולחצו על Save.
בכרטיסייה General של האפליקציה, מצאו את Client ID — תזדקקו לו בשלב האחרון.
הגדירו את Client authentication לערך Public key / Private key. היקפי ההרשאה של okta.* נתמכים רק בשיטת אימות זו.

השביתו את Proof of possession (DPoP) — הוא אינו נתמך.

יש ליצור את האפליקציה כ-API Services.

שלב 2: יצירה ורישום של זוג מפתחות RSA

שימוש במחולל המפתחות של Okta

Okta יכולה ליצור עבורכם את זוג מפתחות ה-RSA ישירות ב-Admin Console:

ב-Admin Console, פתחו את אפליקציית ה-API Services שלכם.
עברו לכרטיסייה General וגללו אל הקטע PUBLIC KEYS.
לחצו על Add Key ולאחר מכן בחרו Generate new key.
לחצו על Save — Okta יוצרת את זוג המפתחות ומציגה את Private Key (JWK) פעם אחת בלבד.
העתיקו ושמרו מיד את ה-JSON של המפתח הפרטי — הוא לא יוצג שוב.

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

העתיקו את ה-JWK הפרטי לפני סגירת תיבת הדו-שיח. הדביקו אותו בשדה מפתח פרטי ב-Living Security Platform בשלב האחרון.

יצירת מפתח משלכם

Okta משתמשת ב-private_key_jwt עבור אפליקציות API Services. אתם יוצרים זוג מפתחות RSA, רושמים את ה-JWK הציבורי ב-Okta, ומספקים את ה-JWK הפרטי ל-Living Security Platform. צרו JWK פרטי באמצעות סקריפט Node.js הבא (דורש Node.js 18 ומעלה):

const { generateKeyPairSync } = require('crypto');
const { privateKey, publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });

const privateJwk = privateKey.export({ format: 'jwk' });
const publicJwk  = publicKey.export({ format: 'jwk' });

// Assign a kid — must match between private and public JWK
const kid = require('crypto').randomUUID();
privateJwk.kid = kid;
publicJwk.kid  = kid;

console.log('=== PUBLIC JWK (upload to Okta) ===');
console.log(JSON.stringify(publicJwk, null, 2));
console.log('\n=== PRIVATE JWK (paste into the Living Security Platform) ===');
console.log(JSON.stringify(privateJwk));

רשמו את ה-JWK הציבורי ב-Okta:

ב-Admin Console, פתחו את אפליקציית ה-API Services שלכם.
עברו לכרטיסייה General וגללו אל הקטע PUBLIC KEYS.
לחצו על Add Key, הדביקו את פלט JSON של ה-JWK הציבורי מהסקריפט שלמעלה ולחצו על Save.

ה-JWK הפרטי הוא זה שמדביקים ב-Living Security Platform. הוא כולל את כל חומר המפתח (d, p, q, dp, dq, qi) ואת ה-kid. שמרו עליו בסודיות.

שלב 3: איתור דומיין Okta שלכם

הזינו את תת-הדומיין של דייר Okta שלכם בלבד — החלק שלפני .okta.com.

ב-Admin Console, שורת הכתובת בדפדפן תציג כתובת URL כגון https://dev-12345678-admin.okta.com.
דומיין Okta שלכם הוא תת-הדומיין בלבד (לדוגמה dev-12345678), ולא dev-12345678.okta.com.
לחלופין, עברו אל Settings > Account ב-Admin Console כדי למצוא את דומיין Okta שלכם, ולאחר מכן השתמשו בחלק של תת-הדומיין.

שלב 4: הענקת היקפי הרשאה ל-API לאפליקציה שלכם

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

ב-Admin Console, עברו אל Applications > Applications ופתחו את האפליקציה שלכם.
לחצו על הכרטיסייה Okta API Scopes.
הענקו את היקפי ההרשאה הנדרשים לאינטגרציה שלכם: okta.users.read ו-okta.logs.read.

רשימה מלאה של היקפי ההרשאה הזמינים מופיעה ב-מסמך העזר של Okta Management API.

שלב 5: הקצאת תפקיד מנהל לאפליקציה שלכם

הענקת היקפי הרשאה בלבד אינה מספיקה — נקודות הקצה של Okta Management API (לדוגמה /api/v1/users) מחזירות בשקט תגובת 200 [] ריקה אם לאפליקציה שלכם אין תפקיד מנהל. יש להקצות לפחות Read-Only Administrator:

ב-Admin Console, עברו אל Security > Administrators (או עברו אל Applications > Applications > האפליקציה שלכם > Admin roles).
לחצו על Add administrator assignment ובחרו את אפליקציית ה-API Services שלכם.

הקצו את התפקיד Read-Only Administrator (או גבוה יותר, בהתאם להיקפי ההרשאה הנדרשים).
לחצו על Save.

ללא תפקיד מנהל, קריאות ה-API מצליחות עם 200 OK אך מחזירות תוצאות ריקות, ואין שגיאת 403 שמצביעה על הבעיה.

שלב 6: הזנת אישורי הגישה ב-Living Security Platform

לאחר שברשותכם מזהה לקוח, מפתח פרטי (JWK), דומיין Okta ו-היקפי הרשאה (Scopes):

פתחו את הטופס שבו יש לבצע אימות מול Okta (Client Credentials).
הזינו את מזהה הלקוח שלכם.
הדביקו את המפתח הפרטי (JWK) — אובייקט ה-JSON המלא מהסקריפט שלמעלה (בשורה אחת או בפורמט מסודר).
הזינו את דומיין Okta כתת-הדומיין של הדייר בלבד (לדוגמה dev-12345678).
הזינו את היקפי ההרשאה כרשימה המופרדת ברווחים (לדוגמה okta.users.read okta.logs.read).
שלחו את הטופס, והאימות אמור להצליח.

כעת אתם מחוברים ל-Okta (Client Credentials).

חלקים מתיעוד זה הותאמו מתוך Nango, ונעשה בהם שימוש ברישיון Elastic License 2.0.

אינטגרציות

הגדרת אינטגרציה

קטלוג

ערוצי שליחה

הגדרת האינטגרציה עם Okta

סקירה כללית

בחירת שיטת חיבור