User authentication

10Duke Enterprise authentication is standards-based and enables all authentication related-activities, supporting the following:

  • Single sign-on (SSO)

    In SSO, a user can use the same credentials (typically a username and password) to log in once to a single application and access other online applications provided by the same vendor in the same session, without having to log in again.

  • Federated identity management (FIM)

    In federated identity management, two or more identity providers communicate with each other to authenticate an end user based on their “home” directory.

    Federation normally involves connecting two or more corporate identity providers. Each identity provider is responsible for authenticating any user it holds, and any connecting identity provider or client application trusts and relies on this authentication.

  • Two-factor authentication (2FA)

    2FA can be used in cases where a username and password alone are considered to be insufficient for authenticating an end user. 10Duke Enterprise supports one-time passwords (OTP) using software-based authenticator apps such as Google Authenticator and Microsoft Authenticator.

Authentication

In a standard setup with 10Duke Enterprise, your software application delegates the authentication of end users to 10Duke Enterprise. This means that your application relies on 10Duke Enterprise to authenticate end users when they log in.

When an end user tries to access your software application, the application starts the authentication process with 10Duke Enterprise. The application prompts the end user to log in on a login page (for example, by opening a browser), which then makes a request to 10Duke Enterprise to authenticate the user.

10Duke Enterprise checks that the user has provided the correct username (usually an email address) and a strong password. If the authentication is successful, a user session is established for the end user between 10Duke Enterprise and the browser.

Integration with external identity providers

You can also set up 10Duke Enterprise to trust user authentication done by an external identity provider.

A common setup is that 10Duke Enterprise receives an end user’s login request from your licensed software application and connects with an external identity provider to authenticate the user. From the identity provider’s perspective, 10Duke Enterprise acts as a client.

In this case, your software application receives the details on the authenticated user from 10Duke Enterprise, and it’s not visible to the application that an external identity provider was used.

Common use cases of using external identity providers include the following:

  • Your customer uses identity federation, where their end users need to be sent to their own identity provider for authentication.

  • You (the vendor) are managing data on your customers’ users in your identity provider (a “customer identity provider”), and 10Duke Enterprise always sends the user to this identity provider for authentication.

  • You support social login to allow users to use a social service such as Google or LinkedIn to log in.

Your client application can also authenticate users directly with an external identity provider, and pass an ID token received from the identity provider to 10Duke Enterprise. In this case, the communication with 10Duke Enterprise is done using OIDC and JWT bearer token authorization.

All of the above use cases require configuring a connection to the identity provider in 10Duke Enterprise. In use cases where 10Duke Enterprise connects directly to the external identity provider, configuring 10Duke Enterprise as a client at the identity provider’s end is also required.

Supported protocols

10Duke Enterprise supports the following protocols for authentication with client applications and external identity providers:

On this page