Parent page: Company Dashboard
The Company Dashboard Authentication page allows account Administrators to configure and enable Single Sign-On (SSO) capabilities for your Altium account, and includes support for SCIM (System for Cross-domain Identity Management) user and group provisioning, which automates the exchange of identity data between your company and its Identity Provider (IdP).
This backend configuration system allows account administrators to establish, test, enable and disable the SSO capability for company users. The SSO option is available when signing in to Altium Designer, AltiumLive, and an Altium 365 Workspace. When set up for account users, SSO offers the convenience of signing in to Altium software and services using the same set of credentials that apply to your company-wide systems.
SAML Single Sign-On
When configured and enabled in the Dashboard, the SSO system establishes authorized identities from your company's nominated Identity Provider (IdP), for example Okta, OneLogin, etc, with the ID assertion communications based on the standardized Security Assertion Markup Language (SAML 2.0). The SSO sign-in interface for your company, if not already in place, is usually based on a template or example provided by the IdP – this instigates the SAML-based authentication assertion exchanges and provides access to company services.
In its default state, the Dashboard Authentication page shows the preconfigured URLs for the AltiumLive SSO service (1. Altium metadata configuration), and the option to upload or manually enter your IdP's authorization connection data (2. SAML Identity Provider Configuration).
The IdP configuration metadata, to be uploaded as shown above, should be available from your Identity Provider once it is set up for integration with your company services.
Identity Provider Integration Examples
Expand the collapsible section below for a step through example of the integration process for a typical Identity Provider (OneLogin):
Expand the collapsible sections below for step-through examples of the integration and provisioning process for a typical Identity Provider (Okta):
Section link
SCIM Provisioning Integration with Okta as the IdP
Adding SCIM (System for Cross-domain Identity Management) Integration:
- In the Okta Admin Console select the General tab, and set SCIM as the provisioning method.
- Select the Provisioning tab and click the Edit button.
- In the settings edit mode, select all provisioning actions (Import.. and Push.. options), and HTTP Header as the Authentication mode.
- Copy and paste the Dashboard SCIM Base URL to the Okta SCIM Connector base URL field.
Copy and paste the Dashboard SCIM API Token to the Okta Authorization field (under HTTP HEADER).
- Specify
userName as the Okta Unique identifier field for users.
- Click the Test Connector Configuration button (see above) and ensure that the connection is working.
If the configuration test is successful, close the Test window and then save the configuration ().
- Select To App in the navigation tree on the left, and then the Edit option.
Enable the Create Users, Update User Attributes, and Deactivate Users options, and then click Save.
Users, Group provisioning and de-provisioning:
- Select the Push Groups tab and then click the Refresh App Groups button.
- Select the Directory » Groups page option from the main menu.
In Groups, you should see both the application Groups and Workspaces as group entries.
- Create 'native' Okta groups with the same name as the application group(s)/workspace(s) – in this example, the imported Administrators and Workspace groups.
- Select a created Okta group and then click the Manage Apps button. In the Assign Applications to <group name> window, assign the SCIM Application to the group and click when finished.
- Go back to the Groups page and select the Push Groups tab. Select the Find groups by name option from the Push Groups button menu.
- Enter the group name (here,
Group Administrators) and then choose the Link Group option to link it with the application group. Save that link configuration ().
Managing Users and Groups
You should now be able to add members to, or remove members from, the existing application group(s).
- Create a new Okta user (Directory » People, then select Add Person). Ensure that the user has a unique email address that does not exist in AltiumLive.
- Add the new user to an Otka Group that is assigned to the SCIM application (Directory » Groups, select a group, then use Assign People).
- Check that the user appears in AltiumLive. Note that the AltiumLive user cache may need to be cleared – to do so, click the Refresh button in the Dashboard overview page.
To create a new user group through the SCIM application, create a new Okta group in the Groups page (), and then under the Push Groups tab, find the new group name and choose the Create Group option (rather than 'Link Group').
The configured SCIM application should allow you to:
- Change a User's firstname / lastname, and email.
- Change a Group's membership.
- Change a Group's name.
- Create a group.
- Delete a group – unlink the group under Push Groups with the delete from app option.
- Activate or Deactivate a user – an activated user will receive an activation email.
Workspaces look similar to user Groups in Okta, but only support membership management. You cannot create a new workspace or rename an existing one.
After adding or removing a user from a Workspace group, you can check the result through the Altium 365 Workspace interface.
- The new SCIM user should be able to log in using SSO
- The new SCIM user should be automatically invited into the Workspace.
- An Email invitation will not be sent to the user.
Expand the collapsible section below for a step through example of the integration and provisioning process for Microsoft Azure as an Identity Provider:
Section link
Integration with Microsoft Azure Active Directory
SAML Application:
1. Sign in to the Microsoft AAD portal.
2. Select More services and then the Enterprise applications option.
3. Create your own application.
4. Select Users and groups and then Add user/group.
5. Select Single sign-on, Step 1, and then Edit.
6. Copy () Entity ID and Single Sign On URL from the Dashboard Authentication page.
7. Paste the copied strings into the Entity ID and Assertion Consumer Service URL fields in the Azure App Save area. Make sure the Default boxes are checked for these fields, and then save the configuration.
8. Download the created Metadata XML.
9. Upload the Metadata XML to the Authentication page, and then test the SAML integration connection.
Provisioning:
1. In the Azure app management screen, select Provisioning in the left panel and then the Get started button.
2. Set Provision MODE to Automatic.
3. Set Tenant URL to the Base URL shown in the Dashboard Authentication page (see below).
4. Set Secret Token to the API Token shown in the Dashboard Authentication page (see below).
5. Click the Azure Provisioning Test Connection button, and if the credentials are successfully authorized, Save the configuration.
6. In the Mappings section, there are two selectable sets of attribute mappings – one for Group objects and one for User objects.
7. Select each mapping to review the attributes that are synchronized from Azure Active Directory to your app. The attributes selected as Matching properties are used to match the users and groups in your app for update operations. Select Save to commit any changes.
You can optionally disable syncing of group objects by disabling the Groups mapping.
8. Under Settings, the Scope field defines which users and groups are synchronized. Select Sync only assigned users and groups (recommended) to only sync users and groups assigned in the Users and groups page.
9. Once your configuration is complete, set the Provisioning Status to On.
10. Select Save to start the Azure AD provisioning service.
Expand the collapsible section below for a step through example of the integration process for JumpCloud as an Identity Provider:
Integration with JumpCloud as the Identity Provider
1. In the JumpCloud interface, select SSO from the navigation tree, and then the Add New Application button on the SSO page.
2. Enter 'saml' in the configuration window Search to locate and then install the Custom SAML App.
3. Name your instance of the Custom SAML App – in this example, the label is 'Altium'.
4. Switch to the SSO tab in the JumpCloud configuration interface and enter the Entity/URL settings from the Dashboard's Authentication page as shown.
5. Enter the JumpCloud endpoint IDP URL and enable the Declare Redirect Endpoint option.
6. Switch to the Identity Management tab in the JumpCloud interface, and then enter the Base URL and Token content copied from the Dashboard Authentication page. Also enter a suitable test email address.
7. Perform a Test Connection, which will show a confirmation message at the top right of the page (as shown below).
8. Turn off (uncheck) the Group Management option and then Activate the configuration.
Note: If you receive a connection error such as 'There was a problem activating Identity Management' at the top of the page or 'Test filter user: unable to get or create user from service' at the bottom of the page, try entering a different test email address and then selecting Activate again.
9. Back in the JumpCloud interface SSO tab, use the Export Metadata option to download the resulting SAML metadata XML file.
10. In the Dashboard Authentication page, import the downloaded metadata XML file and then invoke an Integration test with the Test Sign On button.
11. A successful integration test result should then be displayed.
12. After the connection confirmation you can enable the Altium Sign-On Settings option and then the SSO option in the Authentication methods section.
Expand the collapsible section below for a step through example of the integration process for Microsoft AD FS as an Identity Provider:
Expand the collapsible section below for a step through example of the integration process for AWS IAM as an Identity Provider:
Dashboard SSO Configuration
To configure the SSO system in the Dashboard (if not already completed), use the button on the Authentication page to locate and upload the SAML IdP configuration XML file generated by your company's IdP – see IdP integration examples above. Alternatively, use the enter manually link to add the individual elements (security certificate and URLs) of the configuration.
An uploaded IdP XML file is parsed by the system to extract the main configuration fields (X509 Certificate, Identity Provider Issuer URL, and IdP Single Sign-On URL), which can be manually edited if required ().
SSO is not enabled until an Integration Test is run, which is invoked by the button. This verifies the SSO identity process and your company's SSO sign-in, and then provides a confirmation message that includes the option to inspect the SAML authorization result ().
Back in the Authentication page, the configuration validity check is reported as successful and the Altium account's Single Sign-On capability can be enabled (). If SSO is subsequently disabled, either manually or in response to a configuration change, the button becomes available so the test process can be repeated.
Note that the user
Provisioning section is preconfigured with Altium's
SCIM settings in order to support User/Group provisioning through your company's Identity Provider (IdP), such as
Okta,
OneLogin, etc.
Authentication Methods
Along with providing a setup interface for configuring Altium SSO connectivity, the Dashboard Authentication page also provides global and individual control over the full range of user sign-in options – namely; traditional Email/Password, Google® and Facebook® sign-in, and Single Sign On via your organization's Identity Provider. The options enabled in the Authentication methods section of the page determine the sign-in methods available to all your organization's Altium account users.
The system's response to user sign-in will depend on the enabled Authentication options:
- When SSO is enabled for users but another method is disabled (say, Email/Password), an attempt to sign in using that method will default to the SSO procedure.
- When SSO is disabled, attempting to sign in using another disabled method (say, Email/Password) will result in an error message.
- When SSO is disabled, attempting to sign-in using SSO will result in an error message.
Sign-in options can be configured for an individual user by editing the settings in their Dashboard account entry. Select the button on the user's Dashboard Users page to access their sign-in override options. These settings, when edited with the Override Authentication methods option enabled, will take precedence over the global sign-in settings on the Authentication page for this user only. Click the button to confirm a change to the settings.
The Authentication Override settings might be used where SSO is the enforced sign-in method for an organization (all other options are disabled, globally), but an individual user requires a specific type of sign-in access – email/password only, for example.
Individual user sign-in methods that have been specified with the Override Authentication methods settings (as above) can be restored to their defaults with the Reset users overrides option in the Authentication methods section of the Authentication page. This will reset the individual sign-in settings for all users to the global authentication methods that are currently selected on the Authentication page.