Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

SafeNet IDPrime Virtual Server

Setting up Tenant Utility

search

Setting up Tenant Utility

This is provided with the SafeNet IDPrime Virtual solution, the Setup Tenant Utility is a simple command-line utility used to manage operations related to tenant(s). Update values in (after the update, remove the angle brackets) for the required parameters.

The following operations can be performed:

Creating a Tenant

Perform the following steps to create a tenant:

  1. Open the terminal, and run the tenant onboarding utility by executing the following commands:

    • Docker: 

    

        docker exec –it <idprime-virtual-server-container-name> sh

    • Kubernetes: kubectl exec –it <idprime-virtual-server-kubernetes-pod-name> -n<namespace> sh

    • RHEL 8 or 9 with podman environment: podman exec -it <container-name> sh

      Where:

      namespace must be entered as created in step 1 of Deploying IDPrime Virtual Server in Kubernetes

  2. Run the tenant creation utility using one the following commands based on the SafeNet IDPV version you are configuring:

    IDPV v2.4.1

    

        setuptenant create -i Config/azure-test.json -p Config/policy-configuration.json -a <client_secret> -k <true or false> -u <true or false> -c <IDPV> -n <tenant_name>

    IDPV v2.5

    

        setuptenant create -i Config/idp-configuration.json -p Config/policyconfiguration.json –a <idp secret> -k true (or false) -n <tenant name> -c <tenant category> -m false (or true) -s <swsconfig.json> -u false (or true) -j false (or true) -f true (or false)

    IDPV v2.6

    

        setuptenant create -i Config/idp-configuration.json -p Config/policyconfiguration.json –a <idp secret> -k true (or false) -n <tenant name> -c <tenant category> -m false (or true) -s <swsconfig.json> -u false (or true) -j false (or true) -f true (or false) -o false (or true)

    IDPV v2.9

    • Create Tenant With the PIN Policy

      The IDPV solution includes a default (predefined) PIN policy. When creating a tenant, administrators can customize the default PIN policy, replacing it with a version updated as per their preferred configuration. For a sample policy-configuration.json file and guidance on modifications, refer to the User Logon (Token Policies) section.

      Note

      The -p parameter can be omitted when creating a tenant using the default PIN Policy.

      Command:

      

      setuptenant create -i Config/azure-test.json -p Config/policy-configuration.json -a <client_secret> -k <true or false> -u <true or false> -c <IDPV> -n <tenant_name>

      Example:

      

      setuptenant create -i Config/idp-configuration.json -p Config/policy-configuration.json -a \"test4eba\" -n test-tenant -k true

    Where:

    • -i --idpConfigFilePath : accepts json file for idp configuration (file provided for IDPV installation) (Mandatory)
    • -p --tokenPoliciesPath : accepts json file for sample policy (Optional)

    • -a --IdpA : accepts IDP secret (Mandatory)

      Client Secret value for various IDPs can be located in the respective IDP configuration.
      Regenerate the client secret if the it begins with a hyphen (-).

    • -k --exportKeys : accepts the HSM export key flag as either true or false (Optional) and if SKS flag is set to true, -k flag is always set to false.

      For HSM, the default value is set true. However, if KeySecure is configured, the default value is auto-set to false.

      -k is set to true,
      • when the HSM is configured for the export mode.
      • to download the token offline bundle to support the offline mode feature.

    • -n --tenantName : accepts a tenant name.

    • -c --tenantCategory : provide tenant category from IDPV or Signature Web Service (SWS)

      The default value is set to IDPV if -c is not specified. (Optional)

    • -m --sksMode : accepts the HSM SKS flag as either true or false (Optional)

    • -s --swsConfigFilePath : accepts a json file as a sws configuration file.

    • -u --IsAutoCardCreationEnabled : accepts true or false for IsAutoCardCreationEnabled flag (Optional). It enables/disables the automatic smart card creation for tenant if no smart card exist for the user. The default value is set to true. If -u is not specified, then the default value is used.

      Tenant created with -u: true allows auto creation of smart card. Tenant created with -u: false does not allow auto creation of smart card.

    • -j --IsAutoRefreshSigningKeyEnabled : Accepts true or false. The default value is false. If it is set to true, the signing key gets rotated automatically on the IDPV server. This flag is added in SafeNet IDPV v2.5.

      The signing key is rotated,

      • At period intervals for which the interval value is set in the appsettings file (KeyRotationRefreshIntervalInHrs).
      • At the time of Authorization failure (due to the signing key mismatch).

      If it is set to false, the administrator has to manually update the IDP signing key, in case it gets changed at the IDP level.

      The flag (-j) is applicable for Azure tenants only.

    • -f --IsOfflineFallbackEnabled : The default value is true. This flag is used to enable or disable the Offline fallback feature. When enabled (-f: true), it allows you to go offline when TPM is FIPS compliant, but the keys are non FIPS. This flag is added in SafeNet IDPV v2.5.

      You can set this flag to false using the setuptenant update command.

      This feature has a dependency on -k (HSM export key flag). So, if you create a tenant with -k: false, -f will also be set to false, and then you will not be able to configure it. If you set -k: true, the value of -f will be configurable (true/false).

    • -o --IsAutoOfflineBundleDownloadEnabled : Accepts true or false. The default value is false. If it is set to true, the offline bundle is downloaded at the client side, after the user enters a correct PIN. This flag is added in SafeNet IDPV v2.6.

      You can set this flag to false using the setuptenant update command.

      This feature has a dependency on -k (HSM export key flag). So, if you create a tenant with -k: false, -o will also be set to false, and then you will not be able to configure it. If you set -k: true, the value of -o will be configurable (true/false).

    • --help

    • --version

      The /publish/Config path is mapped with host directory /var/thales/config using docker run command in deployment section. So path used inside container must be the same, i.e. /publish/Config.

    After running the above command, a Tenant ID is generated and saved as a text file in the /publish/Tenant/<TenantGUID>.txt directory, and displayed on the console.

  3. Copy the Tenant ID to the machine using the following command:

    

    docker cp idprime-virtual-server-containername:/publish/Tenant/<TenantGUID>.txt <location on host>

    For RHEL 8 or 9 with podman environment, the command is:

    

    podman cp idprime-virtual-server-containername:/publish/Tenant/<TenantGUID>.txt <location on host>

Deleting a Tenant

Execute the following command:



    setuptenant delete –t <tenantId>

Example:



        setuptenant delete –t "8b6ad028-3266-4718-88f3-11ace3b90d78"

Where, -t : accepts the Tenant ID (Mandatory).

Updating a Tenant

Execute the following command:



        setuptenant update –t <tenantId> -i Config/idp-configuration.json -p Config/policy-configuration.json –a <idp secret> -s <swsconfig.json> -n <tenant name> -u false (or true) -j false (or true) -f true (or false) -o false (or true)

Example:



        setuptenant update –t "8b6ad028-3266-4718-88f3-11ace3b90d78" -i Config/idpconfiguration.json

Where:

  • -t --tenantId : accepts Tenant ID (Mandatory)
  • -i --idpConfigFilePath : accepts json file for idp configuration
  • -p --tokenPoliciesPath : accepts json file
  • -a --IdpA : accepts IDP secret Client Secret value for various IDPs can be located in the respective IDP configuration.
  • -s --swsConfigFilePath : accepts a json file for sws configuration.
  • -n --tenantName : accepts tenant name.
  • -u --IsAutoCardCreationEnabled : accepts true or false for IsAutoCardCreationEnabled flag (Optional). It enables/disables the automatic smart card creation for tenant if no smart card exist for the user. For more information about swsconfig.json, refer to the IDPV package.

  • -j --IsAutoRefreshSigningKeyEnabled : Accepts true or false. The default value is false. If it is set to true, the signing key gets rotated automatically on the IDPV server.

    The signing key is rotated,

    • At period intervals for which the interval value is set in the appsettings file (KeyRotationRefreshIntervalInHrs).
    • At the time of Authorization failure (due to signing key mismatch).

    If it is set to false, the administrator has to manually update the IDP signing key, in case it gets changed at the IDP level.

    The flag is applicable for Azure tenants only.

  • -f --IsOfflineFallbackEnabled : The default value is true. This flag is used to enable or disable the Offline fallback feature. When enabled (-f: true), it allows you to go offline when TPM is FIPS compliant, but the keys are non FIPS.

    You can set this flag to false using the setuptenant update command.

    This feature has a dependency on -k (HSM export key flag). So, if you create a tenant with -k: false, -f will also be set to false, and then you will not be able to configure it. If you set -k: true, the value of -f will be configurable (true/false).

  • -o --IsAutoOfflineBundleDownloadEnabled : Accepts true or false. The default value is false. If it is set to true, the offline bundle is downloaded at the client side, after the user enters a correct PIN.

    You can set this flag to false using the setuptenant update command.

    This feature has a dependency on -k (HSM export key flag). So, if you create a tenant with -k: false, -o will also be set to false, and then you will not be able to configure it. If you set -k: true, the value of -o will be configurable (true/false).

• At least one of the three flags, -i, -p, or -a is mandatory.
• In case of kubernetes, Pods must be updated if configuration files under /var/thales/hsm are updated.

For more information about idp-configuration.json file parameters, refer to step 4 of Updating Identity Provider Parameters.

Listing all Tenants

Execute the following command:



        setuptenant list -l true

Where,
-l : shows all tenants (Mandatory)

List tenant's details

Run the following command:



        setuptenant list –l false -t <tenantId>

For example,



        setuptenant list –l false -t "8b6ad028-3266-4718-88f3-11ace3b90d78"

Where,
-t : accepts the Tenant ID (Mandatory)

Listing a Tenant’s Information

Execute the following command:



        setuptenant usage -l true

To view the usage details for a single tenant:



        setuptenant usage -l false -t <tenantId>

For example,



        setuptenant usage -l false -t "8b6ad028-3266-4718-88f3-11ace3b90d78

Where:
-l: shows all tenants (Mandatory)
To view the usage details for all tenants: true

-t --tenantId : accepts Tenant ID (Mandatory)
Note: -t tag is mandatory when -l tag is false.

Additional Standard Tokens Validated with SafeNet Access Exchange for StepUp:

Aspect LOA Value ACR Value Token
Step Authentication Flow Configured pwd  0  LDAP Password

 

 

 otp 1 SAS Token 
cba    2 Certificate Base Authentication (CBA)
Test ID Test Scenario Precondition Test Steps Expected Result Actual Result Remarks
TC01 App1 Authentication using LDAP Password User: kapil with App1 (Postman) 1. Launch App1 (Postman). Successful authentication to App1 using LDAP Password.

FALSE

User will be logged in without ldap credentials

In the above flow the User will be logged in without ldap credentials because authentication flow is conditional and the condition is to check if acr value is passed from sp.
2. Enter LDAP Password.
TC02 App2 Authentication - Scenario 1.1 SSO session of App1 is live; ACR value not provided 1. Launch App2 (WordPress). System prompts only for OTP (simple SSO, no step-up).

FALSE

User will be logged in without asking for OTP

In the above flow the User will be logged in without asking for OTP because authentication flow is conditional and the condition is to check if acr value is passed from sp.
(SSO live; ACR not sent) 2. Attempt authentication with only SSO context.
TC03 App2 Authentication - Scenario 1.2 SSO session of App1 is live; ACR is pwd (less restrictive than required Auth Flow) 1. Launch App2 (WordPress). No OTP is prompted since pwd is less restrictive than the defined Auth Flow.

TRUE

User got logged in directly because SSO session of App1 is live with LDAP creds

User will be logged in directly because SSO session of App1 is live with LDAP creds
(SSO live; ACR is pwd) 2. Attempt authentication with SSO session.
TC04 App2 Authentication - Scenario 2.1 SSO session of App1 is live; ACR is otp (similar in restrictiveness to Auth Flow) 1. Launch App2 (WordPress). System prompts only for OTP as the provided ACR meets the flow requirements.

TRUE

User is prompted for OTP only as SSO session of App1 is live with LDAP creds

User is prompted for OTP only as LDAP SSO session of App1 is live with LDAP creds
(SSO live; ACR is otp) 2. Attempt authentication with live SSO session.
TC05 App2 Authentication - Scenario 2.2 No active SSO session from App1; ACR is otp 1. Launch App2 (WordPress). Successful authentication using LDAP Password and OTP as required.

TRUE

User is prompted for OTP and LDAP password as there is no live session.

User is prompted for OTP and LDAP password as there is no live session.
(No SSO live; ACR is otp) 2. Enter LDAP Password.
3. Provide OTP.
TC06 App2 Authentication - Scenario 3 SSO session of App1 is live; ACR is cba (stronger than required Auth Flow) 1. Launch App2 (WordPress). System prompts for OTP only

TRUE

System prompts for OTP only

However gets error after entering correct OTP.

ERROR (no-match-acr): No matching acr values.

CBA is not triggered because the authentication flow is defined as LDAP Password + OTP 
(SSO live; ACR is cba) 2. Attempt authentication with SSO session.
TC07 App2 Authentication - Scenario 3.1 SSO session of App1 is live; ACR is cba (stronger than required Auth Flow) 1. Launch App2 (WordPress). System prompts for OTP only and select the certificate and gets logged in.

TRUE

System prompts for OTP only , user selects the Certificate and get logged in.

CBA is triggered because the authentication flow is defined as LDAP Password + OTP + CBA
(SSO live; ACR is cba) 2. Attempt authentication with SSO session.

On this page