This use case should cover all steps which are necessary to set-up SSO with Azure AD using B1 Security-Hub.

• 1. Summary
• 2. Result
• 3. Step by Step Guide
• 3.1 What to do on Azure Side
• 3.2 Determining OIDC Configuration Parameters
• 3.3 What to do on Security-Hub Side
• 3.4 What to do on Build.One Site
• 4. Documentation

1. Summary

OIDC is the more modern protocoll for Single Sign On, Azure supports a number of Authentication protocolls [1]. Build.One today only supports OIDC.

Key reasons to setup SSO are:

• Single Sign On allowing ease of login and control on:
• force login only possible via company domain credentials (not via other domains)
• use of MFA can be enforced
• control on providers and scope (access and data) an be enabled

If there is no option but to use Saml, then there are a number of options customers can use

• Preferred: Implement a saml <-> passport <-> ldap bridge
• Use Auth0 / Okta as a federated identity management (* incurs extra costs, requires online access)
• Use keycloak in the SecurityHub stack
• Implement a oidc<->saml bridge ([https://github.com/digitalcredentials/saml2-oidc-bridge) ]
• Implement a saml <-> passport connector, with an embedded token to create and issue further tokens

2. Result

After applying all these steps, you’re application can be accessed via SSO with Azure AD. You’ll see an additional button in the login screen

3. Step by Step Guide

3.1 What to do on Azure Side

To configure an OIDC Application for Azure AD the following High-Level Steps have to be performed beforehand:

• Create or select an Azure AD Application
• Configure Redirect URIs (Type: web)
• the redirect url takes the form of https://<app_url>/callback
• Grant the AAD application the permission: Group.Read.All
• Create a secrets for the AAD application
• groupMembershipClaims should be set to “All” or “Security” in the App registration manifest

3.2 Determining OIDC Configuration Parameters

The OIDC Configuration expects the following parameters:

• discovery url
• client id
• client secret

The discovery url specifies the OIDC Discovery URL, without any .well-known components. For Azure AD this URL looks like this:

https://login.microsoftonline.com/<tenant-id>/v2.0

Make sure to replace the tenant id with the ID of your tenant. There are multiple ways to find out the own tenant id. For example in the Azure Portal -> Azure Active Directory

the client id and client secret represent the Credentials for the Azure AD Application that was registered or selected for use with HashiCorp Vault.

These Values can be retrieved via the Azure Portal under Azure Active Directory-> App registrations. Select your App Registration to view the Details.

3.3 What to do on Security-Hub Side

Create a new OIDC service provider

• providers→OIDC→new
• enter a name, and description
• the domain is used by secureable to identify a login provider. You should normally use the domain of the Azure AD
• Enter the Discovery Url, client id and client secret obtained from Azure
• Save

3.4 What to do on Build.One Site

You have to configure the environment variables to use to Security-Hub Login instead of the standard login

for standard swat logins

• PASOE_LOGIN_MODEL=form
• ALLOWED_AUTHENTICATION=AkiomaUser

for secureable logins

• PASOE_LOGIN_MODEL=oauth2
• ALLOWED_AUTHENTICATION=Secureable
• AUTHENTICATION_URI=<url of secureable instance>
• AUTHENTICATION_OIDC_ROLE_ID=<role id>
• AUTHENTICATION_AUDIENCE=<audience>

4. Documentation

To find more information, you can check the following documentation.

Security-Hub (Formerly known as secureable)

Back to Use Cases

Back to Home Page