Policies & Conditional Access

Overview and policies concepts

This guide explains the concept of policies within the WebADM framework. Policies are a crucial component of WebADM, allowing you to design who can access what, when, from which network(s), at what time, and under which conditions.

WebADM includes multiple policy layer:

Default application configuration (weight 1)
Per-group (weight 2)
Per-user (weight 3)
Per-application (weight 4-6)

Settings with the highest weight override those with the lowest weight.

For example, in OpenOTP: If the default OpenOTP settings (weight 1) require a LoginMode of LDAP only, but a user has a policy configured on their account with LoginMode set to LDAP+OTP, the user will need to provide both an LDAP password and an OTP to log in. If the LoginMode is reconfigured to LDAP+U2F at the client policy level (for a specific application or set of applications), then for that same user logging into that specific application, the LDAP password with FIDO authentication will be enforced.

Default policy (weight 1)

The first level of setting is defined under the applications configuration itself. Login on WebADM Admin GUI > Applications tab > APPLICATION_NAME > CONFIGURE. All web services and web applications provided by RCDevs can be configured here for the first level of settings. If no other settings are configured on a user, a group or in a client policy, then the default configuration will be applied.

Per-group policy (weight 2)

Applications can be configured per-group. Per-group policies override the default applications configuration. Login on WebADM Admin GUI, select a group on which you want to apply other settings than the default settings already configured on the application configuration itself. To be able to configure a policy on a group, the group must be activated under WebADM. When you are on the group object, click on Activate button > Proceed > Extend Object.

Your group is now Activated and ready for per-group policy. On the group object > Object Details > WebADM settings: NONE [CONFIGURE], click on CONFIGURE button.

On the next page, you can select which application you want to reconfigure for the selected group.

In this example, I reconfigure some settings for OpenOTP application:

OTP Type to SMS;
OTP PIN Prefix enabled for that group.

With these settings configured on the group, if a member of that group doesn't have a phone number and a PIN prefix already configured on their account, the login will fail with an error message like: "Account missing required data." This is unless those settings are reconfigured at another level with a higher priority, such as per-user or client policy settings.

Per-user policy (weight 3)

Applications can be configured per-user. Per-user policies override the default applications configuration and the per-group policies. Login on WebADM Admin GUI, select a user account on which you want to apply other settings than the default settings. To be able to configure a policy on a user account, the user must be activated under WebADM. When you are on the user object, click on Activate button > Proceed > Extend Object.

Your user is now Activated and ready for per-user policy. On the user object > Object Details > WebADM settings: NONE [CONFIGURE] click on CONFIGURE button.

On the next page, you can select which application you want to reconfigure for the selected user.

In this example, I changed the LoginMode to LDAPMFA and OTP Fallback to MAIL for the user.

With those settings configured on the user account, if the user doesn't have a FIDO2/OTP token registered or an email address configured on their account, the login will fail with an error message like: "Account missing required data."

Client policies

Create a client policy

A policy is configured for a specific application or for a group of applications/servers to which you want to apply the same global settings. For different applications, it is recommended to create different client policies.
Client policies override every other policy already configured for a group or user account. A client policy can also be defined per-group (weight 5) and per-network (weight 6) under the client policy configuration itself.

WebADM can match a policy with a client application through a Client ID value sent by the client integration with RCDevs plugins like OpenOTP Credential Provider for Windows/Mac OSX, LDProxy, and ADFS plugin. For Radius integrations, the NAS-Identifier or NAS-IP-Address attributes (by default), or the IP address of the client system can be used to match the policy. A dedicated section for client policy matching is described below in the documentation.

From the WebADM Administator portal, click on the Admin tab and you will find a box named Client Policies.

Click on it and on the next page, click on Add Client to create the policy object:

Enter a Common Name to easily identify the integration it is referring to, optionally add a description, and click on Proceed.

On the next screen, click on the Create Object button.

A client Policy object has now been created. We are now able to configure this client policy.

Default Application Settings (weight 4)

After the policy object creation, you should be redirected to the policy configuration.

Many settings can be applied here, such as which users/groups/networks the client policy will be applied to, allowed/excluded hours, which domain allowed... These are common settings, configure them as wished.

If you scroll down a little bit, you will find the setting named Default Application Settings.

Click on the checkbox on left and click the Edit button.
On the next screen, you are able to completely reconfigure a web service like OpenOTP for that specific application.

So, you can choose every setting you want and reconfigure the OpenOTP application for your client application. The client policy overrides the default application settings, user and group settings.

After editing the configuration, you can click on the Apply button to save the configuration and leave the Web Service configuration page. You will be redirected to the policy configuration page and will see your setting added in the previously empty box. Click the Apply button one more time to save the client policy configuration.

Per-group Application settings (weight 5)

In the same way, a client policy can be overridden for a specific group.
In Per-Group Extra Policies menu, enable the group list setting and then click the Select button. You are now in the edition mode, and you can select the group you want in the left LDAP tree just by clicking on it.

In this example, I reconfigured the setting LoginMode to LDAPU2F for the group CN=domain admins,CN=Users,DC=rcdevsdocs,DC=com. I disabled the OTPFALLBACK method, enabled the Fake Challenge protection, enabled the Password Check feature to see if the password is leaked, and required a Badge-in/check-in operation to increase the security for that privileged group.

Per-group policy overrides the default application settings.

Per-Network Application settings (weight 6)

In the same way, a client policy can be overridden for login coming from a specific network.
In Per-Network Extra Policies section, check the box on the left of Internal Networks setting and put the network value for which network you want to reconfigure the policy. In Application Settings (Internal), click the Edit button, and you can now reconfigure the application you want for the specified network.

In this example, I reconfigure the setting LoginMode to LDAP for login requests coming from 192.168.3.0/24 network.

Per-Network policy overrides Per-Group Application settings and Default application settings for requests coming from that network.

To be able to use that feature, your client application should be configured to forward the user IP address to OpenOTP.

Dynamic Application Settings

The Dynamic application settings allow you to dynamically change setting of Web applications or Web Services when source IP is coming from a botnet or public VPN endpoints.

Level 1: This policy mode will enter in the Step-Up mode where Step-Up settings can be defined below.
Level 2: This policy mode completely deny the access to the system when IP source is considered as botnet IP and apply the Step-Up settings when IP source is considered as public VPN endpoints.

Botnet and public VPN endpoint IP addresses are fetched from large public databases on the internet, and we provide a microservice on RCDevs cloud infrastructure for these checks. If communications with https://cloud.rcdevs.com are not allowed from your WebADM server, this setting cannot be used.

In the following example, I configured the Risk-based policy mode to Level 2.

The Step-Up mode will enforce:

LDAP and OTP factors requested for the authentication;
Push Login enabled;
Few settings for account blocking in case of login failure.

For the Step Down mode, I enforced a badge-in/check-in operation from OpenOTP Token or the User Self-Services Desk, and the required factor is switched to LDAP.

Once settings are applied, you can see the following from the Client Policy menu:

Note that the Step Down mode is not triggered automatically; you have to manually enable it by clicking [CHANGE MODE] button.

For example, you can manually Step-Down, Step-Up or Deny the access for a specific period.
This settings can also be enforced when it matches Per-Group and/or Per-Network policies. By default, it is applied to the default application setting policy (weight 4) if nothing else specified is specified.

Select the desired mode between the following options:

Click on the Change Mode button to apply the desired mode.

Press Ok on the previous screen. You will then be redirected to the Client Policies menu where you can see an overview of your policy.

Contract Signing access condition

RCDevs has implemented in Client policy settings the ability to require users to sign a document before they can access a system. This document could be an NDA, Terms and Conditions, or any other agreement that needs to be signed prior to accessing the system.

The document can be an HTML form, a PDF located on the file system or accessible through a URL. In that example I used a document stored on the file system. For OpenOTP Cloud tenants, only HTTP(S) scheme is allowed.
Once the document has been signed by your user(s), the signed version can be sent to a recipient. Only one recipient can be configured. If you want more than one person to receive the signed document, you have to create a mailing list on your mail server which include the desired recipients.
Once the document is signed, you can also choose if you want to store it in the SQL database of WebADM server in the Record table or not.
The desired Signing mode can be configured, you can choose between Standard and Advanced. Please refer to OpenOTP Signature documentation to get details on the signature types. If Advanced mode is chosen, you can configure the scope (Local CA, Global CA or eIDAS) that you want to use. This can be configured under Default Application Settings > MFA Authentication Server > Confirmation & Signing section.
The signature timeout is corresponding to the time that the signature request is available on the backends and the time the user has to sign the document. Once reached, the signature request is expired on the backends and user will have to restart the login from scratch to trigger a new signature request. Once the document is signed, the user will be able to log in.
Signature validity correspond to the validity of the signed document. Once exceeded, the document will need to be signed again by the user.

If the document had any modification then the user will be automatically prompted to sign the new version before being able to authenticate on the system.

How to match my client policy with my client application

The matching between a client policy configured under WebADM and a client application can be done in different ways.

Client ID

With RCDevs products/plugins (e.g : OpenOTP Credential Provider, ADFS plugin, Spankey client...) a setting named Client ID can be configured during the plugin/application installation or in its configuration file.

For the matching operation, the Client ID value sent by the client application must match the client policy object name or the Client Name Alias value configured in your client policy.

In the below example with OpenOTP Credential provider for Windows, I configure the Client ID value with the hostname of my computer. In my Client policy created in that documentation, I will add the computer hostname in the Client Name Alias setting. You can define multiple Client Name Aliases value to match many clients with only one client policy. You just have to put values comma-separated.

Client ID configuration on the Windows Client:

On my policy configuration, I'm adding the Client ID value in the Client Name Alias setting :

Nas-Identifier

In some third-party product using RADIUS APIs, you can define a setting named NAS-Identifier. In this example with Pulse Secure, we configure a NAS-Identifier named MyPulse. Create a client policy object for your Pulse Secure inegration and configure the NAS-Identifier value in the Client Name Alias setting of your client policy.

Client application IP(s)

If you are not able to configure a NAS-Identifier, NAS_IP_Address, or a Client ID on your client application, you can match a client policy with the IP address of your client application. The IP address of your client should be configured in the client policy itself in the Client Name Aliases setting.

Put the IP address of your client here, and the policy will match during the authentication process.

OpenID and SAML client applications

For OpenID and SAML applications integrated through RCDevs Identity Provider, you can use the Issuer information to match your client policy.
Create your Client Policy and configure the Issuer value of your SAML/OIDC client application in the Client Name Alias setting.

Web Application policy

You can define client policies for User Self-Registration, User Self-Service Desk, Secure Password Reset, Helpdesk applications, and for logging into the WebADM Admin portal. To do this, simply create a client policy using the short name of the application or by putting the shortname in the Client Name Aliases setting of your cient policy. The short names are:

PwReset: Secure Password Reset application;
SelfDesk: User Self-Service Desk application;
Admin: WebADM Admin portal;
Helpdesk: Help-Desk application and login tester.
OpenID: RCDevs Identity Provider login page.

Create a client policy for the web application you want and reconfigure the application settings under the client policy configuration menu.

[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] New openotpNormalLogin SOAP request
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] > Username: john.doe
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] > Client ID: PwReset
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] > Source IP: 192.168.3.205
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] > Settings: LoginMode=OTP,ChallengeMode=Yes
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] > Options: -BLOCK,-CTX
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Enforcing client policy: PwReset (matched client ID)
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Registered openotpNormalLogin request
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Resolved LDAP user: CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com (cached)
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Started transaction lock for user
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Found 1 user emails: yoann@rcdevs.com
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Found 50 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,OfflineExpire=30,MobileTimeout=30,EnableLogin=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,U2FPINMode=Discouraged,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Found 2 request settings: LoginMode=OTP,ChallengeMode=Yes
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Found 4 user data: LastOTP,TokenType,TokenKey,TokenState
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Last OTP present (valid until 2024-07-12 15:25:08)
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Found 1 registered OTP token (TOTP)
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Requested login factors: OTP
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Authentication challenge required
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Started OTP authentication session of ID XlvdKxSE8rxN6miE valid for 90 seconds
[2024-07-12 15:20:29] [127.0.0.1:45030] [OpenOTP:J7J6EMM8] Sent login challenge response
[2024-07-12 15:20:29] [192.168.3.205:54432] [PwReset:J7J6EMM8] OpenOTP authentication challenge
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] Enforcing client policy: PwReset
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] New login challenge (OpenOTP)
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] > Session: XlvdKxSE8rxN6miE
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] > Username: john.doe
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] > LDAP Password: xxxxxxxxxxxx
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] > OTP Password: xxxxxx
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] Sending openotpChallenge request
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] New openotpChallenge SOAP request
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] > Username: john.doe
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] > Session: XlvdKxSE8rxN6miE
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] > OTP Password: xxxxxx
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] Found authentication session started 2024-07-12 15:20:29
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] Started transaction lock for user
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] TOTP password Ok (token #1)
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] Updated user data
[2024-07-12 15:20:39] [127.0.0.1:56266] [OpenOTP:J7J6EMM8] Sent login success response
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] OpenOTP authentication success
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] Resolved LDAP user: CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com (cached)
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] LDAP password Ok
[2024-07-12 15:20:39] [192.168.3.205:54441] [PwReset:NX3PWVHU] Login session started for CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com

Check policy matching through WebADM logs

Try performing an authentication on your client application, then log in to the WebADM GUI, navigate to the Databases tab. In the System Log Files section, click on either the WebADM Server Log file or the WebADM Shared Event Logs and look for your authentication request.

[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] New openotpNormalLogin SOAP request
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] > Username: Administrator
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] > Domain: RCDEVSDOCS
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] > LDAP Password: xxxxxxxxxxxx
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] > Client ID: Netscaler
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] > Source IP: 172.16.0.252
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] > Context: 8defa604ffca0f7da1e8d00ae6d22148
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Enforcing client policy: Netscaler (matched client ID)
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Registered openotpNormalLogin request
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Resolved LDAP user: CN=Administrator,CN=Users,DC=rcdevsdocs,DC=com (cached)
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Resolved LDAP groups: ap_exclude,key admins,enterprise key admins,cert publishers,group policy creator owners,enterprise admins,schema admins,domain admins,administrators,organization management,denied rodc password replication group,remote desktop users,kpdjhbvjh,rgreg (cached)
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] New openotpNormalLogin request (RCDEVSDOCS\Administrator)
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Started transaction lock for user
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Found 1 user emails: Administrator@rcdevsdocs.com
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Found 50 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=Yes,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,OfflineExpire=30,MobileTimeout=30,EnableLogin=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,U2FPINMode=Discouraged,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Found 11 user data: OTPPrefix,TokenType,TokenKey,TokenState,TokenID,TokenSerial,Token2Type,Token2Key,Token2State,Token2ID,Token2Serial
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Found 2 registered OTP tokens (TOTP,TOTP)
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Requested login factors: LDAP & OTP
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] LDAP password Ok
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Authentication challenge required
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] OTP authentication challenge (valid 90 seconds)
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Started OTP authentication session of ID UyK0y0A7l8JFOmTR valid for 90 seconds
[2024-07-08 13:00:24] [127.0.0.1:38282] [OpenOTP:ZEWKHXAR] Sent login challenge response
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] New openotpChallenge SOAP request
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] > Username: Administrator
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] > Domain: RCDEVSDOCS
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] > Session: UyK0y0A7l8JFOmTR
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] > OTP Password: xxxxxx
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] Found authentication session started 2024-07-08 13:00:24
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] New openotpChallenge request (RCDEVSDOCS\Administrator)
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] Started transaction lock for user
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] TOTP password Ok (token #1)
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] Updated user data
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] Sent success response

You can show in the previous transaction logs, that the Nas-Identifier passed by the client application is NETSCALER and the client match with the corresponding policy.

[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR] > Client ID: Netscaler
...
[2024-07-08 13:01:07] [127.0.0.1:46642] [OpenOTP:ZEWKHXAR]] Enforcing client policy: Netscaler 
(matched client ID)

My client policy is applied and settings defined in this policy will be required during an authentication coming from that client.