> ## 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. # SAML-Anwendungen > Referenz für die Einstellungen von SAML-Anwendungen in Iru Identity: Anbieterdetails, Verarbeitung von Anfragen und Antworten, Signierung, Attributzuordnung und Sitzungsdauer. Mit einer **SAML-Anwendung** können sich Benutzer bei einem Dienst anmelden, der SAML-Single-Sign-On unterstützt, wobei Iru als **Identitätsanbieter (IdP)** fungiert. Iru stellt dem Dienst die erforderlichen Anbieterdetails bereit, signiert die Antwort und die Assertion, die es sendet, und ordnet die Profilattribute Ihrer Benutzer in diese Assertion ein. Sie bearbeiten die Konfiguration einer SAML-App in einem **Entwurf** und legen diesen dann als current-Version fest. Das Versionsmodell finden Sie unter [Übersicht über Anwendungen](/de/identity/applications/applications-overview). Nachfolgend finden Sie eine feldweise Referenz für jede Einstellung, gruppiert genau so, wie der Editor sie darstellt. Die meisten Dienste benötigen nur einige dieser Einstellungen, typischerweise die ACS-URL, die Service Provider Entity ID und die Zuordnung. Die Standardwerte sind so gewählt, dass sie mit gängigen Service Providern funktionieren; ändern Sie die übrigen nur, wenn die Dokumentation Ihres Dienstes dies verlangt. ## Protokolldetails: was Iru dem Service Provider bereitstellt Öffnen Sie die **Protocol details** der Anwendung, um die Werte zu kopieren, die Ihr Service Provider benötigt, um Iru zu vertrauen. Diese werden von Iru generiert. | Detail | Bedeutung | | - | - | | **Metadata URL** | Ein einzelnes Dokument, das die SAML-Einstellungen von Iru für diese App beschreibt. Viele Dienste konfigurieren alles über diese URL; Sie können die Metadatendatei auch anzeigen oder herunterladen. | | **IdP Entity ID** | Die Kennung von Iru als Identitätsanbieter für diese App. | | **Single Sign On Service** | Die URL, an die der Service Provider Authentifizierungsanfragen sendet (und an der die IdP-initiierte Anmeldung beginnt). | | **IdP Signing Certificate** | Das Zertifikat, mit dem der Dienst überprüft, dass eine Antwort tatsächlich von Iru stammt. Betreff, Ablaufdatum und Fingerabdruck werden angezeigt, und Sie können es kopieren oder herunterladen. | Wenn der Dienst Metadaten importieren kann, verweisen Sie ihn auf die **Metadata URL** (oder laden Sie die heruntergeladene Datei hoch). Sie enthält Entity-ID, Anmelde-URL und Signatur- zertifikat zusammen, sodass weniger manuell eingegeben werden muss. ## Anbieterdetails: was Sie Iru über den Dienst mitteilen | Einstellung | Funktion | | - | - | | **ACS URL** | Die Assertion Consumer Service-URL, das Ziel, an das Iru die SAML-Antwort sendet. Erforderlich; muss eine gültige `https`-URL sein. | | **Service Provider Entity ID** | Die eigene Kennung des Service Providers. Iru verwendet sie als Standard-Audience und (optional) zur Validierung des Ausstellers der Anfrage. | | **Unsolicited authentication** | Ob der Dienst die **IdP-initiierte** Anmeldung unterstützt (der Benutzer startet bei Iru). Setzen Sie **Supported**, wenn der Dienst eine nicht angeforderte Antwort akzeptiert; andernfalls **Unsupported**. | | **Alternative authentication URL** | Wird angezeigt, wenn Unsolicited authentication auf **Unsupported** steht: die URL, an die Iru Benutzer sendet, damit der Dienst die Anmeldung selbst starten kann (vom Service Provider initiiert). | Diese Einstellungen regeln den **AuthnRequest**, den ein Service Provider sendet, um die Anmeldung zu starten. ### Validate issuer Wie streng Iru den **Issuer** in einer eingehenden Anfrage prüft. | Option | Funktion | | - | - | | **Must match Service Provider Entity ID** | Der Aussteller der Anfrage muss der oben eingegebenen Service Provider Entity ID entsprechen. | | **Must match custom value** | Der Aussteller muss einem von Ihnen angegebenen **Custom value** entsprechen (verwenden Sie dies, wenn sich der Aussteller des Dienstes von seiner Entity-ID unterscheidet). | | **Ignore** | Den Aussteller nicht validieren. | ### Authentication request restriction Steuert, **ob die Anfrage signiert sein muss** und **an welche ACS-URL** Iru antwortet. "Follow" verwendet die ACS-URL aus der Anfrage; "pinned" verwendet immer die in den **Provider details** konfigurierte ACS-URL. | Option | Muss die Anfrage signiert sein? | Antwort wird gesendet an | | - | - | - | | **Any request and follow** | Nein | Die ACS-URL in der Anfrage | | **Any request and pinned** | Nein | Die konfigurierte ACS-URL | | **Signed request and follow** | Ja | Die ACS-URL in der Anfrage | | **Signed request and pinned** | Ja | Die konfigurierte ACS-URL | **Pinned** ist die sicherere Wahl: Es ignoriert jede in der Anfrage angegebene ACS-URL, sodass eine manipulierte Anfrage eine Antwort nicht umleiten kann. Bevorzugen Sie **Signed request and pinned**, wenn der Dienst das Signieren seiner Anfragen unterstützt. Wenn Sie eine Option **Signed request** wählen, legen Sie außerdem fest, wie Iru diese Signatur überprüft: | Einstellung | Funktion | | - | - | | **Allowed signing algorithms** | Die Signaturalgorithmen für Anfragen, die Iru akzeptiert: beliebige aus `RSA-SHA1`, `RSA-SHA256`, `RSA-SHA384`, `RSA-SHA512`. Wählen Sie diejenigen, die Ihr Dienst verwendet; vermeiden Sie `RSA-SHA1`, sofern nicht erforderlich. | | **Allowed digest algorithms** | Die Digest-Algorithmen für Anfragen, die Iru akzeptiert: beliebige aus `SHA1`, `SHA256`, `SHA384`, `SHA512`. | | **Signing Certificate** | Das Zertifikat, mit dem Iru die signierten Anfragen des Dienstes überprüft. Laden Sie das Zertifikat zur Anfragesignierung des Service Providers hoch. | ### Zustellung und Kennungen | Einstellung | Funktion | | - | - | | **HTTP Method** | Wie die SAML-Antwort zugestellt wird: **HTTP-POST** (ein automatisch absendendes Formular, die übliche Wahl) oder **HTTP-REDIRECT**. | | **IdP Entity ID** | Der Aussteller, den Iru in der Antwort angibt. Belassen Sie **Use default** (in den Protocol details angezeigt) oder wählen Sie **Specify custom**, um eine andere **Custom IdP Entity ID** anzugeben. | | **Audience** | Für wen die Assertion bestimmt ist. **Use default** sendet die Service Provider Entity ID; wählen Sie **Specify custom**, um eine andere **Custom Audience** zu senden. | | **Recipient** | Der in der Assertion angegebene Empfänger. **Use default** verwendet die ACS-URL (das Ziel); wählen Sie **Specify custom**, um einen anderen **Custom Recipient** zu senden. | | **Fallback relay value** | Der RelayState, den Iru verwendet, wenn der Dienst keinen angegeben hat, typischerweise die Stelle, an der der Benutzer in der App landen soll. | | **Error action** | Was passiert, wenn eine Anmeldung nicht abgeschlossen werden kann: **Iru** zeigt eine Iru-Fehlerseite an, oder **Protocol** gibt den Fehler zur Behandlung an den Service Provider zurück. | ### Signierung | Einstellung | Funktion | | - | - | | **Signing method** | Welche Teile der Nachricht Iru signiert: **Response**, **Assertion** oder **Both - Response and Assertion**. Richten Sie sich nach den Anforderungen des Dienstes. | | **Signing algorithm** | Der Signaturalgorithmus, mit dem Iru signiert: `RSA-SHA1`, `RSA-SHA256`, `RSA-SHA384` oder `RSA-SHA512`. `RSA-SHA256` eignet sich für die meisten Dienste. | | **Digest algorithm** | Der in der Signatur verwendete Digest-Algorithmus: `SHA1`, `SHA256`, `SHA384` oder `SHA512`. | Iru signiert mit seinem eigenen **IdP Signing Certificate** (dem in den Protocol details angezeigten), daher muss hier kein Signaturzertifikat hochgeladen werden. ### Assertions verschlüsseln | Einstellung | Funktion | | - | - | | **Encrypt assertions** | **Unencrypted** (Standard) oder **Encrypted**. Aktivieren Sie dies nur, wenn der Dienst verschlüsselte Assertions erfordert. | | **Use the Request signing certificate** | Verwendet beim Verschlüsseln das Zertifikat zur Anfragesignierung des Dienstes als Verschlüsselungszertifikat, statt ein separates hochzuladen. (Erfordert ein im Abschnitt **Request** konfiguriertes Signaturzertifikat.) | | **Encryption Certificate** | Das Zertifikat des Service Providers, für das Iru die Assertion verschlüsselt, wenn Sie das Zertifikat zur Anfragesignierung nicht wiederverwenden. | | **Encryption algorithm** | Der Algorithmus zur Inhaltsverschlüsselung: `AES-128-GCM`, `AES-192-GCM`, `AES-256-GCM`, `AES-128-CBC`, `AES-192-CBC` oder `AES-256-CBC`. Verwenden Sie, was der Dienst erwartet (eine GCM-Option ist ein guter Standard). | | **Key transport algorithm** | Wie der Verschlüsselungsschlüssel geschützt wird: `RSA-OAEP` oder `RSA-PKCS1-v1.5`. | ### Erweitert | Einstellung | Funktion | | - | - | | **Use namespace prefixes** | Fügt der Antwort explizite XML-Namespace-Präfixe (`saml2p`, `saml2`, `ds`, `xenc`) hinzu. Aktivieren Sie dies, wenn der SAML-Parser des Dienstes Elemente mit Präfix erfordert. | Öffnen Sie die **Zuordnung** der Anwendung, um die Identität in der Assertion zu steuern. Sie besteht aus zwei Teilen: dem **Betreff** (der NameID) und allen zusätzlichen **Attributen**. ### Subject (NameID) Das Subject ist die primäre Kennung des angemeldeten Benutzers. Standardmäßig wird es aus dem `user.username` des Benutzers gebildet; Sie können den Wert ändern, aus dem es gebildet wird, und ein **NameID-Format** wählen: | NameID-Format | Verwenden, wenn der Dienst Folgendes erwartet … | | - | - | | **E-Mail** | Eine E-Mail-Adresse als Kennung. | | **Persistent** | Eine stabile, undurchsichtige Kennung, die über Sitzungen hinweg gleich bleibt. | | **Transient** | Eine temporäre Kennung, die sich bei jeder Sitzung ändern kann. | | **Unspecified** | Kein bestimmtes Format. | ### Attribute Fügen Sie jedes Attribut hinzu, das der Dienst in der Assertion benötigt. Für jedes Attribut legen Sie fest: * Einen **Namen:** den Attributnamen, den der Service Provider erwartet. * Einen **Wert:** das Profilattribut oder den Ausdruck, aus dem er gebildet wird (zum Beispiel `user.email` oder eine Kombination von Feldern). * Ein **Attributnamensformat:** **Unspecified**, **URI** oder **Basic**. * Ob es **aktiviert** ist. Eine Live-**Vorschau** zeigt die Assertion, die erzeugt wird, sodass Sie ihre Struktur vor der Veröffentlichung bestätigen können. `Subject` ist als NameID reserviert und kann nicht als Name eines benutzerdefinierten Attributs wiederverwendet werden. Die Standard-Sitzungsdauer beträgt **60 Minuten** in der Assertion der SAML-App oder im OIDC- Token. Die Sitzungsdauer der zutreffenden Rolle überschreibt diesen Wert. Setzen Sie in der Rolle die Sitzungsdauer auf **0**, um stattdessen den Anwendungsstandard zu verwenden. Siehe [Rollen und Rollen-Bundles](/de/identity/applications/roles-and-bundles). | Einstellung | Funktion | | - | - | | **Session Length Supported** | **Supported** füllt das `notOnOrAfter` der Assertion (Sitzungsablauf) anhand der unten angegebenen Dauer; **Unsupported** lässt es weg. | | **Default session length (minutes)** | Der in die Assertion geschriebene Anwendungsstandard. Standardwert **60**. Gültig sind in der App **10** bis **2880** Minuten. | ## Zertifikate im Überblick Eine SAML-App umfasst bis zu drei Zertifikate: Iru signiert die Antwort und/oder die Assertion mit seinem eigenen Zertifikat, das in den **Protocol details** angezeigt wird. Der Dienst verwendet es, um zu bestätigen, dass die Nachricht von Iru stammt und nicht verändert wurde. Es muss nichts hochgeladen werden. Laden Sie das Zertifikat des Service Providers hoch, damit Iru die **signierten Authentifizierungsanfragen** überprüfen kann, die dieser sendet. Wird im Abschnitt **Request** konfiguriert und ist nur erforderlich, wenn Sie signierte Anfragen verlangen. Das Zertifikat des Service Providers, für das Iru **die Assertion verschlüsselt**; wird nur verwendet, wenn **Encrypt assertions** aktiviert ist. Sie können das Zertifikat zur Anfragesignierung wiederverwenden, statt ein separates hochzuladen. ## Veröffentlichen, zuweisen und aktivieren Veröffentlichen Sie Ihren Entwurf, damit er zur Live-Konfiguration wird. Weisen Sie die Gruppen zu, die die App erhalten sollen. Siehe [Zugriff zuweisen](/de/identity/applications/assigning-access). Aktivieren Sie die App, damit sich zugewiesene Benutzer anmelden können. Melden Sie sich als Testbenutzer über das App-Dashboard an, um die Erfahrung zu überprüfen, und verwenden Sie die **Vorschau** der Zuordnung, um die Assertion zu prüfen. ## Nächste Schritte Die App Benutzern und Gruppen zuweisen und App-Rollen gestalten. Konten in der App automatisch erstellen und entfernen, wenn sich der Zugriff ändert. Eine App konfigurieren, die OpenID Connect statt SAML verwendet. Protokolle und das Versionsmodell vom Entwurf zur current-Version überprüfen.