Shared Identities

Shared Identities are entities of the Sentinet Repository that can be shared between many virtual services and their inbound and/or outbound endpoints. Sharing identities between many endpoints can be useful because:

  1. Changing shared identity affects all virtual services’ endpoints that use (reference) them, without the need to reconfigure virtual services themselves.
  2. Visibility and modifications of the Shared Identities can be controlled by User Roles and their Permissions.

To add a shared identity to a particular Repository folder (or Repository root), right click on the folder and select +Add -> Identity menu option, or select +ADD -> Identity menu option from the toolbar.

Add Identity
Figure. +Add -> Identity right-click and toolbar menu options.

Provide friendly Name and optional Description for your new Shared Identity. Select what identity type will be associated with this Shared Identity from the Identity Type drop-down box.

Select Identity Type
Figure. Selecting Name, Description and Identity Type.
Important

Once Identity Type is selected and new Identity is fully configured and saved, its identity type cannot be changed. For example, if you create shared identity of type Username/Password, provide specific Username and Password and save identity, you can later change its friendly name, description and its specific Username/Password, but you cannot change identity type to something else, like X.509 Certificate.

Sentinet supports the following Identity Types:

  • Username/Password - used by virtual services’ outbound endpoints which require Username/Password.

  • X.509 Certificate – identity created from uploaded PFX (PKCS #12) certificate file, which contains certificate’s private key.

  • X.509 Certificate Thumbprint – specifies certificate’s thumbprint that will be used to reference an existing certificate installed in the Sentinet Node’s local machine certificates Personal Store. Note: in this case the Sentinet Node process must have access to certificate’s private key.

  • OAuth Service Credentials – used for virtual services’ inbound endpoints when OAuth Security requires knowledge of signing secrets, and when these signing secrets are not configured using <signingSecrets> element.

  • OAuth Client Credentials – used for virtual services’ outbound endpoints that require Client Id and Client Secret which are not provided in the Policy configuration.

    Important

    Sentinet allows to specify clientId and clientSecret in the Policy configuration as explained in Client OAuth security configuration chapter. This leads to potential exposure of OAuth secrets in clear text in the Policy configuration. Alternative (and recommended) way to specify these two particular secrets, is to use explicit assignment of secrets via a Private or a Shared Identity as an endpoint’s Outbound Client Identity, in which case OAuth policy configuration is allowed to omit specifying Client Id and Client Secret settings.

  • Windows User – used to create specific Windows Active Directory shared user identity.

  • Microsoft Azure Service Bus – used to create Microsoft Azure Service Bus shared identity.

Selecting Identity Type from the drop-down changes the form beneath the drop-down to provide fields specific for selected type of identity.

Selected Identity Type
Figure. Example of a form specific to the selected Identity Type (Username/Password in this case).

Shared Identities can be inspected for their current usage (references) by the virtual services (DEPENDENCIES tab), and can be audited for any changes made to the identity (AUDIT tab). Shared Identities can also be exported and imported.

DEPENDENDCIES and AUDIT tabs
Figure. DEPENDENDCIES and AUDIT tabs.