Selecting an Identity Provider for Keyfactor Command

Identity providers are used to provide a method for authenticating access to Keyfactor Command. Keyfactor Command supports Microsoft Active Directory and open authorization (OAuth) 2.0 compliant identity providers with a complete implementation of the OpenID Connect (OIDC) protocol. Keyfactor Command has been tested with the following identity providers:

• Active Directory

  Microsoft’s Active Directory has historically been the only identity provider supported by Keyfactor Command. With Active Directory, you can authenticate users defined in the Active Directory forest An Active Directory forest (AD forest) is the top most logical container in an Active Directory configuration that contains domains, and objects such as users and computers. to which the Keyfactor Command server is joined and users from forests in a trust relationship with this forest using integrated Windows authentication. Users may alternatively be authenticated to Keyfactor Command using Basic authentication when you opt for Active Directory as your identity provider. Active Directory supports user, group and computer accounts.

  Important:  Active Directory is not supported as an identity provider if you opt to install Keyfactor Command under Kubernetes.

• Keyfactor Identity Provider

  Keyfactor Identity Provider is a lightweight application that is easily installed in the same environment as Keyfactor Command to provide standalone authentication separate from Active Directory. It may be used directly to supply authentication or it may be used to federate authentication to another OAuth 2.0 compliant identity provider (e.g. Okta, Ping Identity). Keyfactor Identity Provider runs in a Linux-based Docker container. Keyfactor Identity Provider supports users and groups.

• Auth0

  Auth0 is a cloud-based OAuth 2.0 compliant identity and access management (IAM) solution owned by Okta.

A given Keyfactor Command server may be configured with only one type of identity provider (Active Directory or OAuth) but can support multiple OAuth providers. If desired, you may configure an environment with multiple Keyfactor Command servers and configure a different type of identity provider for each Keyfactor Command server. This is referred to as a hybrid implementation.

OAuth identity providers must meet the following requirements to work with Keyfactor Command:

• They must be a complete implementation of OpenID Connect. For more information, see:

  https://openid.net/developers/how-connect-works/

• They must enforce that usernames within the realm are unique.

• Users should not be allowed to choose their own usernames and/or email addresses for access to Keyfactor Command.

• The identity provider must be configurable using the fields provided in Keyfactor Command.

• The endpoint An endpoint is a URL that enables the API to gain access to resources on a server. used to acquire a bearer token must support POST Form URL requests leveraging the client_secrets, client-id, and grant_type parameters.

• The identity provider must support front channel logout.