Service Provider edition

Overview and Prerequisites

This documentation covers various aspects of setting up and configuring RCDevs solutions for Managed Security Service Provider (MSSP). It encompasses understanding core components and dependencies, implementing a multi-tenant setup for deploying a cloud environment, and offering various RCDevs solutions as services for your customers. Each chapter delves into specific topics and offers practical guidance for readers to follow.

Performing this type of setup requires a solid understanding of the following technologies/concepts:

• WebADM and all its dependencies mechanisms,
• Public Key Infrastructures,
• Reverse Proxy technologies,
• LDAP backend knowledge,
• High availability concepts for cloud application deployments and hosting.

The setup can be virtualized or deployed on physical machines. The server sizing will depend on the number of customers/users you plan to onboard. Refer to the RCDevs Server Sizing documentation. RCDevs recommends beginning with an infrastructure that offers flexibility in adding resources later if necessary. The advised Linux operating systems for RCDevs components are RHEL, Rocky, CentOS, Debian, or Ubuntu. While other operating systems might function, they have not undergone testing.

In this documentation, we will detail the process of setting up the entire infrastructure in SAAS mode. To avoid redundancy with existing RCDevs documentation, we will incorporate multiple references to other documents within each section. These references will guide you through the setup of specific components.

This documentation is intended for professionals in the field of hosting services, as well as system, network, and security engineers. It caters to those seeking to offer services related to MFA, IAM, PKI, SSO, LDAP, e-Signature, SSH key solutions and Self-Services.

The main steps to deploy an infrastructure of this kind are as follows:

1. Set up the LDAP backends and master-master replication. For this setup, using the RCDevs directory is highly recommended to avoid directory limitations (e.g., duplicate usernames across different tenants).
2. Set up the SQL backends and master-master replication;
3. Set up WebADM backends in cluster mode;
4. Set up WAProxy or reverse proxy frontends;
5. Tenant Creation;
6. Client integration with a tenant.

The architecture we are going to demonstrate looks like below:

In that schema, the PUBLIC and PRIVATE DMZ/LAN on the right refer to the service provider infrastructure. In the WAN area, the services and applications (HTTPS endpoints) are exposed from the service provider infrastructure to the internet for its customers, accessible through dedicated tenant URLs. On the left side, in the LAN/DMZ area are the customers' infrastructures, which consume the exposed services and applications from their tenant.

This setup requires a Service Provider/MSSP license. Without this specific license type, service provider features will not be accessible. To obtain the necessary license, please contact the RCDevs Sales team, as this license type cannot be purchased through the RCDevs online shop.

RCDevs Directory Server Setup (LDAP service)

The highly recommended LDAP backend for this setup is the RCDevs Directory server. For setting up the RCDevs Directory server in cluster mode, refer to the RCDevs Directory Server documentation.

While it's possible to deploy LDAP services on the same machines, for the sake of performance and availability, it's recommended to contemplate migrating the LDAP service to dedicated servers.

The RCDevs Directory setup follows the same procedures as regular setups. It's crucial to note that this component should be deployed in cluster mode for production deployments.

While it's possible to deploy LDAP services on the same machines, for the sake of performance and availability, it's recommended to contemplate migrating the LDAP service to dedicated servers.

Opting for any other LDAP solution might impose limitations on the setup or could potentially result in non-functioning.

Utilizing the RCDevs Directory server offers several advantages. Firstly, it empowers you to provide customers with the ability to synchronize their on-premise Active Directory to their WebADM cloud tenant using the Active Directory synchronization script supplied by RCDevs.
Given that a majority of the enterprise market employs Active Directory, this synchronization capability offers customers the convenience of syncing their accounts, groups and LDAP structure to their WebADM cloud tenant.

Additionally, the RCDevs Directory server supports hot backups and allows replication of the entire Active Directory structure. The RCDevs directory is designed to support AD-formatted passwords, including NTLM hashes (MD4 by default), enabling seamless integration with Active Directory environments and allowing for secure, direct authentication. This compatibility ensures that AD passwords can be stored and validated in their native MD4 hash format within the RCDevs OpenLDAP directory, preserving security standards and simplifying user management across systems.
The schema also supports a list of UIDs for the username values. In Active Directory, users often log in using their SAMAccountName or UserPrincipalName attributes. Both of these values can be synchronized with RCDevs Directory for the same account. Notably, the UID values used by end-users for authentication can be identical across multiple tenants; a functionality that doesn't align with the design of Active Directory.

The same OpenLDAP database serves all customers. RCDevs has implemented protective measures within the WebADM software to ensure that tenant owners access only their own data and not the data of other tenant owners. Customers are also empowered to perform their own backup and restoration of portions of their LDAP treebase through LDIF exports/imports. Service providers can periodically perform LDIF exports to back up/restore specific portions of data, or they can selectively trim data from LDAP backups to restore data for a specific tenant.

Tenant owners must not have the ability to access the RCDevs Directory database through LDAP APIs, considering that the same LDAP database serves all hosted tenants.

During the setup of the RCDevs Directory service, permissions will be configured. This process involves creating a super_admin account (WebADM administrator account) and a service account (WebADM Proxy user account), with permissions already properly configured. RCDevs recommends enabling the "Proxy User Admin" setting in tenants' configuration. Doing so eliminates the need to manually configure LDAP permissions each time a new tenant is created or when onboarding a new customer and setting up their LDAP structure. This setting can be enabled in the tenant configuration through the master/admin tenant. The Master/Admin tenant provides full capabilities to create tenants and manage customers. From the master tenant, you can control and monitor all aspects, including license allocation, tenant creation, tenant administration, and logs.

SQL Setup

WebADM requires an SQL service to be configured in cluster mode with master-master replication. There are no limitations on the choice of the database management system (DBMS) for this setup. RCDevs has tested this configuration with MariaDB, MySQL and MSSQL DBMS.

While deploying SQL services on the same machines is feasible, it is recommended to improve performance and availability by relocating the SQL service to dedicated servers or to the servers hosting the LDAP services. This approach allows you to designate certain servers as 'Store' servers.

For installating and configuring MariaDB cluster with a Master-Master replication, you can refer the WebADM Cluster and Failover Setup Guide

For other DBMS, please refer to the provider's documentation.

WebADM Setup

Public Key Infrastructure consideration

RCDevs solutions consistently include a Public Key Infrastructure (PKI) component. In this setup, the PKI service is shared among all hosted tenants.

Regarding the PKI setup, you have two choices:

• Set up a new standalone CA (included in the default WebADM setup);
• Issue a subordinate CA from another CA and import it before the WebADM setup, as explained in the WebADM as Subordinate Certificate Authority documentation.

During the tenant creation process, you will need to provide certain details about the customer organization for which you are creating a tenant. These details include:

• Organization Name
• Organization Identifier

These two pieces of information within the tenant configuration serve to identify the tenant owner (customer) and will be incorporated into all issued certificates for each respective tenant. As a best practice, the certificate authority information should accurately identify the Service Provider. It's important to note that the PKI service should be configured in high availability mode, which is included as part of the default setup.
Re

WebADM installation

The WebADM setup remains consistent with the instructions detailed in the WebADM Cluster and Failover Setup Guide.
For production usage, it's essential to configure WebADM in cluster mode of at least 2 nodes.
To initiate the WebADM setup process, it's imperative to first establish the LDAP infrastructure that your WebADM cluster will utilize. Without this LDAP infrastructure in place, setting up WebADM will not be feasible.

In the scenario where you're building a cluster where nodes are across different sites or data centers, it's crucial to ensure that latencies between the sites do not surpass 200 ms. This is necessary to prevent any adverse impact on services and replication performance. This documentation outlines a setup involving two backend nodes for each deployed infrastructure. If necessary, you can consider forming a cluster of four nodes or more, distributing them across different data centers or zones. RCDevs advises having at least one instance of each service (LDAP, SQL, WebADM, Reverse Proxy) on each site if you split your cluster.

The WebADM Manager APIs provide service providers with powerful automation capabilities, including tenant creation, default admin user setup, and applying standardized configurations for apps and services. All functionalities available through the Manager APIs in the WebADM Enterprise Edition are fully supported in the WebADM Service Provider Edition.

An important setting that must be configured in the webadm.conf file for MSSP deployment is public_hostname. This setting defines the DNS name through which the admin tenant will be accessible. All other tenant names will be derived from this base hostname.

For example:

public_hostname admin.openotp.com

With this configuration, the URL admin.openotp.com will provide access to the master (admin) tenant. Other tenants will be accessible using the format tenant_id.openotp.com, where tenant_id is the unique identifier for each tenant.

WAProxy / Reverse Proxies

The Reverse Proxy servers mentioned in this documentation are based on WebADM Publishing Proxy (WAProxy).
However, it's advisable to consider utilizing a professional reverse proxy solution such as HAProxy, F5, or similar options. Adopting such an appliance offers several advantages, including the provision of DDoS protection, safeguarding against bot attacks, and additional features to bolster the security and resilience of your services. RCDevs validated this setup with HAProxy and F5.
It's important to note that other solutions may not fulfill all the necessary requirements, and RCDevs might not be able to offer technical assistance for alternative solutions.

In order to provide admin, web applications and web services accesses, you will have to publish the WebADM HTTP endpoints through a reverse proxy, WAF or WAProxy infrastructure.

By default, WebADM is listening on the following ports:

• 80 TCP: Automatically redirected to 443 TCP;
• 443 TCP: Used for Admin portal, web applications, OCSP/CRL endpoints (automatically pointing to the public URL if configured before the certificate issuing, mobile endpoint URL (for mobile push responses).

For these accesses, it's crucial to utilize a publicly trusted SSL certificate to avoid any web browser warnings or errors while accessing different pages on this port. To achieve this, please consult your reverse proxy solution's documentation for guidance on importing a trusted certificate and configuring its usage for Port 443. The reverse proxy handles the SSL termination process. For WAProxy, refer to WAProxy documentation to perform the setup, expose applications, services and use a custom certificate.

• 8443 TCP: Use for Web service accesses.

While it is possible to use a custom publicly trusted certificate for the 8443 SOAP API port, it is recommended to use a server certificate issued by the WebADM PKI for secure communication with the backend Web Services.

For client integrations, such as Windows login, it's imperative to provide either a VALID client SSL certificate OR a valid API key issued from the tenant you are targeting for authentication.

Please, refer to the following documentations to issue Certificates and API keys from WebADM framework.

By default, WAProxy performs URL rewriting for applications. For instance, for the "Customer_A" tenant, the URL of the SAML/OpenID Provider application is https://customera.openotp.com/webapps/openid/ when accessed directly on the WebADM server.
However, if this application is published on WAProxy, the exposed URL becomes https://customera.openotp.com/openid/. In this exposed URL, the webapps path is omitted, but it must be included in the URL when requests are forwarded to the backend servers.

If you intend to use an alternative reverse proxy solution such as HAProxy and wish to circumvent the implementation of URL rewriting for various reasons, you can opt to utilize the default backend-generated URLs for the public URLs. This means that once the application is published through the app configuration on WebADM, the public link will retain the default URL path.
To enable this feature, you must include the following setting in the WebADM configuration files (/opt/webadm/conf/webadm.conf) on all nodes within your WebADM cluster:

waproxy_keepurl yes

Please note that the setting mentioned earlier does not apply or function when using WAProxy.

To enable WebADM to accept requests from reverse proxies, it's essential to declare the reverse proxy IPs in /opt/webadm/conf/webadm.conf using the following setting:

reverse_proxies "192.168.0.100", "192.168.0.101"

In addition, the reverse proxy is required to include the HTTP X-Forwarded-For and X_Forwarded_Host headers in the requests forwarded to WebADM. This is critical for proper functionality.

When not using WAProxy, another significant consideration pertains to the publication of WebServices APIs such as OpenOTP or Spankey. The reverse proxy must also append the following HTTP headers to enable the usage of WebServices via a Reverse Proxy:

HTTP Header names	Values
WAPROXY_VERSION	2
WAPROXY_CERT	%[ssl_c_der,base64]
WAPROXY_VERIFY	%[ssl_c_used]

• WAPROXY_VERSION 2 is to make WebADM think it is a WAPRoxy.

• %[ssl_c_used] is an HAProxy configuration which means:
  Returns true if current SSL session uses a client certificate even if current
  connection uses SSL session resumption.

• %[ssl_c_der,base64] is also an HAProxy configuration which means:
  Returns the base64 formatted certificate presented by the client when the
  incoming connection was made over an SSL/TLS transport layer.

Example of HTTP headers par of a authentication request forwarded by HAProxy:

[2023-10-16 14:50:28] [x.x.x.x:53766]   WAPROXY_VERSION: 2
[2023-10-16 14:50:28] [x.x.x.x:53766]   WAPROXY_CERT: 
-----BEGIN CERTIFICATE----- 
MIIFZTCCA02gAwIBAgIRANQm4rn89k5MaIFEKYaPvnQwDQYJKoZIhvcNAQELBQAw 
TDEXMBUGA1UEAwwOUkNEZXZzIFJvb3QgQ0ExCzAJBgNVBAsMAkNBMRcwFQYDVQQK 
DA5SQ0RldnMgU3VwcG9ydDELMAkGA1UEBhMCTFUwHhcNMjMxMDE2MTI0MjIzWhcN 
MjQxMDE1MTI0MjIzWjBSMQ0wCwYDVQQDDARhZDE5MQ8wDQYDVQQNDAZDTElFTlQx 
FzAVBgNVBAoMDlJDRGV2cyBTdXBwb3J0MRcwFQYDVQRhDA5WQVRMVS0wMDAwMDAw 
MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALweWax6ZeqTkjKNMDI3 
xEoev8KZ0c1wDrn2epSFssGuhE5Je9eWyNfs20Fa3S2k4/8I6o1b6jcuPkJlV5GT 
xtGV3EvYuD0SLz27wMXmdh1UoRdKMQqJZH1I0gqLG/W6gdo6yk5BlO86x+z7prE8
zhXRXI+2YvCaeDClh/FPMSxoAIo/FC87AvN1IulQpufWimu2aGQRbBGpFhMkCAKe 
PyVWHduc8u8wCSAwr5+9V3awZIjJd6pFWjfl/2mn1NYi7PkUKpbFqU9iQ7SXhDqE 
ir0i9+Dy9NuIf2TzbAUrujOVPUs+dCuAel5bM/mg6n1bw01KN+2kXTcKGEz5xal7 
ugECAwEAAaOCATowggE2MAsGA1UdDwQEAwIF4DATBgNVHSUEDDAKBggrBgEFBQcD 
AjCBxgYIKwYBBQUHAQEEgbkwgbYwJQYIKwYBBQUHMAGGGWh0dHA6Ly8xOTIuMTY4 
LjQuMjAvb2NzcC8wJQYIKwYBBQUHMAGGGWh0dHA6Ly8xOTIuMTY4LjQuMjEvb2Nz 
cC8wMgYIKwYBBQUHMAKGJmh0dHA6Ly8xOTIuMTY4LjQuMjAvY2FjZXJ0Lz9mb3Jt 
YXQ9ZGVyMDIGCCsGAQUFBzAChiZodHRwOi8vMTkyLjE2OC40LjIxL2NhY2VydC8/ 
Zm9ybWF0PWRlcjBJBgNVHR8EQjBAMB6gHKAahhhodHRwOi8vMTkyLjE2OC40LjIw 
L2NybC8wHqAcoBqGGGh0dHA6Ly8xOTIuMTY4LjQuMjEvY3JsLzANBgkqhkiG9w0B 
AQsFAAOCAgEAekLd2b+DjLmEwyiNwQ1wU/2WIPphppRg4YPIVfiWcXuGSbmHtAG7 
OFtvuH3dz0+nmjH1z0D6X2tE9g3bJY5TcwVHsJH5dA3Lg4nbpkQCIroCYuLdDHq/ 
eX4WOrmZLac6HeP66UfIj5UfpO0RfV1NECSNp1xVRUMpqKV52ztxCV/tFxeepXko 
XgqfitvAd83X087Z1nmi1qzvMLTfR8nz7xN7eHQftY1a/Ex7GrfeDbR3zSANiV6o 
Dsc+dipsOlCnXczLOc81oo9m3yL8GUO+Yx3XNv3lvgBFOO7sHdOy5DWRsrzHQTaH
Rd84O4MuB7GzSSQA/P1lq0NpAY83CXsxC677uFPUR5ytJPPKPwAaCVmH5sU3RcBN 
6prUCT+1KIcVxJdQ5jpOfvO23cayaXt9k643wmT3vtq/w+t2k4szH3+VVKF62nsF
vYoA0DGRa3n/6Mxck8YXsRDtlztpAYc+FXi6PSst7XqnSRvd5YVlXQzS4KXMYtom 
rTdKqiqDiJeeXahfUMseJ0xZRXgayQaQuvmKF1AXqKmXwA4Etcf+32oCuHMkfSeO 
Pz2+QuT9b+MXAyogujSnm2mxd9KVSfukkcVNl+OtADiJNPQWG56zVG3jD/HRr/Cm 
JEHwDSTKsA2DxHcS6K6YZK/+a7Z6glZZpgqVGBPp5Cm3GaHkvriYlas= 
-----END CERTIFICATE-----
[2023-10-16 14:50:28] [x.x.x.x:53766]   WAPROXY_VERIFY: SUCCESS
[2023-10-16 14:50:28] [x.x.x.x:53766]   X-Forwarded-For: x.x.x.x
[2023-10-16 14:50:28] [x.x.x.x:53766]   X-Forwarded-Host: x.x.x.x
[2023-10-16 14:50:28] [x.x.x.x:53766]   X-Forwarded-Server: xxx.openotp.com

Found below a configuration example for HAProxy:

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin expose-fd listeners
    nbthread                    8
    hard-stop-after             60s
    no strict-limits
    maxconn                     25000
    httpclient.resolvers.prefer   ipv4
    tune.ssl.default-dh-param   2048
    spread-checks               0
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 warning
    lua-prepend-path            /tmp/haproxy/lua/?.lua
    ssl-default-bind-options no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
cache opnsense-haproxy-cache
    total-max-size 64
    max-age 60
    max-object-size 512000
    process-vary off

defaults
    log     global
    option redispatch -1
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc


# Mailer: Alert Hosting
mailers <anonymized-id>
    timeout mail 30s
    mailer <anonymized-ip>:25 <anonymized-ip>:25
    mailer <anonymized-ip>:25 <anonymized-ip>:25


# Frontend: CLOUD_FRONTEND_SSL ()
frontend CLOUD_FRONTEND_SSL
    http-response set-header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    bind <anonymized-ip>:443 name <anonymized-ip>:443 ssl no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ca-file /tmp/haproxy/ssl/<anonymized-id>.calist verify optional alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/<anonymized-id>.certlist 
    bind <anonymized-ip>:8443 name <anonymized-ip>:8443 ssl no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ca-file /tmp/haproxy/ssl/<anonymized-id>.calist verify optional alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/<anonymized-id>.certlist 
    bind <anonymized-ip>:443 name <anonymized-ip>:443 ssl no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ca-file /tmp/haproxy/ssl/<anonymized-id>.calist verify optional alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/<anonymized-id>.certlist 
    bind <anonymized-ip>:8443 name <anonymized-ip>:8443 ssl no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ca-file /tmp/haproxy/ssl/<anonymized-id>.calist verify optional alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/<anonymized-id>.certlist 
    mode http
    option http-keep-alive
    default_backend CLOUD_BACKEND
    option forwardfor

    # logging options

    # ACTION: WAPROXY_VERSION
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_VERSION 2 
    # ACTION: WAPROXY_CERT
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_CERT %[ssl_c_der,base64] 
    # ACTION: WAPROXY_VERIFY
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_VERIFY %[ssl_c_used] 

# Frontend: CLOUD_FRONTEND_STD ()
frontend CLOUD_FRONTEND_STD
    bind <anonymized-ip>:80 name <anonymized-ip>:80 
    bind <anonymized-ip>:8080 name <anonymized-ip>:8080 
    bind <anonymized-ip>:80 name <anonymized-ip>:80 
    bind <anonymized-ip>:8080 name <anonymized-ip>:8080 
    mode http
    option http-keep-alive
    default_backend CLOUD_BACKEND
    option forwardfor

    # logging options

    # ACTION: WAPROXY_VERSION
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_VERSION 2 
    # ACTION: WAPROXY_CERT
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_CERT %[ssl_c_der,base64] 
    # ACTION: WAPROXY_VERIFY
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_VERIFY %[ssl_c_used] 

# Frontend: MSSP1_FRONTEND_SSL ()
frontend MSSP1_FRONTEND_SSL
    http-response set-header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    bind <anonymized-ip>:443 name <anonymized-ip>:443 ssl no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ca-file /tmp/haproxy/ssl/<anonymized-id>.calist verify optional alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/<anonymized-id>.certlist 
    bind <anonymized-ip>:8443 name <anonymized-ip>:8443 ssl no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ca-file /tmp/haproxy/ssl/<anonymized-id>.calist verify optional alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/<anonymized-id>.certlist 
    bind <anonymized-ip>:443 name <anonymized-ip>:443 ssl no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ca-file /tmp/haproxy/ssl/<anonymized-id>.calist verify optional alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/<anonymized-id>.certlist 
    bind <anonymized-ip>:8443 name <anonymized-ip>:8443 ssl no-tls-tickets ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ca-file /tmp/haproxy/ssl/<anonymized-id>.calist verify optional alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/<anonymized-id>.certlist 
    mode http
    option http-keep-alive
    default_backend MSSP1_BACKEND
    option forwardfor

    # logging options

    # ACTION: WAPROXY_VERSION
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_VERSION 2 
    # ACTION: WAPROXY_CERT
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_CERT %[ssl_c_der,base64] 
    # ACTION: WAPROXY_VERIFY
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_VERIFY %[ssl_c_used] 

# Frontend: MSSP1_FRONTEND_STD ()
frontend MSSP1_FRONTEND_STD
    bind <anonymized-ip>:80 name <anonymized-ip>:80 
    bind <anonymized-ip>:8080 name <anonymized-ip>:8080 
    bind <anonymized-ip>:80 name <anonymized-ip>:80 
    bind <anonymized-ip>:8080 name <anonymized-ip>:8080 
    mode http
    option http-keep-alive
    default_backend MSSP1_BACKEND
    option forwardfor

    # logging options

    # ACTION: WAPROXY_VERSION
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_VERSION 2 
    # ACTION: WAPROXY_CERT
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_CERT %[ssl_c_der,base64] 
    # ACTION: WAPROXY_VERIFY
    # NOTE: actions with no ACLs/conditions will always match
    http-request set-header WAPROXY_VERIFY %[ssl_c_used]

DNS considerations

Let's consider the WebADM infrastructure behind the DNS record openotp.com (public DNS record).

The administrative tenant, known as the Service Provider admin portal, will be accessible through the default server FQDN.

For instance, a tenant named customerA will be accessible through the URL https://customera.openotp.com, while a tenant named customerB will be accessible through the URL https://customerb.openotp.com.

All tenant URLs need to be forwarded to the WebADM cluster, regardless of the specific node within the WebADM cluster that receives the request.

The hostname (e.g., "customera" or "customerb" in the previous examples) should be directly forwarded to WebADM. WebADM will then handle the matching process based on the tenants' configurations, without requiring any specific DNS configuration. To achieve this, you should have a public DNS record associated with the respective public IPs that point to all nodes within your WebADM cluster. For example, in the case of the openotp.com infrastructure, two public IPs are linked to the same DNS record. Requests can be directed to any server within the cluster at any given time:

nslookup openotp.com 
Server:		192.168.x.x
Address:	192.168.x.x#53

Non-authoritative answer:
Name:	openotp.com
Address: 146.59.206.40
Name:	openotp.com
Address: 146.59.203.4

Behind each public IP, a WebADM server is indeed accessible; however, access requires a valid tenant URL in order to proceed.

WebADM Graphical configuration

After completing your WebADM setup, you can log in to the default admin page using the URL (https://<public_hostname_defined_in_webadm_conf>/admin). If this is your initial login on the admin console, and you haven't completed the graphical setup, please finalize it by clicking the Finish The Setup Wizard button on the Home page.

Create your LDAP structure

Now that the WebADM configuration is complete, you need to create the LDAP structure that will serve your customers and provide a clear architectural view of your hosted clients.
In this example, we will create a DC object named Customers, and under this object, we will create the various customer organization objects.

Use the Create menu in WebADM to create the desired structure.

Each organization must also have a global administrator account. Create a global administrator (WebADM Account) for each customer.

These 2 configuration object will be require in the next step during the tenant configuration.

Once this is done, you can continue with the tenant creation section.

Tenant Creation

Click on the Admin tab and click on Hosted tenants box.

Click the Add Tenant button and fill in the required information to create the tenant object. Then, click the Proceed button, followed by the Create Object button to finalize the process.

You are now entering the tenant configuration menu.

Start the configuration of your customer tenant.

• DNS Hostname: The URL used to access the tenant.
• LDAP Root Base: The LDAP root base of the customer's tenant. This is typically where all objects created by the customer in the tenant are stored.
• Super Administrator: The global administrator account created in the previous section to manage the tenant will be used by the customer for tenant administration. Afterward, the customer can create administrator roles within the tenant to grant access to other administrators.
• Admin Auth Mode: Configure the authentication mode enforced for the tenant's administrator portal.
• Admin Clients: IP addresses from which tenant administration is allowed. This can be configured to enforce security on the admin portal.
• Manager Auth Mode: Configure the authentication mode enforced for the tenant's Manager APIs.
• Manager Clients: IP addresses from which the manager APIs usage is allowed.

• Time Zone: Configure the customer's timezone. Logs and other information, including timestamps, will be displayed according to the configured timezone.
• Alert Email: Configure an email address to receive tenant alerts. It should be the customer's email address if they manage the administration, or a service provider's email address if the administration is handled by the service provider.
• Alert Mobile: Configure an phone number to receive tenant alerts. It should be the customer's phone number if they manage the administration, or a service provider's phone numberif the administration is handled by the service provider.
• Admin Skill Level: Value is 1 to 3 for Beginner, Intermediate and Expert. The default level (Expert) is recommended as it provides access to all the RCDevs features.
• Log Retention Time: Configure the log retention for the tenant.
• Proxy User Admin: When enabled, the WebADM proxy user is used for all LDAP operations after login. It is highly recommended to enable this feature to avoid having to configure new LDAP ACLs each time a new tenant is created. ACLs are configured in the slapd.conf file, and any changes to this file require a restart of the SLAPD service to take effect.
• Allow Insecure APIs: Accept SOAP/HTTP Web service requests without TLS and/or client certificates / API keys. For security, that setting should not be enabled for production usage.
• Allow Self Configuration: Tenant administrator can reconfigure relevant tenant configurations.
• Bruteforce Protection: Setting protections here overrides the same settings in tenant applications.
  • BlockIP: Block source IP addresses for 1 minute after 25 login failures within 10 seconds.
  • CacheDN: Prefetch and cache domain DNs for 5 minutes after 25 login failures within 10 seconds.
    It is highly recommended to enable these settings.

• Encrypt Key Salt: Secret to be combined with the encrypt keys for per-tenant software encryption. WARNING: Changing the salt value will break all tenant encrypted data!
• HSM Key Handle: Dedicated key handle(s) to be used instead of the globally configured key handles. This is useful when the WebADM cluster is configured with an HSM cluster, and the encryption keys need to be retrieved from the HSMs.
• Organization Name: The organization name of your hosted customer. This name will be included in the certificate issued by the PKI from the customer tenant.
• Organization Identifier: The identifier of your customer. This identifier will be included in the certificate issued by the PKI from the customer tenant.
• Organization Logo: A logo can be configured to be displayed in the tenant, applications, Push login notifications...
• Organization From: The sender email address of the customer, which will be used for any emails sent by WebADM in the context of the customer tenant.
• Organization Website: The website of your customer, which will be included as part of the customized information.

• Allowed Applications: Select which application(s) and service(s) will be allowed in that tenant.

• Application Options: Select the option(s) (primarily OpenOTP options) that will be allowed for the tenant.
  - AUTH: Authentication with OpenOTP;
  - SIGN: eSignature with OpenOTP;
  - VOICE: Authentication with VOICE biometric feature of OpenOTP.
  - BADGE: Badging feature of OpenOTP.

The options must be part of the global license to be enabled for the tenant.

• Valid From: License starting date (Defaults to main hosting license date).
• Valid To: License expiration date (Defaults to main hosting license date).
• Maximum Users: User quota limit for applications licensed with a user quota.
• Maximum Hosts: Host quota limit for applications licensed with a host quota. (Spankey product)
• Support Services: Allow sending tickets to RCDevs support and opening chat conversations through the WebADM administrator portal.

• Allowed Email Domains: Specifies the email domains that are permitted for use within the tenant. Only email addresses from these domains will be allowed for registration or communication within the system, helping to ensure that only authorized domains are used.

• DKIM Private Key: The private key used for signing outgoing emails with DKIM (DomainKeys Identified Mail). This key is used to authenticate the sender's domain and ensure the integrity of the email content, preventing tampering during transmission.

• DKIM Domain: The domain that will be used for DKIM signing. It indicates which domain's DKIM records will be applied to the outgoing emails, allowing recipients to verify the authenticity of the email sender and ensure the message has not been altered.

• DKIM Selector: The selector used to locate the DKIM public key in the DNS records. It is a string that helps identify the specific DKIM key to use when verifying a signed email, ensuring that the correct public key is matched with the signature during email authentication.
  Here are the descriptions for the settings you provided:

• Max Requests Per Second: Defines the maximum number of requests that can be processed per second. This setting helps to limit the rate of incoming requests to prevent system overload, ensuring optimal performance and preventing abuse or overuse of system resources.

• Max Objects Per Minute: Specifies the maximum number of objects (such as records, entries, or entities) that can be created or modified within a minute. This setting helps to control the rate of changes made to the system, preventing excessive load and maintaining system stability.

• Max Emails Per Minute: Determines the maximum number of emails that can be sent within a minute. This setting helps to manage email traffic, preventing the system from being overwhelmed by a high volume of outgoing emails and protecting against potential misuse or spam-related issues.

Click Apply when everything is configured as expected and your tenant will be created.

A tenant can be accessed through the master tenant for the service provider. To do this, click on the LDAP object the tenant is pointing to, and in the Object Details box, click Administer Tenant.

Once redirected to the customer tenant, complete the setup by clicking the button to create the container objects needed for WebADM.

The structure has been created, and WebADM administration can now begin.

Remember that in the tenant configuration, we set the Admin Auth Mode to OTP. The OpenOTP service must be enabled on the tenant, and the administrator account must have a method configured (such as a token or email address) that meets the authentication requirements to successfully complete the authentication process on the administrator portal.

Your customer should now be able to access their tenant through the specified tenant URL using the super administrator account configured in the tenant object. Once authenticated with the global administrator account defined in the tenant configuration, the customer can manage products as they would in an on-premise installation. For product configuration, please refer to the RCDevs documentation.

Client integration with a tenant

Please, refer to the following documentation for client integrations example with your tenant.

Client integrations with a tenant are similar to on-premise or enterprise deployments. An API key or a client certificate issued through the tenant must be provided if the Allow Insecure APIs setting is enabled in the tenant configuration.

OpenOTP Cloud Bridges VM

For RADIUS and LDAP integrations, RCDevs advises to deploy the OpenOTP Cloud bridge VM for security reasons. Please, refer to the following documentation for more information on that topic.