SecSign ID Plugin: Shibboleth IDP

Der Ablauf für die SecSign ID 2FA mit dem Shibboleth Identity Provider v3.3.x.:

1. Der Nutzer greift auf eine geschützte Anwendung über einen Service Provider zu
2. Die Verbindung wird durch die Anwendung oder den Service initiiert. Der Shibboleth IDP zeigt die Anmeldung mit Nutzernamen und Passwort
3. Primäre Authentifizierung, in der Regel über Active Directory. Der LDAP Server sendet den Authentifizierungskontext mit der SecSign ID des Nutzers an den Shibboleth IDP
4. Die Sekundäre Authentifizierung wird initiiert. Der SecSign ID Authentifizierungsserver kann hier Inhouse oder in der Cloud betrieben werden
5. Eine neue Authentifizierungssession wird erstellt und dem Nutzer wird das Zugangssymbol im Browser angezeigt.
6. Der Nutzer erhält eine Notifikation auf sein Smartphone, dass eine Authentifizierungssession begonnen wurde. Der Nutzer loggt sich in der App mit einem PIN Code, Fingerabdruck, oder FaceID ein, erhält die Informationen zur Authentifizierungssession und muss das entsprechende Zugangssymbol auswählen/bestätigen.
7. Shibboleth IDP erhält die Rückmeldung zur Authentifizierung
8. Der Nutzer ist in der Anwendung oder dem Service eingeloggt

Der SecSign ID Ablauf ist so gestaltet, dass er sich perfekt auf bestehende Loginabläufe anpassen kann, üblicherweise ein MFA Loginablauf. Der erste Loginablauf ist generell eine reguläre Passwortabfrage über einen LDAP Server. Dafür müssen die Nutzer in Ihrem AD Nutzeraccount das SecSign ID Attribut zugewiesen bekommen.
Nach dem Passwortlogin ist die SecSign ID des Nutzers im Authentifizierungskontext und kann für die 2FA genutzt werden.

• Shibboleth Identity Provider 3.3.x
• Java 8
• LDAP Server mit SecSignID als Attribut in den Nutzerprofilen

Bitte kontaktieren Sie uns, wenn Sie Ihre Active Directory Nutzerprofile nicht modifizieren wollen. Mit dem SecSign ID Inhouse Server können Sie ID-Nutzernamen Mapping ohne Änderungen im AD vornehmen. Auch das Mapping via Textdatei ist möglich, aber nicht empfohlen.

Wenn sich Ihre Nutzer einloggen, authentifizieren sie sich generell erst mit ihrem Nutzernamen und Passwort. Danach wird der zweite Faktor angefragt. Wie funktioniert also das Mapping von Nutzernamen und SecSign ID?

Sie haben mehrere Möglichkeiten, die SecSign ID einem Nutzer zuzuordnen:

• Die einfachste Option ist der SecSign ID Inhouse Server, der das komplette Mapping übernimmt. Die Shibboleth Nutzernamen werden in einer internen Datenbank gespeichert und die 2FA wird auf dem Server absolviert. Sie behalten die vollste Kontrolle über Nutzerdaten, Registrierung und ID-Namen.
• Wenn Sie die erweiterten Funktionen des SecSign ID Inhouse Servers nicht benötigen können Sie die Attribute auch einfach Ihren Nutzerprofilen im Active Directory hinzufügen. Mehr Informationen zum AD Mapping finden Sie hier.
  Wenn Sie die SecSign ID Ihrem AD Mapping hinzufügen, können Sie Ihre Nutzer einfach verwalten und die Nutzerprofile organisieren. /li>

• Das Mapping kann auch mit einer einfachen Textdatei realisiert werden. Dies wird nur für Tests empfohlen, da diese Methode Fehleranfällig ist und keine Registrierungsoptionen unterstützt.

Mapping mit dem SecSign ID Inhouse Server

Der SecSign ID Inhouse Server kann das Nutzermapping übernehmen, insbesondere wenn Sie die Attribute der LDAP Nutzerprofile nicht ändern können oder wollen:

1. Der Benutzer versucht, auf einen geschützte Ressource bei einem Serviceprovider (SP) zuzugreifen
2. Der SP startet den Loginprozess und leitet den Nutzer zum Identity Provider (Shibboleth IDP) weiter
3. Nachdem der IDP die LDAP Authentifizierung abgeschlossen hat erhält das Shibboleth SecSign ID Plugin den EEPN (eduPerson-principalName: unique identifier) des Nutzers
4. Das IDP sendet die Anfrage mit dem EPPN zum SecSign ID Server um die SecSign ID zu erhalten
5. Das IDP erhält die SecSign ID und absolviert die 2FA wie oben beschrieben

Nutzermanagement muss nicht kompliziert sein. SecSig ID bietet zahlreiche Möglichkeiten, die Registrierung Ihrer Nutzer automatisch und schnell abzuwickeln. Sie können so mit minimalen Aufwand den Zugriff von großen Nutzergruppen auf Ihr Shibboleth verwalten.
Mehr Informationen zum Nutzermanagement

Individuelle Nutzerregistrierung

Die individuelle Nutzerregistrierung ist ideal für kleinere Benutzergruppen oder um die Integration zu testen. Je nach Ihrem Mapping können Sie die SecSign ID direkt zum Active Directory Nutzerprofil hinzufügen, oder das EPPN (der Shibboleth Nutzername in Kombination mit dem Scope) zum Nutzerprofil auf Ihrem SecSign ID Inhouse Server hinzufügen.

Individuelle Registrierung

Sie können Ihren Nutzern anbieten, ihre SecSign ID während des Logins hinzuzufügen. Der Nutzer wird aufgefordert, seine SecSign ID anzugeben, nachdem er sich erfolgreich mit seinem Nutzernamen und Passwort angemeldet hat. Nach seiner ersten erfolgreichen Authentifizierung mit der App ist er automatisch für die 2FA freigeschaltet.

Vordefinierte Registrierung

Wenn Sie lieber eine definierte Struktur für die Erstellung der SecSign ID bestimmen möchten, bieten wir die QR Code Registrierung an. Der Nutzer meldet sich mit seinem Nutzernamen und Passwort an und bekommt einen QR Code angezeigt. Dieser QR Code enthält alle Informationen zu Server Endpoints und der SecSign ID mit definiertem Muster, beispielsweise die Email Adresse des Nutzers. Der Nutzer scannt den QR Code mit seiner SecSign ID App und die SecSign ID wird automatisch in der App erstellt. Die SecSign ID wird dem Shibboleth Nutzer nach seiner ersten erfolgreichen Authentifizierung automatisch zugeordnet.

Für einen noch komfortableren Registrierungsprozess bieten wir darüber hinaus die SecSign ID Custom App in Kombination mit dem SecSign ID Inhouse Server an. Die App bietet zahlreiche individuell anpassbare Registrierungsoptionen, beispielsweise Email Aktivierungscodes.

Kontaktieren Sie uns für mehr Informationen zu Nutzerregistrierungen

1. Bauen Sie die Verteilung

$ cd secsign-shibboleth
$ ./gradlew build

2. Kopieren Sie conf, edit-webapp, flows und views von IDP_HOME zu $IDP_HOME, normalerweise /opt/shibboleth-idp.

$ cp -r /secsign-shibbolet/build/* $IDP_HOME/

3. Bearbeiten Sie $IDP_HOME/conf/idp.properties und ändern Sie die folgenden Eigenschaften:

• Fügen Sie /conf/secsignid.properties zu dem Propertyidp.additionalProperties= hinzu,

  beispielsweise:

  idp.additionalProperties= /conf/ldap.properties, /conf/saml-nameid.properties, /conf/services.properties, /conf/secsignid.properties

• Ändern Sie das Property idp.authn.flows= zu idp.authn.flows=MFA

4. Bearbeiten Sie $IDP_HOME/conf/secsignid.properties und passen Sie es Ihren Anforderungen an:

• idp.secsignid.serviceName: Dieser Service Name wird in der SecSign ID App während der Authentifizierung angezeigt.
• idp.secsignid.apiHost: API Endounkt für die öffentliche Cloud (https://httpapi.secsign.com) oder die HTTP Interface Ihres SecSign ID Inhouse Servers
• idp.secsignid.fallbackserver: Fallback Server API Endpunkt falls apiHost ausfällt (öffentliche Cloud: https://httpapi2.secsign.com)
• idp.secsignid.showAccesspass: true: Zeige den Zugangspass während des Logins und in der App.
  false: Zeige „Login akzeptieren“ oder „Login ablehnen“ Auswahl in der SecSign ID App während des Logins.
• idp.secsignid.useShibLdap:true: LDAPq Konfiguration von ldap.properties nutzen, u die SecSign ID für die Nutzer im AD Profil zu finden. Wenn Sie die SecSign ID Registrierungsoptionen nutzen, wird die SecSign ID nicht im LDAP gespeichert (Diese Funktion wird in V. 1.3 verfügbar sein).

  false: LDAP Connector nicht verwenden und EPPN an den Inhouse SecSign ID Server senden. Der SecSign ID Inhouse Server verwaltet das Aufrufen der ID und die Authentifizierung. Wenn Sie die SecSign ID Registrierungsoptionen nutzen, werden die SecSign IDs mit dem EPPN als Identifizierung auf dem SecSign ID Inhouse Server gespeichert.
  Die LDAP Profile müssen die folgenden Werte enthalten: mail (Email Addresse), sn (Nachname), givenname (Vorname)

• idp.secsignid.secPinName: SecSign ID Inhouse Server PIN Account Name für QR Code Enrollment und Nutzersuche.
• idp.secsignid.secPinPassword: SecSign ID Inhouse Server PIN Account Passwortfür QR Code Enrollment und Nutzersuche.
• idp.secsignid.selfEnrollment: Aktiviere QR-Code und Wiederherstellungscode Selbst-Registrierung, falls der Nutzer noch keine SecSign ID hat. Wenn diese Funktion deaktiviert ist, wird die Authentifizierung für Nutzer ohne SecSign ID automatisch fehlschlagen.
• idp.secsignid.usePattern: true: Eine vorgegebene Struktur von idp.secsignid.idPattern nutzen, um eine neue ID zu erstellen, false: der Nutzer kann frei eine ID wählen (Die Option, eine individuelle SecSign ID während der Registrierung zu wählen wird in v1.3 verfügbar sein)
• idp.secsignid.idPattern: Eine vorgegeben Struktur für die SecSign ID nutzen. Diese IDs müssen in der gesamten Nutzergruppe individuell sein. Wenn eine ID bereits vergeben ist, kann die Registrierung des Nutzers nicht abgeschlossen werden.
  
  Definitionen, die genutzt werden können: Variables that can be used:
  • %username% : Shibboleth Nutzername, normalerweise der gleiche wie die LDAP uid
  • %email% : Email Adresse des Nutzers
  • %scope% : Feld von idp.properties
  • %eppn% : eduPersonPrincipalName, normalerweise username@scope

5. Bearbeiten Sie $IDP_HOME/conf/authn/general-authn.xml, und authn/SecSignID Bean zum Element

 <bean id="authn/SecSignID" parent="shibboleth.AuthenticationFlow"
        p:passiveAuthenticationSupported="true"
        p:forcedAuthenticationSupported="true">
        <!--
         The list below should be changed to reflect whatever locally- or
         community-defined values are appropriate to represent MFA. It is
         strongly advised that the value not be specific to SecSignID or any
         particular technology.
       -->
        <property name="supportedPrincipals">
            <list>
                <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="http://example.org/ac/classes/mfa" />
                <bean parent="shibboleth.SAML1AuthenticationMethod" c:method="http://example.org/ac/classes/mfa"/>
            <list>
        </property>
    </bean>

6. Passen Sie die Modify the supportedPrincipals Liste im Bean<bean id="authn/MFA"... an, beispielsweise:

    <property name="supportedPrincipals">
        <list>
            <bean parent="shibboleth.SAML2AuthnContextClassRef"                c:classRef="http://example.org/ac/classes/mfa" />
            <bean parent="shibboleth.SAML1AuthenticationMethod"   c:method="http://example.org/ac/classes/mfa"/>
            <bean parent="shibboleth.SAML2AuthnContextClassRef"
                c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
            <bean parent="shibboleth.SAML2AuthnContextClassRef"
                c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:Password" />
            <bean parent="shibboleth.SAML1AuthenticationMethod"
                c:method="urn:oasis:names:tc:SAML:1.0:am:password" />
        </list>
    </property>

7. Bearbeiten Sie $IDP_HOME/conf/authn/mfa-authn-config.xml und ändern Sie das Element , beispielsweise so:

    <util:map id="shibboleth.authn.MFA.TransitionMap">
        <!-- First rule runs the UsernamePassword login flow. -->
        <entry key="">
            <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/Password" />
        </entry>

        <!-- An implicit final rule will return whatever the final flow returns. -->
        <entry key="authn/Password">
            <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/SecSignID" />
        </entry>
    </util:map>

8. Bauen Sei die IdP war Datei neu auf

$ $IDP_HOME/bin/build.sh

8. Kopieren Sie die war Datei zum öffentlichen Ordner und starten Sie den Web Server neu. Beispielsweise mit Jetty:

$ cp $IDP_HOME/war/idp.war /opt/jetty.../webapps/
$ service jetty restart

1. Konfigurieren Sie den SAMLtest Service Provider

• Öffnen Sie https://samltest.id/upload.php und laden Sie die meta data file von $IDP_HOME/metadata/idp-metadata.xml hoch.
• Öffnen Sie $IDP_HOME/conf/metadata-providers.xml und kopieren Sie die SAMLtest Metadata von https://samltest.id/download/

2. Öffnen Sie https://samltest.id/start-idp-test/ in Ihren Browser und kopieren Sie Ihre entityID von Ihrem IdP

Alle Verbindungs- und Authentifizierungsfehler werden unter $IDP_HOME/logs/idp-process.log oder $IDP_HOME/logs/idp-warn.log geloggt.