Skip to main content
Skip table of contents

How-Tos

This section provides practical, step-by-step instructions on how to perform specific tasks or address particular scenarios.

How to protect access to TrustBuilder Admin portal with MFA

This document describes the set up to protect TrustBuilder Admin portal access with TrustBuilder MFA.

Two cases are identified:

  • the TrustBuilder. io tenant and the MFA tenant are not linked by SAML connectors → see “Link the tenants

  • the TrustBuilder. io tenant and the MFA tenant are already linked by SAML connectors → see “Configure users and access flow

Prerequisites

You should have:

  • Access to TrustBuilder Admin portal with administrator rights.

  • Access to TrustBuilder MFA Admin console with administrator rights. As an admin, you should have at least one trusted device activated.

  • the same email should be configured for the user in both tenants (if “email” is used for authentication)

In order to protect access to the Admin portal with MFA, the TrustBuilder. io tenant and the TrustBuilder MFA tenant should both be linked by connectors in order to be able to communicate.

If the tenants are already linked, you should go directly to “Configure users and authentication scheme”.

Step 1: Create a SAML connector
  1. In TrustBuilder MFA admin console, go to the Secure Sites tab.

  2. In the "connectors” section, click on Add a connector of type… and select SAML 2.0.

  3. Name your connector.

  4. Click on Add to create the connector. This will bring up other parameters.

Step 2: Retrieve the TrustBuilder MFA SAML metadata
  • Click the link “Download inWebo IdP SAML 2.0 metadata in XML format“ and save the file.

  • Click the link “Download inWebo IdP SAML 2.0 certificate“ and save the file.

You will need them for configuration in TrustBuilder Admin portal.

You will come back to this connector later to finalize it.

Step 3: Add an Identity Provider (IdP)
  1. In the TrustBuilder Admin portal, go to Identity Management > Identity Providers.

  2. Click on + Add New IDP

  3. Click on Custom SAML IDP

  4. Define a display name: TrustBuilder MFA.
    You can also add a description.

  5. Select the Subject of the SAML request. Select Email in Common category.
    The SAML subject identifies the user whose identity is being asserted by the identity provider. In our case TrustBuilder MFA is the IdP.

  6. Click on Import Certificate.

  7. Select a Type “Trust” and fill in the “Alias“ field.

  8. Click on Upload > +Select File.

  9. Select the IdP certificate downloaded at step 2.

  10. Click on Accept to import the certificate.

  11. Select the Context “SIGNING (TRUST)”

  12. Enter the Entity ID URL and the SSO location URL.
    You can retrieve them in the IdP metadata file or in the SAML connector you created in the MFA console.

  13.  Click on Add SLO Endpoint.

    • In the location field, enter the Single Logout URL.
      You can retrieve it in the IdP metadata file or in the SAML connector you created in the MFA console.

    • Select “Binding“ as “HTTP-Redirect”.

  14. In Post Profile Template select Default SAML POST page.

  15. Click on Save & Close.

  16. The TrustBuilder metadata appear. Select “Copy to Clipboard” to copy them and “Close”.

Step 4: Finalize the TrustBuilder SAML connector
  1. Go back to TrustBuilder MFA Admin console and edit the TrustBuilder SAML connector.

  2. Paste the TrustBuilder metadata into “Metadata Service Provider (SP)”

  3. In the section “Connector options”, select the option:

    • NameIDFormat → Email Address

    • NameID value” → User email

  4. Click on Update to save and click on Close.

  5. If not automatically created, add the Secure Site associated to the connector (Secure Sites tab > Add a Secure Site of type … > Select your connector’s name).
    The called URL should match the URL of your TrustBuilder instance.

Configure users and access flow

Step 5: Check the user emails

This step should be performed for every administrator who will access the Admin portal with an MFA protection.

  1. In MFA Admin console, check the user email.

  2. In TrustBuilder Admin portal, go to Identity Management > Users

  3. Click on Edit for the relevant user.

  4. In the General tab, edit the email to match the one defined in the MFA tenant.

  5. Click on “Save And Close”

Step 6: Configure the access flow
  1. In TrustBuilder Admin portal, go to Access Management > Access flows.

  2. Edit the IDHub Default Scheme.

  3. Click on Link an Identity Provider.

  4. Select TrustBuilder MFA to add it to the access flow.

  5. Click on Save.

Test access to Admin portal with MFA

Prerequisite
The user performing the authentication test should have at least one MFA trusted device activated.

  1. Log out or open a new incognito window in your browser to avoid having to log out.

  2. Go to the URL of your TrustBuilder instance. https://yourcompany.trustbuilder.io/

  3. You should be able to choose between two sign-in methods:

    • TrustBuilder Repository, which is the default IdP

    • TrustBuilder MFA, which is the Identity Provider previously configured and added into the Access flow.
      Choose TrustBuilder MFA to test the MFA.

  4. Authenticate with TrustBuilder MFA.
    The flow is different depending on the MFA trusted device used (mobile, desktop or browser token) and the multi-Factor authentication method chosen. See https://docs.inwebo.com/documentation/multi-factor-authentication-methods

  5. After a successful authentication with TrustBuilder MFA, you access the Admin Portal.

If you encounter any problems, check the prerequisites and go through the configuration steps to see if anything is missing. Then try again.

Disable TrustBuilder default sign-in method

Be aware that at this stage you will change the TB administrator connection. If something is not correct you may not be able to connect anymore
Please carefully review the previous steps and and be sure to keep an administration session open in a browser before proceeding

  1. In TrustBuilder Admin portal, go to Access Management > Access flows.

  2. Edit the IDHub Default Scheme.

  3. Click on the link icon remove “User Password” of the access flow.

  4. Click on Save.


How to propagate OIDC SP scope to match with SAML IdP attributes

To ensure a seamless user experience in scenarios where OIDC and SAML are used, it may be necessary to align attribute expectations between the two protocols. This involves creating an attribute set with attributes that match those of the scope. Follow the step-by-step procedure below for more information.

  1. Create the attributes that will be included in both OIDC scope and SAML attributes.
    See Defining custom attributes

  2. Create a scope you want to use in OIDC:

    • Define it as OPENID type.

    • Enter a name and an optional description.

    • Select the attributes to be included in the scope.

    • Click on Save & Close.

      image-20240222-163231.png
  3. Create an attribute set:

    • Enter a name

    • Select the attributes included in the scope.

    • Click on Save & Close.

      image-20240222-162434.png
  4. Configure an OAuth Service Provider with the following properties:

    • Check “Propagate to attribute set”

    • Allow openid scope (OAUTH scope type)

    • Allow the scope created above.

      image-20240222-164729.png
  5. Configure a SAML Identity Provider with the following property:

    • Define “Attribute Consuming Services” with the attribute set created above.

      image-20240222-165306.png

  6. Test your configuration:

    • ⚠️ Note that exactly one scope of OPENID type must be present in the request for propagation to work.

    • Make an OIDC Authorization Request from the configured Service Provider. Build the authorization request with the necessary parameters. Make sure to include scopes: openid and the scope created and configured above.
      For example:

      CODE
      https://authorization-server/authorize
      ?response_type=code
      &client_id=your-client-id
      &redirect_uri=your-redirect-uri
      &scope=openid myscope01

      TrustBuilder will use the attribute set that contains all of the attributes defined in the incoming OpenID scope and the least additional attributes.
      The SAML request to the IDP contains AttributeConsumingService attribute with an index defined on IDP configuration.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.