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

# Anmeldeinformationen und Sitzungen

> Wie Iru Identity die Anmeldeinformationen, mit denen sich Benutzer anmelden, und ihre Sitzungen schützt und wie Sie den Zugriff bei Bedarf sofort beenden.

Hinter jedem Benutzer, der über Iru eine App erreicht, stehen zwei Dinge: die
**Anmeldeinformation**, mit der er nachgewiesen hat, wer er ist, und die **Sitzung**, die ihn
danach angemeldet hält. So schützt Iru beides, und so sperren Sie jemanden aus,
wenn es nötig ist.

## Wie Anmeldeinformationen geschützt werden

Benutzer weisen mit **Authenticators** nach, wer sie sind, wobei ein **Passkey** der
wichtigste ist. Passkeys sind so konzipiert, dass sie Phishing widerstehen, dem häufigsten
Weg, auf dem Anmeldeinformationen gestohlen werden.

<CardGroup cols={2}>
  <Card title="Das Geheimnis verlässt nie den Benutzer" icon="fingerprint">
    Ein Passkey hält das Geheimnis, das die Identität nachweist, an das Gerät des Benutzers gebunden.
    Bei der Anmeldung wird nachgewiesen, dass der Benutzer es besitzt, ohne das Geheimnis selbst jemals zu übertragen,
    sodass ein Angreifer nichts Wiederverwendbares abfangen kann.
  </Card>

  <Card title="An Iru gebunden" icon="link">
    Ein Passkey funktioniert nur, wenn sich der Benutzer tatsächlich bei Iru anmeldet. Eine
    ähnlich aussehende Phishing-Seite kann ihn nicht auslösen, da der Passkey an
    die echte Iru-Anmeldung gebunden ist und nicht auf einen Betrüger reagiert.
  </Card>

  <Card title="Im Ruhezustand geschützt" icon="lock">
    Was Iru zur Verifizierung eines Authenticators aufbewahrt, ist bei der
    Speicherung geschützt und reicht allein niemals aus, um sich als der Benutzer auszugeben.
  </Card>

  <Card title="Von Benutzern und Administratoren verwaltet" icon="user-gear">
    Benutzer verwalten ihre eigenen Authenticators per Self-Service. Wenn jemand den Zugriff
    auf seine verliert, kann ein Administrator ihn zurücksetzen, damit der Benutzer einen
    neuen registrieren kann. Siehe [Benutzer](/de/identity/directory/users).
  </Card>
</CardGroup>

<Info>
  Welche Authenticators Benutzer registrieren dürfen und welche eine Richtlinie
  für eine bestimmte App akzeptiert, entscheiden Sie. Siehe
  [Authenticators](/de/identity/authentication/authenticators) und
  [Authentifizierungsrichtlinien](/de/identity/authentication/authentication-policies).
</Info>

## Was eine Anwendung erhält (und was sie nie sieht)

Wenn ein Benutzer über Iru eine App erreicht, erfährt die App, wer er ist, ohne
jemals zu erfahren, wie er dies nachgewiesen hat. Diese Trennung verhindert, dass sich eine einzelne gestohlene
Anmeldeinformation über Ihre Apps ausbreitet.

<CardGroup cols={2}>
  <Card title="Die App erhält" icon="circle-check">
    Eine signierte Erklärung, die bestätigt, wer der Benutzer ist, sowie die Profildetails,
    die Sie der Anmeldung dieser App zugeordnet haben. Da die Erklärung signiert ist,
    kann die App verifizieren, dass sie wirklich von Iru stammt und nicht manipuliert wurde.
  </Card>

  <Card title="Die App erhält nie" icon="circle-xmark">
    Den Passkey des Benutzers oder ein anderes Authenticator-Geheimnis. Apps besitzen nie die
    Mittel, die Identität des Benutzers nachzuweisen, sodass eine Kompromittierung einer App nicht
    gegen Iru oder Ihre anderen Apps wiederverwendet werden kann.
  </Card>
</CardGroup>

<Note>
  Sie entscheiden, welche Profilattribute mit jeder Anwendung geteilt werden, sodass eine
  App nur die Angaben sieht, die sie zur Identifizierung des Benutzers benötigt. Siehe
  [Zugriff zuweisen](/de/identity/applications/assigning-access).
</Note>

## Wie Sitzungen geschützt werden

Nach einer erfolgreichen Anmeldung richtet Iru eine Sitzung ein, damit der Benutzer nicht
bei jedem Klick erneut seine Identität nachweisen muss. Sitzungen sind so geschützt, dass sie nicht
ausgeliehen oder unbegrenzt verlängert werden können.

<AccordionGroup>
  <Accordion title="Sitzungen laufen ab" icon="clock">
    Eine Sitzung dauert nicht ewig: Sie endet nach einer Inaktivitätsphase und
    zudem nach einem Höchstalter, woraufhin sich der Benutzer anmeldet und die maßgebliche
    Richtlinie erneut ausgewertet wird. Die einer verbundenen App mitgeteilte Sitzungsdauer ist
    pro [SAML-App](/de/identity/applications/saml-applications) und
    pro [Anwendungsrolle](/de/identity/applications/roles-and-bundles) konfigurierbar.
  </Accordion>

  <Accordion title="Jede App-Anmeldung wird anhand der Richtlinie geprüft" icon="shield-halved">
    Die Anmeldung bei einer verbundenen App durchläuft die Authentifizierungsrichtlinie dieser App,
    sodass eine sensible App ein vertrauenswürdiges Gerät verlangen kann, selbst wenn der Benutzer
    bereits bei Iru angemeldet ist. (Ein Passkey oder Iru Access ist in jedem Fall für jede
    Anmeldung erforderlich.) Siehe
    [Authentifizierungsrichtlinien](/de/identity/authentication/authentication-policies)
    und [Device Trust](/de/identity/authentication/device-trust).
  </Accordion>

  <Accordion title="Sitzungen können bei Bedarf beendet werden" icon="right-from-bracket">
    Die aktiven Sitzungen eines Benutzers können beendet werden, wodurch er sich erneut anmelden muss,
    bevor er fortfahren kann. So sperren Sie den Zugriff, selbst wenn jemand
    bereits angemeldet ist.
  </Accordion>
</AccordionGroup>

## Zugriff sofort beenden

Wenn der Zugriff enden muss, müssen Sie nicht auf das Ablaufen einer Sitzung warten. Wählen Sie
die Aktion, die zur Situation passt; jede wird im
[Aktivitätsprotokoll](/de/identity/administration/activity-log) aufgezeichnet.

| Aktion | Funktion | Umkehrbar? |
| - | - | - |
| **Sitzungen beenden** | Beendet die aktiven Sitzungen des Benutzers, sodass er sich erneut anmelden muss. | Ja; er kann sich erneut anmelden, wenn er noch aktiv ist. |
| **Benutzer sperren** | Blockiert jede Anmeldung, während Datensatz und Verlauf erhalten bleiben. Bestehender Zugriff wird gekappt und neue Anmeldungen werden abgelehnt. | Ja; die Reaktivierung stellt den vorherigen Status wieder her. |
| **Zugriff auf eine App entziehen** | Widerruft eine Zuweisung; bei Apps, die Bereitstellung unterstützen, kann auch das dortige Konto entfernt werden. | Ja; durch erneute Zuweisung wiederherstellbar. |
| **Benutzer entfernen** | Löscht den Verzeichnisdatensatz vollständig. | Nein; dies kann nicht rückgängig gemacht werden. |

<Note>
  **Das Beenden einer Sitzung innerhalb einer verbundenen App hängt von der App ab.** Das Beenden von Sitzungen
  und das Sperren eines Benutzers stoppen weitere Anmeldungen **über Iru** sofort. Ob auch die
  *bestehende* Sitzung eines Benutzers innerhalb einer verbundenen App endet, hängt von dieser App
  und ihrem Protokoll ab:

  * Apps, die bei jedem Zugriff bei Iru nachfragen, lassen den Benutzer bei der nächsten
    Prüfung nicht mehr herein.
  * Bei Apps, die mit [SCIM](/de/identity/applications/provisioning) bereitgestellt werden,
    sendet das Sperren oder Aufheben der Zuweisung des Benutzers ein **Deaktivieren** (das Kennzeichen
    `active` des Kontos wird auf `false` gesetzt) oder ein **Löschen** an die App. Ob dadurch
    die aktiven Sitzungen der App sofort beendet werden, hängt davon ab, wie die App
    dieses Signal verarbeitet.
  * Manche Apps behalten eine bestehende Sitzung bis zu ihrem Ablauf bei, sofern sie keinen Sitzungswiderruf
    oder Single Logout unterstützen.

  Um jemanden so vollständig wie möglich auszusperren, **sperren Sie den Benutzer** und **beenden Sie
  seine Sitzungen**, und verlassen Sie sich auf das Deprovisioning jeder App, um nachgelagerten
  Zugriff zu entfernen.
</Note>

<Warning>
  Das Sperren eines Benutzers ist die sicherste einzelne Aktion, um jemanden überall gleichzeitig
  auszusperren: Es stoppt neue Anmeldungen, und bestehender Zugriff bleibt blockiert, bis Sie
  ihn reaktivieren. Das Entfernen eines Benutzers ist dauerhaft; sperren Sie ihn stattdessen, wenn die
  Möglichkeit besteht, dass er zurückkehrt, oder Sie seinen Verlauf benötigen. Siehe
  [Benutzer](/de/identity/directory/users).
</Warning>

<Tip>
  Wenn Sie vermuten, dass eher eine Anmeldeinformation als der Benutzer kompromittiert ist, setzen Sie die
  Authenticators des Benutzers zurück und beenden Sie seine Sitzungen. Er behält sein Konto, muss aber
  einen neuen Authenticator registrieren, bevor er sich erneut anmeldet.
</Tip>

## Wie eine kompromittierte Anmeldeinformation eingedämmt wird

Die oben genannten Elemente wirken zusammen, sodass eine gestohlene Anmeldeinformation keine Kettenreaktion auslösen kann:

1. Passkeys bieten Angreifern von vornherein nichts Wiederverwendbares, das sie per Phishing abgreifen könnten.
2. Apps erhalten nie die Mittel, die Identität nachzuweisen, sodass eine kompromittierte App nicht
   gegen Iru wiederverwendet werden kann.
3. Wenn doch etwas schiefgeht, kappt das Sperren des Benutzers und das Beenden seiner Sitzungen
   den Zugriff sofort, und jeder Schritt wird zur Überprüfung aufgezeichnet.

## Nächste Schritte

<CardGroup cols={2}>
  <Card title="Sicherheit und Datenschutz" icon="shield-halved" href="/de/identity/security/security-and-privacy">
    Die vollständige Sicherheits- und Datenschutzhaltung, ausgedrückt als klare Garantien.
  </Card>

  <Card title="Authentifikatoren" icon="fingerprint" href="/de/identity/authentication/authenticators">
    Wählen Sie, welche Authenticators Benutzer registrieren und verwenden.
  </Card>

  <Card title="Das Anmeldeerlebnis" icon="arrow-right-to-bracket" href="/de/identity/authentication/sign-in-experience">
    Was Benutzer sehen, wenn sie sich über Iru anmelden.
  </Card>

  <Card title="Benutzer" icon="user" href="/de/identity/directory/users">
    Sperren, reaktivieren, Authenticators zurücksetzen und Benutzer in Ihrem
    Verzeichnis verwalten.
  </Card>
</CardGroup>