Note
Configuring SSO methods is a premium feature that requires an additional purchase. Contact your Customer Success Manager for more information.
Overview
Fireblocks allows you to use your enterprise identity provider (IdP) as a single sign-on (SSO) method for logging in to the Fireblocks Console. Using an SSO method replaces the username and password authentication method, helps you streamline the sign-in experience, and strengthens your security by reducing the number of passwords each user has to manage.
SSO methods authorize users based on their domain. To log in to the Fireblocks Console via SSO, users must have a workspace account created with an authorized domain. You can choose which domains are authorized for your workspace. After logging in, a list of their available workspaces linked to that domain will appear.
You can use your enterprise’s identity management to permit or prohibit access to the Fireblocks Console.
Fireblocks currently supports the following SSO integrations:
- ADFS
- Google Workspace
- LDAP/Active Directory
- Microsoft Azure Active Directory (AD)
- Okta
- OpenID Connect
- PingFederate
- SAML 2.0 and SAML 3.0
For more information about using ADFS or LDAP as your Fireblocks workspace SSO method, contact Fireblocks Support.
Important
The SSO mechanism only affects a user’s login authorization credentials. Adding or removing a Fireblocks user to or from a workspace can only be done in the Fireblocks Console by the Owner or an Admin.
Google Workspace
Set up your app in Google
To allow your users to sign in to the Fireblocks Console using Google Workspace, you must register your application in the Google developer console. Before registering your app, you must have your own Google Workspace Organization where you are an administrator.
To register a new application with Google, follow Google's procedure for setting up OAuth 2.0. During this process, Google generates a Client ID and Client Secret for your application. Save these for later use.
Settings
On the OAuth consent screen, add auth0.com to the list of authorized domains.
When asked to select an application type, select Web application and set the following parameters:
Field | Description |
Name | The name of your application |
Authorized JavaScript origins | https://YOUR_DOMAIN |
Authorized redirect URLs | https://auth.fireblocks.io/login/callback |
Send Fireblocks Support the following information:
- Client ID
- Client Secret
- Domains of your organization that should be forced to sign in via SSO
Microsoft Azure AD
To register your app with Azure Active Directory (AD), see Microsoft's Quickstart: Register an application with the Microsoft identity platform.
During registration, configure the following settings:
- Supported account types: To allow users from external organizations, such as other Azure AD directories, select Accounts in any organizational directory (Any Azure AD directory - Multitenant).
- Redirect URL: Select Web as your redirect URL type, and enter your callback URL: https://auth.fireblocks.io/login/callback.
Create a Client Secret
To create a Client Secret, see Microsoft's Quickstart: Configure a client application to access web APIs - Add Credentials to your web application. Once generated, save this value for later use.
Send Fireblocks Support the following information:
- Client ID
- Client Secret
- Domains of your organization that should be forced to sign in via SSO
Note
Please make sure to send the Client Secret value, not the Client Secret ID. This is a common mistake.
Okta
- Sign in to the Okta Developer Console.
- Use the App Integration Wizard to add an application for use with Auth0.
- Use the SAML App Wizard to create your SAML integration. Then you'll be directed to the sign-on page for your newly-created app where you enter the following details when necessary:
- Single sign-on URL
- Recipient URL
- Destination URL
- Entity ID
Note
These items are provided by Fireblocks.
- Select View Setup Instructions to complete the process.
- Save the IdP’s single sign-on URL for later use, and download a copy of the X.509 certificate.
Configuring required attributes in Okta
Set the required attributes in your Okta application as follows. Fireblocks needs these attributes to map our Service Provider IDs to your IdP IDs.
Send Fireblocks Support the following information:
- The customer-metadata.xml file of your IdP
- In the Okta app, go to Applications > the required app > Sign On.
- Click the link to the IdP metadata, where you can find the IdP metadata XML file.
- Save that file as a new file with the name customer-metadata.xml.
- X.509 certificate
- Domains of your organization that should be forced to sign in via SSO
OpenID Connect
To allow your users to sign in to the Fireblocks Console using an OpenID Connect (OIDC) IdP, you must register your application with the IdP. This process varies depending on the OIDC IdP, so you will need to follow your IdP's documentation to complete this task. Generally, you should make sure that you enter your callback URL: https://auth.fireblocks.io/login/callback.
Send Fireblocks Support the following information:
- Issuer URL
- This is the URL where Auth0 can find the OpenID Provider Configuration Document, which should be available in the
/.well-known/openid-configuration
endpoint. You can enter the base URL or the full URL. You will see a green checkmark if it can be found at that location, a red mark if it cannot be found, or an error message if the file is found but the required information is not present in the configuration file.
- This is the URL where Auth0 can find the OpenID Provider Configuration Document, which should be available in the
- Client ID
- This is the unique identifier for your registered application. Enter the saved value of the Client ID for the app you registered with the OIDC IdP.
- Domains of your organization that should be forced to sign in via SSO
PingFederate
As long as your server is configured in the standard way, you must get the signing certificate from the IdP and convert it to Base64 in order to connect your PingFederate server to Auth0.
Get the signing certificate from the IdP
Auth0 acts as the service provider for the PingFederate Server, so you need to retrieve an X.509 signing certificate from the IdP (in PEM or CER format). Later, you will upload this to Auth0. The methods for retrieving this certificate vary, so please see the PingFederate documentation for instructions on managing your server's certificates.
Convert signing certificate to Base64
Next, you must convert the file to Base64. To do this, you can use a simple online tool or run the following command in Bash: cat signing-cert.crt | base64
.
Send Fireblocks Support the following information:
- Ping Federate Server URL
- X.509 certificate
SAML 2.0 and SAML 3.0
Integrating SAML 2.0 or 3.0 is similar to the Okta setup instructions above. When you choose this option, Fireblocks provides you with the following details for use in your SAML integration:
- Single sign-on URL
- Recipient URL
- Destination URL
- Entity ID
Once you've configured your SAML integration, send Fireblocks Support the following information:
- Your IdP metadata, saved as an XML file with the name customer-metadata.xml
- X.509 certificate
- Domains of your organization that should be forced to sign in via SSO
Changing SSO providers
To change which SSO provider you use to log in to the Fireblocks Console, contact Fireblocks Support. Changing SSO providers requires approval from the workspace Owner.