> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

> חברו את OneLogin אל Living Security לצורך מחזור חיי משתמשים, אימות, MFA ופעילות ניהולית.

export const EgressIpAllowlistBothSets = ({system}) => <Warning>
    <strong>{system} דורש שתי קבוצות של כתובות, לא קבוצה אחת.</strong> Living Security מנפיקה את אסימון הגישה של האינטגרציה הזו בתשתית שלה ומרעננת אותו באופן רציף, ולכן תעבורת ההגדרה ותעבורת הסנכרון יוצאות מרשתות שונות. יש להוסיף את שתי הקבוצות לרשימת ההיתרים ב-{system} ולהשאיר את שתיהן במקומן — זו אינה דרישה שחלה רק בשלב ההגדרה.
    <br />
    <br />
    <strong>תעבורת סנכרון של האינטגרציה</strong> — זהה בכל אזור:
    <br />
    <code>52.34.139.153/32</code>, <code>54.69.127.183/32</code>, <code>44.247.133.183/32</code>,{' '}
    <code>52.26.211.56/32</code>
    <br />
    <br />
    <strong>תעבורת הפלטפורמה</strong> — יש להשתמש רק בשורה של האזור שמארח את הארגון שלכם:
    <br />
    ארצות הברית: <code>98.91.60.249/32</code>, <code>13.216.91.102/32</code>
    <br />
    האיחוד האירופי: <code>34.246.236.210/32</code>, <code>52.31.102.238/32</code>
    <br />
    <br />
    אם תוסיפו לרשימת ההיתרים רק את קבוצת הסנכרון, ההגדרה לא תושלם לעולם. אם תוסיפו רק את קבוצת הפלטפורמה, ההגדרה תצליח אך כל סנכרון ייכשל. לתיאור של שני סימני הכשל ולמדיניות השינויים, ראו{' '}
    <a href="/he/integrations/managing/egress-ip-addresses">
      הגדרת כתובות IP של יציאה עבור אינטגרציות
    </a>.
  </Warning>;

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>משאבים קשורים</h2>
    <ul>
      <li>
        <a href="/he/signals/data-sources">כך הופכים נתוני אינטגרציה לאותות של ניהול סיכוני גורם אנוש</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">גלו את האינטגרציות של Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">פתחו את Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">בקשו הדגמה של Living Security</a>
      </li>
    </ul>
  </>;

export const ConnectInPlatform = ({tile, children}) => <Step title="הזינו את פרטי הגישה ב-Living Security Platform">
    <p>
      השלב מבוצע על ידי מי שיש לו גישה ל-Living Security — בעל התוכנית, או מנהל המערכת
      אם הוזמן (הגדרה מואצלת).
    </p>
    <ol>
      <li>
        עברו אל <strong>הגדרות → שילובי → קטלוג</strong>, אתרו את האריח{' '}
        <strong>{tile}</strong> ולחצו על <strong>חבר</strong>.
      </li>
      <li>
        מלאו את השדות שלהלן, ולאחר מכן לחצו על <strong>חבר</strong>.
      </li>
    </ol>
    {children}
  </Step>;

export const SystemAdminBanner = ({system, recommendDelegated}) => <Note>
    <p>
      <strong>מדריך זה מיועד למנהל/ת {system} שלכם.</strong> הוא עוסק ביצירת אישורי API
      בתוך {system}, פעולה הדורשת הרשאות ניהול ב-{system} — ולא ב-Living Security Platform.
    </p>
    <p>
      אם אתם <strong>בעלי התוכנית</strong> של Living Security ואינכם מנהלים את {system},
      העבירו דף זה לאיש או אשת הקשר המנהלים אותה. הם ישלימו את חלק A ויעבירו אליכם את האישורים
      (או שיזינו אותם ישירות אם הוזמנו לפלטפורמה).
      {recommendDelegated && <>
          {' '}מאחר שהתקנה זו מפיקה חומרי מפתח רגישים, אנו ממליצים על מסלול{' '}
          <strong>ההתקנה המואצלת</strong>, כך שהסוד לעולם לא יישלח אליכם.
        </>}
    </p>
  </Note>;

<SystemAdminBanner system="OneLogin" recommendDelegated={true} />

## מה האינטגרציה הזו תורמת

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

* `mfa.success` — משלים אתגרי MFA
* `mfa.failed` — נכשל באתגרי MFA
* `account.locked` — חשבון ננעל

ראו [כיצד נתוני אינטגרציה הופכים לאותות](/he/signals/data-sources).

## מה Living Security צריכה

| אישור גישה | תיאור |
| - | - |
| **מזהה לקוח** | מזהה הלקוח של זוג אישורי API ב-OneLogin עם הרשאה לקרוא משתמשים ואירועים. |
| **Client secret** | הסוד של זוג אישורי הגישה הזה. |
| **Tenant subdomain** | הערך שלפני `.onelogin.com` בכתובת ה-URL של דייר OneLogin שלכם. |

## הגדרה

<Steps>
  <Step title="יצירת אישורי API ב-OneLogin">
    כבעלי חשבון או כמנהלי מערכת, פתחו את **Developers → API Credentials**, צרו אישור ייעודי ובחרו היקף הרשאות המאפשר קריאת משתמשים ואירועים. שמרו את מזהה הלקוח ואת הסוד במקום מאובטח.
  </Step>

  <ConnectInPlatform tile="OneLogin">
    הזינו את תת-הדומיין של הדייר, את מזהה הלקוח ואת הסוד, ולאחר מכן התחברו.
  </ConnectInPlatform>
</Steps>

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

## אימות ופתרון בעיות

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

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    מזהה הלקוח או הסוד שגויים, או שזוג אישורי הגישה נמחק ב-OneLogin. ודאו שהזוג עדיין קיים תחת **Developers → API Credentials**, ולאחר מכן התחברו מחדש עם הערכים העדכניים.
  </Accordion>

  <Accordion title="403 Forbidden">
    צרו מחדש את אישור ה-API עם הרשאה לקרוא ממשקי API של משאבי OneLogin, משתמשים ואירועים.
  </Accordion>

  <Accordion title="לא ניתן להגיע לדייר">
    הזינו רק את תת-הדומיין של הדייר, ולא כתובת URL מלאה ולא את שם התצוגה הניהולי.

    אם תת-הדומיין נכון ועדיין לא ניתן להגיע לדייר, בדקו אם OneLogin מגבילה בחשבון שלכם את הגישה ל-API לפי כתובת IP של המקור. אינטגרציה זו דורשת הוספה לרשימת ההיתרים של **שתי** קבוצות כתובות, מכיוון ש-Living Security מפיקה את אסימון הגישה בעצמה ומחדשת אותו באופן רציף — ולכן בקשות האסימון והסנכרונים המתוזמנים יוצאים מרשתות שונות.

    <EgressIpAllowlistBothSets system="OneLogin" />
  </Accordion>
</AccordionGroup>

לפרטים בצד הספק, ראו [המדריך של OneLogin לאישורי API](https://developers.onelogin.com/api-docs/2/getting-started/working-with-api-credentials).

<PublicIntegrationNextSteps />


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.