NEXT offers the option to configure your own managed identity provider as a single sign-on authentication option for NEXT enterprise workspaces.

Managed identity provider

On NEXT enterprise workspaces, you can bring your organization's identity provider to integrate with directly with NEXT. Using your own organization's identity allows you to delegate authentication and provisioning to your source of truth to increase security and onboard employees faster.

SSO benefits

Single sign-on allows users to log into NEXT with their organization's account. This means for users that they don't have to remember yet another password and for organizations that they don't have to worry about yet another place to manage their users (e.g. when somebody leaves the organization).

NEXT single sign-on is available to NEXT Enterprise workspaces.

User journey during single sign-on

With single sign-on activated, this is the journey of a user:

  • User sees on the NEXT login page a "Log in with SSO" login button

  • Clicking that button, the user is forwarded to the organization's identity provider (e.g. Active Directory)

  • The identity provider authenticates the user and sends the user back to NEXT

  • NEXT checks if the authenticated user has already an account in NEXT. If not, a new account is created on the fly. This provides seamless access to e.g. new employees.

  • The user is logged into NEXT

How to set up single sign-on (step-by-step guidance)

NEXT enables single sign-on via SAML, the industry-standard supported by identity providers like Microsoft's Azure Active Directory.

In general terms these are the steps to set up single sign-on:

Step 1 Create an application with SAML SSO in the identity provider

  • Configure the "Sign-on URL" to be https://TENANT.nextapp.co

  • Configure the application logo so that users can identify the application in the application directory (please find the logo attached to this article)

Step 2 Configure the claims provided by the identity provider to NEXT

Claim

Contents

Required?

NameID

Unique identifier.

This must use the "persistent SAML Name ID format."

Required

tenant

Tenant identifier

Required

role

Initial user role in the NEXT application

Each user must have exactly one of the available roles: admin, user, guest

This value is only used when initially provisioning a user, afterwards, the user role can be adjusted through NEXT's administrative interface

Optional (default is "user")

email

Email address of the user for receiving mails.

This should be in the regular RFC822 format (user@domain.tld; an initial display name for a new user can be set by encoding it here as "Display Name" <user@domain.tld> )

Required

Note that the claims use simple names, and do not include any namespace such as "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/".

Here an example from Azure ActiveDirectory (AD):

Step 3 Assign the users that should be able to use NEXT to the application

Step 4 Inform your NEXT Customer Success that you want to enable SSO

Provide them with the "Federation Metadata URL" for the application. Please inform NEXT if you wish migrate any non-SSO users to SSO (see below section on "Migrate existing non-SSO users to SSO").

Step 5 NEXT will provide you with an Identifier (Entity ID), Reply URL (Assertion Consumer Service URL), and Logout URL.

Azure AD: Note that Azure AD supports multiple identifiers and reply URLs for a single application. Ensure that the correct identifier and reply URL is selected and marked as "Default".

Step 6 Configure the application to use the SAMLv2 "POST" binding with the provided Reply URL (Assertion Consumer Service URL) and Logout URL.

Migrate existing non-SSO users to SSO

If you enable SSO after using NEXT for a while, you might have already users with a NEXT account whom you want to log in with SSO instead of email/password.

In a nutshell: Without SSO, users prove that they own their NEXT account by typing in their email/password. With SSO, users prove ownership via a token granted by the SSO IdP, showing that they own the email address associated to the NEXT account. This means if a user logs in via SSO: NEXT checks if there is already an existing NEXT account with the same email address. If so, it binds the existing NEXT account to the SSO identity. If not, a new NEXT account is created for the user.

Before moving to SSO, please validate the email addresses of all users in the admin pages of the NEXT app. All same email address in NEXT must match the ones registered in their SSO identity.

Additional Considerations

SSO-Only or SSO+non-SSO?

In the default configuration, NEXT manages users in a user directory for you, and you can add SSO as an additional sign-in option for your users. Any existing users can use the user directory, and newly invited users will be added to the NEXT user directory.

Depending on the particular details of your organization however, it could be required to enforce the use of SSO. In this case, users must authenticate through your identity provider. The "Invite user" functionality can be used to send out invitation links to new users (taking into account any configured Signup domain restrictions), but whether the user can accept the invitation depends on whether the account of the user in the identity provider has been configured to allow access to NEXT.


Note that the invitation emails right now do not indicate a SSO-only environment, and will contain a generic "Signup" link.


Note that this will impact also accounts that you might have created for NEXT's Customer Success/Support. There are different options to ensure smooth interactions with NEXT in a SSO-only setup:

  • You can add the NEXT account to your SSO IdP.

  • You can sign up for a free NEXT instance and reproduce the issue there. This can then be share with NEXT Support.

  • You can organize a screen share session with NEXT Customer Success and a user who has SSO access.


SP-Initiated or IdP-Initiated Sign-In

NEXT assumes an SP-initiated sign-in, i.e. users go to NEXT via https://TENANT.nextapp.co, and from there get pointed to the IdP for signing in.

Right now it is not possible to configure the application for a pure IdP-initiated sign-in experience due to technical limitations. In case IdP-initiated sign-in is needed (for example for an application directory for users), the application in the directory should be configured to go to the https://TENANT.nextapp.co URL.

Access Token Expiration

For technical reasons in how we must implement the support for SSO/SAML authentication, we cannot automatically refresh sessions of users. With the default token expiration time of 1h that would create a rather huge burden for the SSO users: They would need to re-authenticate explicitly every hour of work.

As a work-around, while we're looking into other options we decided to default the expiration times for id and access tokens to 8h when SSO via SAML is enabled. Please contact support for any concerns related to this topic.

Role Management

NEXT user roles are managed inside the NEXT administrative interface for existing (and invited) users.

If the IdP includes role claim in the token for a new user NEXT will assign this role to the user. Changing the role claim for an existing user will not propagate the changed role to NEXT.

Signing and Token encryption

NEXT does not support signing (AuthnRequestsSigned and WantAssertionsSigned in the SP SSO descriptor) nor token encryption.

Federation Metadata URL or file?

Typically the federation metadata can be exported from the IdP either as a XML file, or as a "live URL". NEXT generally prefers a live URL, as that means we are not coupled to (nor do we need to be involved) when the enterprise needs to change the metadata. The IdP is already accessible through the internet, so this generally should not be a problem. If there are concerns about exposing the metadata through a public URL, please do contact Customer Success.

Did this answer your question?