SecSign ID Plugin: Shibboleth IDP

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

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.

• Shibboleth Identity Provider 3.3.x – 4.x
• Java (check which version to use for your IDP)
• optional Ldap Server with SecSignID in user profiles

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.

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

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/idp.properties and change the following properties:

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

  for example:

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

• Change the property idp.authn.flows= to idp.authn.flows=MFA

4. Edit $IDP_HOME/conf/secsignid.properties 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 (https://httpapi.secsign.com) or the http interface of your On-Premise ID Server
• idp.secsignid.fallbackserver: Fallback server Api endpoint if apiHost fails (public cloud: https://httpapi2.secsign.com)
• 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 ldap.properties 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 idp.properties
  • %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 secsignid.properties. 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"
        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. Modify the supportedPrincipals list in the bean <bean id="authn/MFA"... to something like this:

    <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. 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" />
        </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. Rebuild the IdP war file

$ $IDP_HOME/bin/build.sh

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

1. Configure the SAMLtest Service Provider

• open https://samltest.id/upload.php and upload your meta data file from $IDP_HOME/metadata/idp-metadata.xml
• open $IDP_HOME/conf/metadata-providers.xml and paste the SAMLtest Metadata from https://samltest.id/download/

2. Open https://samltest.id/start-idp-test/ 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