Delegated password validation
SafeNet Trusted Access (STA) allows you to delegate password validation to a third-party password repository, such as Microsoft Entra ID (AD) or Active Directory Federation Services (AD FS).
Delegation means that no password synchronization is needed. Users can be synchronized or non-synchronized. Delegated password validation allows non-synchronized STA user accounts to use a password policy in STA for local accounts as long as the accounts exist in the third-party repository.
Delegated password validation is shown as a valid authentication method on the user screens on the STA Access Management console, but not on the user screens on the STA Token Management console.
Delegated password validation uses the OIDC Resource Owner Password Credentials (ROPC) flow, which allows an application to sign in the user by directly handling their password. The ROPC flow is compatible with any IdP that can handle the flow, such as Microsoft Entra ID, AD FS, and others.
Configure delegated password validation
Configuring delegated password validation involves these steps:
-
Configure the password repository:
This step includes gathering some information that is required for STA.
Configure the password repository
In general, the process involves registering STA as an application in the password repository. During the application registration process, you generate the following information:
-
OIDC client (or application) ID
-
OIDC shared secret
-
OpenID Connect metadata document, where you can find the following information:
-
OIDC token endpoint (token_endpoint)
-
OIDC token keys endpoint (jwks_uri)
-
Issuer (issuer)
-
You need to enter that information when you Configure delegated password validation in STA.
We provide detailed instructions for the following password repositories:
For other repositories, refer to the vendor documentation.
Register STA as an application in Microsoft Entra ID
In Microsoft Entra ID, you need to register STA as an application. To register an application in Microsoft Entra ID, you need to have the Application Administrator role.
When you register STA as an application in Microsoft Entra ID, you need to gather some information so that you can enter it in STA:
Where to find information in Microsoft Entra ID | Information in Microsoft Entra ID | STA fields (Settings > Delegated Password Validation) |
---|---|---|
App registrations | Application (client) ID | Application ID |
Client secret | Shared secret | |
OpenID Connect metadata document | OpenID Connect metadata document | Well-known configuration endpoint |
token_endpoint | Token endpoint | |
jwks_uri | Token keys endpoint | |
issuer | Issuer |
-
In Microsoft Entra ID, go to App registrations, and then select New registration.
-
Enter a Name for your STA application, select the Supported account types, and then select Register.
-
Copy and save the Application (client) ID. You need it later when you configure STA.
-
Select Certificates & secrets, and then select New client secret.
-
Select an Expires option and then select Add.
Delegated password validation stops when the secret expires.
-
Copy and save the client secret. You need it later when you configure STA.
The client secret is available only when you create it. If you don't copy and save it now, you will need to create a new client secret.
-
Select API permissions, and select Grant admin consent.
-
Select Overview > Endpoints.
-
In the list of Endpoints, copy and save the link for the OpenID Connect metadata document. You need it later when you configure STA.
In STA, you can use this endpoint to automatically populate the corresponding STA fields with the following values from the OpenID Connect metadata document:
-
token_endpoint
For example:
https://login.microsoftonline.com/7109293-######################36ef3/oauth2/v2.0/token
-
jwks_uri
For example:
https://login.microsoftonline.com/7109293-######################36ef3/discovery/v2.0/keys
-
issuer
For example:
https://login.microsoftonline.com/7109293-######################36ef3/v2.0
When using Microsoft Entra Conditional Access for all cloud apps, you must exclude STA password delegation app.
-
-
Go to Configure delegated password validation in STA, where you enter these values from Microsoft Entra ID.
Add an application group for STA in AD FS
In AD FS Management, you need to add an application group for STA.
When you create an application group for STA in AD FS, you need to gather some information so that you can enter it in STA:
Where to find information in AD FS Management | What it's called in AD FS Management | STA fields (Settings > Delegated Password Validation) |
---|---|---|
Add Application Group Wizard | Client Identifier | Application ID |
Secret | Shared secret | |
OpenID Connect metadata document | OpenID Connect metadata document | Well-known configuration endpoint |
token_endpoint | Token endpoint | |
jwks_uri | Token keys endpoint | |
issuer | Issuer |
-
In AD FS Management, right-click Application Groups and select Add Application Group
-
On the Add Application Group Wizard, select Server application accessing a web API, enter a Name and Description, and then click Next.
-
Copy and save the Client Identifier. You need it later when you configure STA.
-
Under Redirect URI, type any URL, click Add, and then click Next.
The redirect URL is not used for this configuration. For example, type https://sta.us.safenetid.com.
-
Select Generate a shared secret, and then copy and save the shared secret. You need it later when you configure STA.
The shared secret is not available after you click Next.
-
Click Next.
-
Under Identifier, type any URL, click Add, and then click Next.
The identifier is not used for this configuration. For example, type https://sta.us.safenetid.com.
-
Make sure that Permit Everyone is selected and click Next.
-
Under Permitted scopes, select openid and click Next.
-
On the Summary page, verify the application settings, click Next, and then click Close.
-
In ADFS Management > Services > Endpoints, ensure that the /adfs/oauth2/ endpoint is enabled.
-
Copy and save the path to /adfs/.well-known/openid-configuration, which is the OpenID Connect metadata document:
https://fs.<ADFS URL>.com/adfs/.well-known/oidc-configuration
Where the ADFS URL is the URL that is set in AD FS.
You need the well-known configuration URL later when you configure STA. In STA, you can use this URL to automatically populate the corresponding STA fields with the following values from the OpenID Connect metadata document:
- **token_endpoint** - **jwks_uri** - **issuer**
-
Go to Configure delegated password validation in STA, where you enter the values that you copied from AD FS.
Configure delegated password validation in STA
Enter the information that you copied from the password repository and the OpenID Connect metadata document.
-
On the STA Access Management console, select Settings > Delegated Password Validation.
-
Select Edit.
-
In the Account Details, enter the Application ID, Shared Secret, and Well-known configuration endpoint that you copied when you configured the password repository.
-
Select Load.
The Well-known configuration endpoint is the endpoint for the OpenID Connect metadata document. When you select Load, the Token endpoint, Token keys endpoint, and Issuer are populated. Alternatively, you can copy these values from the OpenID Connect metadata document.
The token endpoint and token key endpoint must begin with: https://
-
In the User Mapping section, select an item in the STA User Attribute list to use as the username in the password request.
For AD FS, select UPN or a user attribute that contains the UPN.
For example, if you select Email address, when the user enters their user name and password on the STA login screen, their email and password are sent in the access request.
-
To turn on delegated password validation, enable the toggle button in the upper-right corner.
-
Select Save.
Configure delegated password validation with Microsoft Entra ID for federated domains
You can configure STA delegated password validation with Microsoft Entra ID (AD) for federated domains. For example, you can use delegated password validation with Microsoft Entra ID when the Microsoft Entra ID domain is fully-federated with STA, as described in the online help for the SafeNet Trusted Access for Microsoft 365 application.
This configuration also allows non-synchronized STA user accounts to use a password policy in STA for local accounts as long as the accounts exist in Microsoft Entra ID.
Before you start, you need the following prerequisites:
-
STA is registered in Microsoft Entra ID as an enterprise application.
-
Microsoft Entra ID is configured in STA delegated password validation.
-
Delegated password validation works for non-federated domains.
To allow delegated password validation for federated domains, you need to create a new Microsoft Entra ID policy for the registered STA application. The policy is: AllowCloudPasswordValidation.
To configure the policy, you need the PowerShell AzureAD module.
-
If needed, run Windows PowerShell as administrator and install the AzureAD cmdlet:
Install-Module AzureAD
-
To connect to Microsoft Entra ID, sign in with an Microsoft Entra ID administrator account:
Connect-AzureAD
-
Create a service principal for your registered STA application using the Application ID (Get the application ID from Microsoft Entra ID > Enterprise Applications > Application):
New-AzureADServicePrincipal -AppId XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
-
Check the newly created service principal:
Get-AzureADServicePrincipal -SearchString "STA App Name"
-
Create a Home Realm Discovery (HRD) policy to enable AllowCloudPasswordValidation:
New-AzureADPolicy -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AllowCloudPasswordValidation`":true}}") -DisplayName EnableDirectAuthPolicy -Type HomeRealmDiscoveryPolicy
-
Validate the created policy:
Get-AzureADPolicy
-
Associate the Application ID and the Policy ID:
Add-AzureADServicePrincipalPolicy -Id XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX -RefObjectId XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX
Where Id is the Object ID of the application and RefObjectId is the Policy ID.
-
Verify the application policy association:
Get-AzureADPolicyAppliedObject -Id XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX
Where Id is the Policy ID.
-
Test your authentication.