Editor Single Sign-On (SSO)

With SSO, you can manage your team access to DeveloperHub projects without having to add them one by one.

DeveloperHub easily integrates with your existing Identity Provider (IdP) so you can provide your employees with single sign-on to DeveloperHub using the same credentials and login experience as your other service providers.

By using SSO, you employees can access DeveloperHub directly from the shared dashboard your IdP provides, or through our login page. This brings you far more control over access and security.

DeveloperHub supports SAML 2.0, which works with but not limited to:

• Google
• Okta
• OneLogin
• Azure
• Active Directory (ADFS)

Process for Setting Up SSO

The process for setting up SSO is as follows:

• Contact us to let us know that you require SSO, providing us with which IdP you are integrating with.

• We will provide you with an sso_id which you can use to get the ACS URL. The Entity ID and logo are as follows:

  • ACS URL: https://auth.developerhub.io/login/callback/<sso_id>
  • Entity ID: https://auth.developerhub.io/sp
  • Logo link.

• We will then require from you

  • IdP SSO URL.
  • IdP Issuer.
  • Are responses signed?
  • X.509 certificate.

• Inform us of the SSO configuration you require.

Attributes

To save on time for your employees to enter their name on DeveloperHub, you can set optional attributes in your IdP setup as such:

• firstname and lastname for First Name and Last Name of a user profile.
• name if your user profiles have full names.
• role to one of ADMIN, PUBLISHER, WRITER, REVIEWER.

Google SSO

While configuring SSO, use EMAIL Name ID format with Basic Information > Primary email.

The attributes for Google SSO must look as follows:

Okta SSO

While configuring SSO, use Name ID format EmailAddress and Application username to be Email.

The attributes for Okta SSO must look as follows:

Configuration

DeveloperHub provides configuration settings for SSO connections. They are:

• SSO login enforced: Specifies if editors can only log in using SSO. By default this is disabled until SSO connection is tested.
• Default role: The default role for users that get created by signing into SSO.
• Add users to all projects by default: Specifies whether when a user logs in, they would have access to all the projects in the organisation, or if they would require an invitation for each project.
• Email domain: (Optional) The organisation email domain (e.g. tesla.com). Used when new users are logging in using SSO.

SSO settings can be viewed by organisation owners from the sidebar > Organisation . SSO settings can be changed by contacting us.

Creating Users

To create/invite users into your project, you can:

• Initiate a session from your IdP.
• Provide them with a link which you can copy from Team > Copy SSO Login URL
• Invite them by e-mail address from Team > Invite teammate to collaborate . They will be sent an e-mail containing the SSO Login URL.
• Ask them to log in directly from our login screen if "Email domain" is configured for the SSO connection.

Logging in Users

To login existing users, they can:

• Initiate a session from your IdP.
• Provide them with a link which you can copy from Team > Copy SSO Login URL .
• Login directly from our login screen by using Log in Using SSO.

Deprovisioning Users

When deprovisioning a user, the following will happen:

• All their projects will be removed, regardless if they are in the organisation or not.
• All their access to the organisation's projects will be revoked.
• Their user account will be deleted. If they needed to be re-activated again, the user will be a new user.

To deprovision a user:

• From the sidebar, click on Team .
• Click on the badge next to the user, and click Deprovision from Organisation.
• Confirm your choice.

Debugging SSO Issues

If on SSO login you get a message, which depends on your IdP, indicating that the user is not allowed in this application, then you should ensure that the user is added to the correct group in your IdP application settings.