Zum Hauptinhalt gehen

Indeavor Setup für Single Sign On mit SAML 2.0

Tara Hunt
  • Aktualisiert

Übersicht über Indeavor Single Sign On mit SAML 2.0

Dieser Artikel gibt dem Kunden eine Übersicht über die Konfiguration von Single Sign On mit SAML 2.0.

 

Übersicht über SSO

Mit der Security Assertion Markup Language (SAML) können sich Kunden bei der Anmeldung bei Indeavor ihrem eigenen System gegenüber authentifizieren.  Unsere Implementierung verwendet das SAML 2.0 Protokoll.  

SAML ist ein XML-basiertes Framework für die Authentifizierung und Autorisierung zwischen zwei Entitäten: einem Dienstanbieter und einem Identitätsanbieter. Der Dienstanbieter verpflichtet sich, dem Identitätsanbieter zu vertrauen, dass er Benutzer authentifiziert. Im Gegenzug generiert der Identitätsanbieter eine Authentifizierungs-Assertion, die angibt, dass ein Benutzer authentifiziert wurde.

SAML ist ein standardmäßiges Single Sign-On (SSO) Format. Authentifizierungsinformationen werden durch digital signierte XML-Dokumente ausgetauscht. Es handelt sich um eine komplexe Single Sign-On-(SSO)-Implementierung, die eine nahtlose Authentifizierung ermöglicht, hauptsächlich zwischen Betrieben und Unternehmen.

Identitätsanbieter (IDP)/Asserting Party: Dies ist der Kunde.  Eine gängige Implementierung ist Microsoft Active Directory Federated Services (ADFS) oder Azure.

Dienstanbieter (SP)/Vertrauende Partei: Dies ist Indeavor

mceclip1.png

Indeavor Pro Tipp:Indeavor unterstützt nur von SP initiierte Anfragen.

 

Konfiguration des Identitätsanbieters

Der Kunde benötigt unsere Dienstanbieter-Metadaten, um Indeavor als Relying Party in seinem IDP hinzuzufügen. 

Ein Identitätsanbieter ist eine Systementität, die Identitätsinformationen für Auftraggeber erstellt, pflegt und verwaltet, während sie für Relying Party-Anwendungen innerhalb eines Verbandes oder verteilten Netzwerks Authentifizierungsdienste bereitstellt.

Ein Identitätsanbieter bietet Benutzerauthentifizierung als Service an. Relying Party-Anwendungen wie Webanwendungen beauftragen einen vertrauenswürdigen Identitätsanbieter mit dem Benutzerauthentifizierungs-Schritt. Eine solche Relying Party-Anwendung wird als föderiert bezeichnet, d. h. sie nutzt föderierte Identitätsdaten.

Ein Identitätsanbieter ist „ein vertrauenswürdiger Anbieter, mit dem Sie Single Sign-On (SSO) für den Zugriff auf andere Websites nutzen können.“ SSO verbessert die Benutzerfreundlichkeit, indem Passwortermüdung verringert wird. Darüber hinaus bietet sie eine bessere Sicherheit, da sie die potenzielle Angriffsfläche verringert.

Insbesondere ist ein SAML-Identitätsanbieter eine Systementität, die Authentifizierungs-Assertions in Verbindung mit einem SSO-Profil der SAML ausgibt. Eine Relying Party, die diese Authentifizierungs-Assertions verwendet, wird als SAML-Dienstanbieter bezeichnet.[1]

[1] https://en.wikipedia.org/wiki/Identity_provider

  

Metadaten können durch eine URL aus Indeavor abgerufen werden:

https://identity.[UMGEBUNGSNAME].indeavor.com/saml/metadata.xml

 

Empfohlene Best Practices

  • SHA-256-Algorithmus
  • Die Indeavor SSO erfordert, dass das von ADFS bereitgestellte eindeutige Identifikationsfeld im Attribute Statement-Block der Antwort enthalten ist.  Für die meisten Kunden ist die Verwendung der E-Mail-Adresse die beste eindeutige Kennung, um dieses Ergebnis zu erzielen.
  • Der Parameter „Relay State“, der von Indeavor mit der SAML-Authentifizierungsanfrage gesendet wurde, muss in die SAML-Antwort des Federation Service, die an Indeavor zurückgeht, enthalten sein.

 

Indeavor-Konfiguration (des Dienstanbieters)

 Ein SAML-Dienstanbieter ist eine Systementität, die Authentifizierungs-Assertions in Verbindung mit einem SSO-Profil der Security Assertion Markup Language (SAML) empfängt und akzeptiert.

Im SAML-Domänenmodell ist eine SAML Relying Party jede Systementität, die Informationen von einer anderen Systementität empfängt und annimmt. Von besonderem Interesse ist eine SAML Relying Party, die eine SAML-Assertion einer SAML-Autorität erhält und akzeptiert.

Ein wichtiger Typ der SAML-Autorität ist der SAML-Identitätsanbieter, eine Systementität, die Authentifizierungs-Assertions in Verbindung mit einem SSO-Profil der SAML ausgibt. Eine Relying Party, die solche Assertions verwendet, wird als SAML-Dienstanbieter (oder einfach als Dienstanbieter, wenn die Domäne klar ist) bezeichnet. Somit ist ein SAML-Dienstanbieter eine Systementität, die eine von einem SAML-Identitätsanbieter ausgestellte Authentifizierungs-Assertion erhält und akzeptiert.[1]

[1] https://en.wikipedia.org/wiki/Service_provider_(SAML)

 

Assertion

Eine SAML-Assertion enthält ein Paket mit Sicherheitsinformationen

SAML-Assertions werden in der Regel von Identitätsanbietern an Dienstanbieter übertragen. Assertions enthalten Erklärungen, die Dienstanbieter verwenden, um Entscheidungen über die Zugangskontrolle zu treffen. SAML stellt drei Arten von Erklärungen bereit:

  • Authentifizierungserklärungen
  • Attributerklärungen
  • Erklärungen zur Autorisierungsentscheidungen

Authentifizierungsanweisungen erklären dem Dienstanbieter, dass sich der Auftraggeber tatsächlich zu einem bestimmten Zeitpunkt mit einer bestimmte Authentifizierungsmethode beim Identitätsanbieter authentifiziert hat. Die Authentifizierungsaussage kann noch andere Informationen über den authentifizierten Auftraggeber (den sogenannten Authentifizierungskontext) enthalten.

Eine Attributaussage bestätigt, dass ein Subjekt mit bestimmten Attributen verbunden ist. Ein Attribut ist einfach ein Namenswert-Paar. Relying Partys nutzen Attribute, um Entscheidungen über die Zugangskontrolle zu treffen.

Eine Autorisierungentscheidungs-Aussage besagt, dass einem Subjekt gestattet wird, die Maßnahme A auf Ressource R aufgrund des Belegs B durchzuführen. Die Aussagekraft von Autorisierungentscheidungsaussage in SAML ist absichtlich begrenzt.[1]

 

Protokoll

Ein SAML-Protokoll beschreibt, wie bestimmte SAML-Elemente (einschließlich Assertions) innerhalb von SAML-Anfrage- und -Antwortelementen verpackt werden, und gibt die Verarbeitungsregeln an, die SAML-Entitäten bei der Erstellung oder Verwendung dieser Elemente beachten müssen. Ein SAML-Protokoll ist größtenteils ein einfaches Request-Response-Protokoll.

Die folgenden Protokolle werden im SAML 2.0 Core ausführlich beschrieben:

  • Assertion Query und Request Protocol
  • Authentication Request Protocol
  • Artifact Resolution Protocol
  • Name Identifier Management Protocol
  • Single Logout Protocol
  • Name Identifier Mapping Protocol[2]

 

Bindung

Eine SAML-Bindung ist die Zuordnung einer SAML-Protokollmitteilung zu Standard-Nachrichtenformaten und/oder Kommunikationsprotokollen. Beispielsweise gibt die SAML-SOAP-Bindung an, wie eine SAML-Nachricht in einen SOAP-Umschlag eingekapselt wird, der selbst an eine HTTP-Nachricht gebunden ist.

Die folgenden Bindungen werden in SAML beschrieben:

  • SAML SOAP Bindung (auf Grundlage von SOAP 1.1)
  • Reverse SOAP (PAOS) Bindung
  • HTTP Redirect (GET) Bindung
  • HTTP POST Bindung
  • HTTP Artifact Bindung
  • SAML URI Bindung

 

Profil

In einem SAML-Profil wird ausführlich beschrieben, wie SAML-Assertions, -Protokolle und -Bindungen kombiniert werden, um einen definierten Anwendungsfall zu unterstützen. Das wichtigste SAML-Profil ist das SSO-Profil des Webbrowsers.

Die folgenden Protokolle werden in SAML beschrieben:

  • SSO-Profile
    • SSO-Profil des Webbrowsers
    • Enhanced Client or Proxy (ECP) Profil
    • Identity Provider Discovery Profil
    • Single Logout Profil
    • Name Identifier Management Profil
  • Artifact Resolution Profil
  • Assertion Query/Request Profil
  • Name Identifier Mapping Profil
  • SAML Attribute Profile

 

Was wir verwenden

Für den Anmeldearbeitsablauf verwenden wir das „Web Browser SSO Profil“, die Bindung, die unterstützt wird, ist „HTTP Redirect (GET) Binding“ (mobil), „HTTP POST Binding“ (Web).

Für den Logout-Arbeitsablauf verwenden wir das „Single Logout Profil“, die unterstützte Bindung lautet „HTTP Redirect (GET) Binding“, „HTTP POST Binding“.
[1] https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

[2] https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

 

Metadaten

SAML-Metadaten sind Konfigurationsdaten, die erforderlich sind, um automatisch Vereinbarungen zwischen Systementitäten zu verhandeln, die Identifikatoren, Bindungsunterstützung und -endpunkte, Zertifikate, Schlüssel, kryptographische Fähigkeiten sowie Sicherheits- und Datenschutzrichtlinien umfassen. Mehrere SAML-Spezifikationen standardisieren Metadatenstrukturen und -inhalte und unterstützen so effiziente Verwaltungsprozesse für verkäufliche Bereitstellungen.

Da sich die SAML-Spezifikationen im Laufe der Zeit weiterentwickelt haben, sind Metadaten-bezogene Spezifikationen in mehreren Dokumenten enthalten. Dieses nicht normative Dokument bietet eine konsolidierte Übersicht und Links zu den normativen Spezifikationen.[1]

[1] https://www.oasis-open.org/committees/download.php/51890/SAML%20MD%20simplified%20overview.pdf

 SSO muss in Indeavor aktiviert werden, damit die Metadaten-Endpunkte verfügbar sind.

 

ADFS-Konfigurationen 

Endpunkte

Indeavor Pro Tipp:In Ihrer Domäne muss SSO aktiviert werden, damit Metadaten-Links verfügbar sind.

Web

Metadaten und Endpunkte

URL:  https://identity.[UMGEBUNGSNAME].indeavor.com/saml/metadata.xml

Beschreibung: Gibt die Metadaten des Dienstanbieters zurück (siehe SAML-Beschreibung/Metadaten). Wenn der SAML-Anbieter für die angeforderte Domäne nicht aktiviert ist, gibt der Endpunkt 404 zurück. 

 

Assertion Consumer Handler

Beschreibung: Der Endpunkt, der Assertion-Antworten von Dienstanbietern entgegennimmt. Implementiert die Validierung der betreffenden Assertion, extrahiert den Benutzernamen aus dem konfigurierten Attribut und meldet den Benutzer an, wenn er ein gültiger Indeavor-Benutzer ist.

Single Logout Service

Beschreibung: Der Endpunkt, der Abmeldeanfragen/-antworten vom Dienstanbieter akzeptiert. Implementiert die Validierung der gegebenen Anforderungen/Antworten und loggt den Indeavor-Benutzer aus.

SAML Anmeldeseite

Beschreibung: Die Seite, die den Anmeldenamen durch den SAML-Identitätsanbieter implementiert. Der Benutzer nimmt die Domäneneingabe vor, die App findet den richtigen Dienstanbieter, erstellt eine Authentifizierungsanfrage und leitet den Benutzer zum SingleSignOnService des Identitätsanbieters um.

 

 

Indeavor-Konfigurationen

Fügen Sie das Indeavor-Zertifikat zur Verschlüsselung/Signierung der SAML-Anforderungen hinzu

  • Erstellen Sie eine Datei, die das SAML-Zertifikat enthält. Diese Datei sollte von der Anwendung aus zugänglich sein
  • Fügen Sie den Pfad der Datei zu Data/Config/SamlSSO.config <samlSSOSettings certificate="certificate path" password="Dateikennwort" /> hinzu

Führen Sie die Anwendung unter der sicheren Verbindung (HTTPS) aus. SAML-Anbieter erfordert HTTPS

 

Einrichten von Metadaten und UID-Mustern auf Systemebene

 

https://support.workloud.com/hc/en-us/articles/115001794466

 

 

Erstellen eines Benutzerprofils für Single Sign-On

https://support.workloud.com/hc/en-us/articles/115001796366

 

 

Was zu erwarten ist

 

XML

Metadaten des Identitätsanbieters

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://idp.cloudroll.gr">
    <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor use="signing">
            ...
        </md:KeyDescriptor>
        <md:KeyDescriptor use="encryption">
            ...
        </md:KeyDescriptor>
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.cloudroll.gr/idp/SingleLogoutService" index="0" isDefault="false"/>
        <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.cloudroll.gr/idp/SSOService" index="0" isDefault="false"/>
    </md:IDPSSODescriptor>
    </md:EntityDescriptor>

 

entityID: Eindeutige Kennung des Identitätsanbieters.

IDPSSODescriptor: Enthält IdP-Informationen.

KeyDescriptor: Schlüssel, der von einer Entität für die Signierung und Verschlüsselung von Antworten verwendet wird.

NameIDFormat: Das Format der eindeutigen Benutzerkennung.

SingleSignOnService: Die URL, die SSO verwendete.

SingleLogoutService: Die URL, die SLO verwendete.

Ort: Die URL der Bindung.

Bindung: Der Typ der Bindungsantwort.

Index: Der Index der Bindung.

isDefault: Wenn es sich um den Standardbindungsdienst für diesen Prozess handelt

 

 

Metadaten des Dienstanbieters

<md:EntityDescriptor entityID="https://sp.cloudroll.gr" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui">
    <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor use="signing">
            ...        
        </md:KeyDescriptor>
        <md:KeyDescriptor use="encryption">
            ...        
        </md:KeyDescriptor>
        <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://sp.cloudroll.gr/Artifact/SOAP" index="1"   isDefault="false"/>
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://sp.cloudroll.gr/SLO/SOAP" />
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.cloudroll.gr/SLO/POST" />
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.cloudroll.gr/SAML2/POST" index="1" />
    </md:SPSSODescriptor>
</md:EntityDescriptor>

 

entityID: Eindeutige Kennung des Identitätsanbieters.

SPSSODescriptor: Enthält SP-Informationen.

KeyDescriptor: Schlüssel, der von einer Entität für die Signierung und Verschlüsselung von Antworten verwendet wird.

NameIDFormat: Das Format der eindeutigen Benutzerkennung.

SingleSignOnService: Die URL, die SSO verwendete.

SingleLogoutService: Die URL, die SLO verwendete.

Ort: Die URL der Bindung.

Bindung: Der Typ der Bindungsantwort.

Index: Der Index der Bindung.

isDefault: Wenn es sich um den Standardbindungsdienst für diesen Prozess handelt

 

 

Authentifizierungsanforderung

<samlp:AuthnRequest
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="…"
    Version="2.0"
    IssueInstant="2015-01-31T06:00:00"
    AssertionConsumerServiceIndex="0"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
                <saml:Issuer>www.workloud.com</saml:Issuer>
                <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
</samlp:AuthnRequest>

 

ID: Die Kennung der Authentifizierungsanfrage.

Issuer: Kennung der Ausstellers (SP).

Signature: Die Signatur des Ausstellers zur Überprüfung der Gültigkeit der Anfrage, wenn die XML unterzeichnet ist.

AssertionConsumerServiceIndex: Die URL, an die der IDP nach der Benutzeridentifizierung die Assertion zurückgibt.

AssertionConsumerServiceURL: Die URL, an die der IDP nach der Benutzeridentifizierung die Assertion zurückgibt.

ProtocolBinding: Der Typ der Antwort, die die Assertion zurückgeben soll.

 

 

Assertion

Hier ist ein Beispiel für eine Assertion

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" IssueInstant="2015-01-31T12:00:00Z">
    <saml:Issuer>www.workloud.com</saml:Issuer>                                                           <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <saml:Subject>
        <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> cloudroll@example.com</saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="2015-01-31T12:00:00Z" NotOnOrAfter="2015-01-31T12:00:00Z"> </saml:Conditions>
    <saml:AuthnStatement
     AuthnInstant="2004-12-05T09:22:00"
     SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac">
        <saml:AuthnContext>
            <saml:AuthnContextClassRef>
         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
            </saml:AuthnContextClassRef>
        </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
        <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName="eduPersonAffiliation">
            <saml:AttributeValue>admin</saml:AttributeValue>
        </saml:Attribute>                                                                                  </saml:AttributeStatement>
</saml:Assertion>

 

Die Assertion beinhaltet:

Issuer: Kennung der Ausstellers (Idp).

Signature: Die Signatur des Ausstellers zur Überprüfung der Gültigkeit der Anfrage, wenn die XML unterzeichnet ist.

Subject: Die Benutzerkennung.

AuthnStatement: Die Aussage, die die Identität des Benutzers beschreibt.

Conditions: Beschreibt die Bedingungen, unter denen die Assertion gültig ist.

AuthnInstant: Der Moment, in dem die Assertion ausgestellt wurde.

SessionIndex: Der Sitzungsindex, mit dem der Benutzer durch den IdP identifiziert wird.

AuthnContext: Der Authentifizierungskontext, der vom IdP zur Identifizierung des Benutzers verwendet wird

AttributeStatement: Enthält die Benutzerattribute

Name: Der Name des Attributs.

FriendlyName: Der freundliche Name des Attributs.

 

 

LogoutRequest

<samlp:LogoutRequest
        xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        ID="..."
        Version="2.0" IssueInstant="2014-07-18T01:13:06Z"
        Destination="www.workloud.com/SingleLogoutService">
    <saml:Issuer>www.workloud. com </saml:Issuer>
    <saml:NameID SPNameQualifier="www.workloud. com " Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">......</saml:NameID>
</samlp:LogoutRequest>

ID: Die Kennung der Authentifizierungsanfrage.

Issuer: Kennung der Ausstellers (SP).

Signature: Die Signatur des Ausstellers zur Überprüfung der Gültigkeit der Anfrage, wenn die XML unterzeichnet ist.

IssueInstant: Der Zeitpunkt, zu dem die Antwort auf die Abmeldung ausgestellt wurde.

Destination: Der Webdienst, der die Anfrage verarbeitet.

InResponseTo: Die Kennung der Anfrage, zu der die Antwort gehört.

NameID:  Die Benutzerkennung, zu der die Anfrage gehört.

 

 

LogoutResponse

<samlp:LogoutResponse
        xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        ID="...."
        Version="2.0"
        IssueInstant="2014-07-18T01:13:06Z"
        Destination="www.workloud.gr/SingleLogoutService"
        InResponseTo="...">
    <saml:Issuer>www.workloud.gr</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
</samlp:LogoutResponse>

 

ID: Die Kennung der Authentifizierungsanfrage.

Issuer: Kennung der Ausstellers (SP).

Signature: Die Signatur des Ausstellers zur Überprüfung der Gültigkeit der Anfrage, wenn die XML unterzeichnet ist.

IssueInstant: Der Zeitpunkt, zu dem die Antwort auf die Abmeldung ausgestellt wurde.

Destination: Der Webdienst, der die Antwort verarbeitet.

InResponseTo: Die Kennung der Anfrage, zu der die Antwort gehört.

Status: Der Status der Antwort.

 

Web-Anmeldungs-Arbeitsablauf

  • Gehen Sie zur SAML-Anmeldeseite
  • Wählen Sie die Domäne aus, und drücken Sie auf Anmelden
  • Die Anwendung erstellt ein Formular für die automatische Übermittlung, das diese Parameter enthält
    1. RelayState ist ein Parameter, der an den IDP übergeben wird und der unverändert an unseren SP zurückgegeben werden sollte; dieser Parameter behält den Domänennamen, der von unserem SP benötigt wird.
      Beispiel für RelayState-Wert: url=/Default.aspx&dmn=demo
    2. SAMLRequest enthält die AuthnRequest Base-64 codiert. Dieser Wert enthält Informationen über den Aussteller der Anfrage
  • Der Benutzer wurde an den Dienstanbieter weitergeleitet
  • Der Anbieter validiert die Authentifizierungsanfrage
  • Fordert den Benutzer zur Anmeldung auf
  • Der Identitätsanbieter gibt eine Assertion mit den Benutzerinformationen aus
  • Der Benutzer wurde mit der SAMLResponse und der RelayState-Anforderung der SAML auf den Indeavor Assertion Consumer-Handler umgeleitet
  • Assertion Consumer Handler validiert die Anfrage (Signatur, abgelaufen usw.)
  • Extrahiert den UserName für die Assertions-Attribute
  • Benutzeranmeldungen

Arbeitsablauf für die mobile Anmeldung

  • Benutzer geht zur Anmeldungsansicht
  • Wählen Sie die Domäne aus, und drücken Sie auf Anmelden
  • Die Anwendung erstellt eine URL, die diese Parameter enthält
    1. RelayState ist ein Parameter, der an den IDP übergeben wird und der unverändert an unseren SP zurückgegeben werden sollte; dieser Parameter behält den Domänennamen, der von unserem SP benötigt wird.
      Beispiel für RelayState-Wert: url=/Default.aspx&dmn=demo
    2. SAMLRequest enthält die AuthnRequest Base-64 codiert. Dieser Wert enthält Informationen über den Aussteller der Anfrage
  • Die mobile App öffnet eine Webansicht mit der generierten URL
  • Der Benutzer wurde an den Dienstanbieter weitergeleitet
  • Der Anbieter validiert die Authentifizierungsanfrage
  • Fordert den Benutzer zur Anmeldung auf
  • Der Identitätsanbieter gibt eine Assertion mit den Benutzerinformationen aus
  • Der Benutzer wurde mit der SAMLResponse und der RelayState-Anforderung der SAML auf den Indeavor Assertion Consumer-Handler umgeleitet
  • Assertion Consumer Handler validiert die Anfrage (Signatur, abgelaufen usw.)
  • Extrahiert den UserName für die Assertions-Attribute
  • Benutzeranmeldungen

 

Verwandte Beiträge