SecSign ID Plugin: Shibboleth IDP

2018-08-29 10 minutes to read
Tutorial Index

Two-Factor-Authentication for Shibboleth IDP

The following tutorial describes the configuration to use Two-Factor Authentication with SecSign ID Plugin on a third party application using Shibboleth IDP

Login Procedure

System Overview and Login Procedure

The SecSignID 2FA flow for Shibboleth Identity Provider v3.3.x. :

SecSign ID Integration

Please configure your desired integration of the SecSign ID Two Factor Authentication

Choose a system, where you want to add the secure login

Do you need your own ID Server inside your protected network or prefer if we manage and maintain it for you

The location to save the assigned SecSign IDs to a user account or the IDM alltogether

System to protect
The System you want to protect - Choose a system, where you want to add the secure login
SecSign ID Server location
Do you need your own ID Server inside your protected network or prefer if we manage and maintain it for you
User account location
The system to save the assigned SecSign IDs to a user account or the IDM alltogether
edit the settings to change the integration
2FA blind
2FA no AP
2SA no AP
2SA blind
Custom ID
IDP Custom Website
Enrollment initiated by SP
Enrollment with IDM
Show Network
Hide Network
Request Solution
The authentication was successful
  1. User opens a protected resource at a Service Provider
  2. Connection initiated by application or service. The Shibboleth IDP prompts user name and password form
  3. Primary authentication, usually via Active Directory. The LDAP Server returns the authentication context with the user’s SecSignID to the Shibboleth IDP
  4. Secondary authentication gets initiated. The SecSign ID Authentication Server can be on-premise or in the cloud
  5. A new Authentication session is created and the user sees an accesspass symbol in the browser
  6. The user gets a notification on his smartphone that an authentication session is pending. The user logs into the app via PIN code, fingerprint or face recognition, can see the pending login and taps on the correct access pass symbol.
  7. Shibboleth IDP receives authentication response
  8. Application or Service session logged in

The SecSignID flow is designed to be used together with another login flow, usually by utilizing the MFA login flow. The first login flow can be the standard password authentication, connected to a LDAP server. In your AD, the Shibboleth users need the SecSignID attribute in the user profiles.
Alternatively, the On-Premise SecSignID Server can be used to manage the user account to SecSignID mapping

After the password login, the SecSignID of the user will be in the authentication context and can be used for the 2FA.



Please contact us, if you do not want to modify Active Directory user profiles. We offer ID – Username mapping with our on-premise SecSignID server. Mapping via text file is not recommended but possible.

ID Mapping

SecSignID Mapping

When your users login, they usually authenticate with user name and password first. After that, the second factor will be requested. So how does the mapping of user name and SecSignID work?

You have several options to assign a SecSign ID to a user:

  • The most comfortable solution is an on-premise ID Server that will handle the mapping. It saves the shibboleth user names in an internal database and performs the two-factor authentication. You have full control of user data, enrollment policies and naming patterns.
  • If you don’t need the advanced functions of an on-premise ID server, you can add an attribute to the user profiles in your Active Directory quite easily. See here how it works. Adding the SecSignID mapping into Active Directory makes it easy to manage and administer user accounts
  • A simple text file can also handle the mapping. It’s recommended for testing purposes only, since this method is error prone and does not support advanced enrollment features

Mapping with an On Premise ID Server

An On-Premise ID Server can handle the user mapping, especially when you won’t or can’t add an attribute to the LDAP user profiles:

  1. user tries to access a protected resource on a service provider (SP)
  2. SP starts the login process and redirects the user to the identity provider (Shibboleth IDP)
  3. after the IDP finishes the ldap authentication, the Shibboleth SecSignID Plugin will get the Shibboleth user name and creates the EPPN (eduPerson-principalName: unique identifier) of the user
  4. the IDP sends a request to the SecSignID Server containing the EPPN to determine the SecSignID
  5. the IDP gets the SecSignID and performs the 2FA shown above

SecSignID User Enrollment

User management does not need to be complicated. SecSign ID offers convenient options to automate the enrollment of your users. You can conveniently manage the access to your Shibboleth system for large numbers of users with minimal effort. More about user management

Manual Enrollment

The manual enrollment is perfect for small user bases or to test the integration. Depending on your mapping, just add the SecSignID to your Active Directory user profile or add the EPPN (Shibboleth user name combined with the scope) to the user profile on your on-premise ID server.

Individual Enrollment

You can offer the users to add their SecSign ID during the login. Once the user is logged in with his user name and password, he is prompted to provide his SecSignID. He authenticates with his mobile phone and thus, automatically activates 2FA for the next logins.

Predefined Enrollment

If would like to enforce naming patterns on how SecSignIDs are automatically created, we offer QR code enrollment. Once the user is logged in with his user name and password, the SecSignID plugin will generate a QR code containing all server endpoints and predefined SecSignID. The user reads the QR code with the SecSignID app and a new SecSignID will be created automatically on the user’s phone. After performing the two factor authentication, the SecSignID will be assigned to the Shibboleth user for future 2FA.

For an even more convenient and streamlined process you can employ your own SecSignID custom app in combination with your on-premise server. It offers numerous customized enrollment options including Email-based activation codes.

Feature coming soon. Please contact us for more information about enrollment options



1. Build the distribution

You will receive a *.zip file, which contains the plugin source. Extract it to the folder secsign-shibboleth and build the jar file. This might take some time.

$ cd secsign-shibboleth
$ ./gradlew build
$ ./gradlew jar

2. Copy conf, edit-webapp, flows and views from IDP_HOME to $IDP_HOME on your IDP Server (usually /opt/shibboleth-idp).

The following tutorial assumes /opt/shibboleth-idp as $IDP_HOME.

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

3. Edit $IDP_HOME/conf/ and change the following properties:

  • Append /conf/ to the property idp.additionalProperties=

    for example:

    idp.additionalProperties= /conf/, /conf/, /conf/, /conf/
  • Change the property idp.authn.flows= to idp.authn.flows=MFA

4. Edit $IDP_HOME/conf/ and configure it to your liking:

  • idp.secsignid.serviceName: The service name will be displayed in the SecSignID app during authentication
  • idp.secsignid.apiHost: Api endpoint for public cloud ( or the http interface of your On-Premise ID Server
  • idp.secsignid.fallbackserver: Fallback server Api endpoint if apiHost fails (public cloud:
  • idp.secsignid.showAccesspass: true: show AccessPass on login and in SecSignID app or just show reject & accept buttons in SecSignID app on false
  • idp.secsignid.useShibLdap:true: use the LDAPq configuration from to find SecSignID for user in AD profiles. If you use the enrollment options, the SecSignIDs will not be stored via LDAP (function will be available in v.1.3)

    false: don’t use LDAP connector and send EPPN to On-Premise ID Server, which handles the lookup and authentication. If you use the enrollment options, the SecSignIDs will be stored on the On-Premise ID Server with EPPN as identifier. The LDAP Profiles need to contain the following values: mail (email address), sn (last name), givenname (firstname)
  • idp.secsignid.secPinName: On-premise SecSign ID Server PIN account name may be used for QR-code enrollment and user lookup
  • idp.secsignid.secPinPassword: On-premise SecSign ID Server PIN account password may be used for QR-code enrollment and user lookup
  • idp.secsignid.selfEnrollment: Enable QR-Code and Restore-Code self enrollment if user has no SecSignID. If disabled, the authentication will fail for users without SecSignID
  • idp.secsignid.usePattern: true: use a pattern from idp.secsignid.idPattern to create new ID, false: the user can freely choose an available ID (the feature to create custom SecSignIDs during enrollment will be available in v1.3)
  • idp.secsignid.idPattern: Use a pattern to create new SecSignIDs. These IDs must be unique over your whole user pool. If ID already exists, enrollment and authentication fails
    Variables that can be used:
    • %username% : Shibboleth Username, usually same as Ldap uid
    • %email% : email address of the user
    • %scope% : scope used from
    • %eppn% : eduPersonPrincipalName, usually username@scope

    If you use the pattern option, some information need to be extracted from the SAML comunication. To do that, adjust your $IDP_HOME/conf/attribute-resolver.xml accordingly.

    The username will be loaded via c14nContext, the scope via mail and eppn need to be resolved. See example for IDP3 or IDP4

5. Edit $IDP_HOME/conf/authn/general-authn.xml, add authn/SecSignID bean to the element

 <bean id="authn/SecSignID" parent="shibboleth.AuthenticationFlow"
         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">
                <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="" />
                <bean parent="shibboleth.SAML1AuthenticationMethod" c:method=""/>

6. Modify the supportedPrincipals list in the bean <bean id="authn/MFA"... to something like this:

    <property name="supportedPrincipals">
            <bean parent="shibboleth.SAML2AuthnContextClassRef"                c:classRef="" />
            <bean parent="shibboleth.SAML1AuthenticationMethod"   c:method=""/>
            <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" />

7. Edit $IDP_HOME/conf/authn/mfa-authn-config.xml and change the element to something like this:

    <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" />

        <!-- 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" />

8. Rebuild the IdP war file

$ $IDP_HOME/bin/

8. Copy the war file to the public folder and restart the web server. For example with Jetty:

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

Test with

1. Configure the SAMLtest Service Provider

2. Open in your browser and paste your entityID of your IdP



All connection or authentication errors and exceptions will be logged to $IDP_HOME/logs/idp-process.log or $IDP_HOME/logs/idp-warn.log

Your own ID-Server

On premise installations of SecSign ID offer the flexibility to connect with your preferred servers, services, and devices. And you can customize the SecSign ID with your own organization’s branding.

Learn More
On Premise 2FA ID

Latest Blog Posts, Updates & Features

SecSign ID Server passed FIDO Certification

We are happy to announce that the SecSign ID server has passed the official FIDO certification program of the FIDO Alliance. This will allow you to use the complete FIDO2/WebAuthn standard for passwordless 2FA sign-ins in your exi ...

Mehr Lesen

Two-Factor Authentication with Fido2 / WebAuth

The FIDO2 Project is a set of standards developed by the FIDO Alliance and the World Wide Web Consortium (W3C) to create a strong authentication protocol for the web. It consist mainly of the WebAuth standard for the browser part ...

Mehr Lesen

Protecting the Home Office VPN with 2FA

In the recent weeks, home office work has increased potentially. And while employees are practicing social distancing from their home computer, attackers are working hard to exploit security issues in this situation that is unfami ...

Mehr Lesen
SecSign 2FA