SecSignID Plugin: Shibboleth IDP

2018-08-29 10 minutes to read
Tutorial Index

SecSignID 2-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. :

  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.
After the password login, the SecSignID of the user will be in the authentication context and can be used for the 2FA.

Requirements

Requirements

Please contact us, if you do not want to modify Active Directory user profiles. We offer ID – Username mapping with an 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
Enrollment

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

Installation

Installation

1. Build the distribution

2. Copy conf, edit-webapp, flows and views from IDP_HOME to $IDP_HOME, usually /opt/shibboleth-idp.

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

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

    for example:

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

4. Edit $IDP_HOME/conf/secsignid.properties and onfigure 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 durin g 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

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

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

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

8. Rebuild the IdP war file

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

Test IDP

Test with samltest.id

1. Configure the SAMLtest Service Provider

2. Open https://samltest.id/start-idp-test/ in your browser and paste your entityID of your IdP

Troubleshooting

Troubleshooting

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

Options for secure SSO for Atlassian products

Options for securing Atlassian SSO Your users and passwords and services are all over the place? You want to simplify your security and authentication setup but you don’t know where to start? Move beyond your authentication ...

Mehr Lesen

Multi-Factor Authentication powered IdM/IAM

Multi-Factor Authentication powered IdM/IAM with SecSign ID Your users and passwords and services are all over the place? You want to simplify your security and authentication setup but you don’t know where to start? Move bey ...

Mehr Lesen

Atlassian JIRA and Confluence Two-Step Authentication and IP-SafeZone

With SecSign ID you can protect all your logins with a secure Two-Factor Authentication based on a challenge response. The authentication offers the highest protection for the company data while being incredibly simple to us ...

Mehr Lesen