Introduction
vSEC:CMS S-Series (vSEC:CMS) is an innovative, easily integrated and cost effective Credential Management System (CMS) that will help you deploy and manage credentials within your organization.
vSEC:CMS is fully functional with minidriver enabled credentials such as smart cards, USB tokens and virtual smart cards including Windows Hello for Business (WHfB). It streamlines all aspects of managing credentials by connecting to enterprise directories, certificate authorities, physical access control systems, email servers, log servers, biometric fingerprint readers, PIN mailers… the list goes on. With vSEC:CMS organizations can issue Credentials to employees, personalize the Credentials with authentication credentials and manage the lifecycle of the Credentials – directly from the off-the-shelf product.
Architecture
vSEC:CMS is a client-server based architecture. Clients connect to the server-side over HTTP/HTTPS using either SOAP or gRPC protocol. Below we describe in more details the architecture of vSEC:CMS.
When initially setting up vSEC:CMS you connect to the server where vSEC:CMS is installed via RDP. Once you have configured the system as you require it is highly recommended that you connect to the system using client-server architecture and not over RDP for optimal performance reasons.
Components
vSEC:CMS is separated into four main components:
- A MS Windows service, named vSEC:CMS Service (1) in the architecture drawing above, which manages the vSEC:CMS database in addition to operator account management for those operators who have access to vSEC:CMS. This service runs as a MS Windows service and will be installed by default to run under the MS Windows SYSTEM account;
- A MS Windows service, named vSEC:CMS SOAP/gRPC Service (11) in the architecture drawing above, which communicates with the vSEC:CMS Service and is the SOAP/gRPC service for the vSEC:CMS Agent (2) or vSEC:CMS Admin (3) and the vSEC:CMS User Self-Service Console (12);
- The vSEC:CMS Agent (2) or vSEC:CMS Admin (3), which is run by each operator in the user's context;
- The vSEC:CMS User (12) which is run on an end user's workstation from where credential users can perform self-service credential operations with conventional smart cards (8) or virtual smart cards (14).
The SOAP/gRPC HTTPS channel between the vSEC:CMS SOAP/gRPC Service and the vSEC:CMS Agent or vSEC:CMS Admin and vSEC:CMS User is secured using AES128 encryption.
If SOAP is used then SOAP-XML requests using Windows Web Services API (WWSAPI) will be constructed. The SOAP requests are sent using HTTP/HTTPS to the vSEC:CMS SOAP Service. The vSEC:CMS SOAP Service is a .NET WWSAPI service running as a Windows service.
The vSEC:CMS SOAP Service performs the following flow:
- Sends the SOAP request as received from the vSEC:CMS Agent or vSEC:CMS Admin and the vSEC:CMS User to the vSEC:CMS Windows service through encrypted shared memory;
- Receives back the response from the vSEC:CMS Windows service through encrypted shared memory;
- Constructs the XML response;
- Returns the XML SOAP response to the vSEC:CMS Agent or vSEC:CMS Admin and the vSEC:CMS User.
The vSEC:CMS Agent or vSEC:CMS Admin and the vSEC:CMS User applications then parse the XML using WWSAPI.
For gRPC the server endpoints are implemented in the same services where the SOAP endpoints for the same component.
vSEC:CMS Service (1)
The vSEC:CMS Service is managing the Database (4), which is stored in the [DAT] folder which sits beside the service executable (CmsService.exe). By default, this folder has access permissions set for MS Windows SYSTEM user and the Windows user who installed the application. Optionally the Database (4) can be hosted in an SQL database.
Prior to version 5.8, the security keys used by vSEC:CMS were stored on the Operator Cards (7). From version 5.8 these keys will be stored on the server in an encrypted key store. These keys can optionally be stored in HSM (13) if required.
The Database (4) contains several tables. These tables contain information about the smart cards managed and configuration settings used for the vSEC:CMS. The database is encrypted with keys stored on the Agent Credential (7), therefore the database can only be accessed when an operator card is available.
If the application is configured for backup, the vSEC:CMS Service encrypts the database and stores the backup file in the configured location.
If configured, the vSEC:CMS Service will send status information to the MS Windows Event System (5).
vSEC:CMS gRPC/SOAP Service (11)
The vSEC:CMS gRPC/SOAP Service (11) communicates with the vSEC:CMS Service (1) over encrypted shared memory. The vSEC:CMS gRPC/SOAP Service (11) is the SOAP service for the vSEC:CMS Agent (2) or vSEC:CMS Admin (3) and the vSEC:CMS User (12) providing the communication channel for these components. This channel is over HTTP(S). The vSEC:CMS gRPC/SOAP Service (11) has three separate Windows services named vSEC:CMS - Operator Console Service for vSEC:CMS Agent (2) or vSEC:CMS Admin (3), vSEC:CMS - User Self Service for vSEC:CMS User (12) and the vSEC:CMS RSDM service. These services manage the communication between the different components.
vSEC:CMS Agent (2) or vSEC:CMS Admin (3)
vSEC:CMS Agent (2) or vSEC:CMS Admin (3) is started for each operator in the user's user context . It provides the application interface to the operator. The operator needs to logon to the application using a valid Agent Credential (7), thereby providing two-factor authentication.
The Agent Credentials also contain several security keys, which are only accessible with a valid PIN.
The vSEC:CMS Agent (2) or vSEC:CMS Admin (3) accesses the database through the vSEC:CMS gRPC/SOAP Service (11).
Managing Managed Credentials (8), the vSEC:CMS Agent (2) or vSEC:CMS Admin (3) needs to communicate with Directory Servers (9) and Certification Authorities (CA) (10). For connecting to the Directory Servers (9) the LDAP(S) protocol is used. This depends on what is configured in the environment but the default ports typically used are 389 or port 636. For connection with the Certification Authorities (CA) (10) the DCOM/RPC protocol is used. The default port for DCOM/RPC is typically 135.
All communication between the vSEC:CMS Agent (2) or vSEC:CMS Admin (3) and the credential is done through the credential minidriver. Certificate key(s) are generated on the credential and the certificate request is sent to the CA using Microsoft ICertRequest API.
vSEC:CMS User (12)
The vSEC:CMS User is started for each user on their workstation. It provides the UI to the user to perform user self-service operations on their credential (8). All communication is performed through the vSEC:CMS gRPC/SOAP Service (11). The protocol used is HTTP(S). The connection and the port is configurable through the vSEC:CMS Admin (3).
vSEC:CMS RSDM
The vSEC:CMS Remote Security Device Management (RSDM) is a Windows service which is installed on each client machine that a credential (either virtual or physical) is to be issued on and managed by vSEC:CMS. vSEC:CMS RSDM service running on the client machines will send a registration request to the RSDM service running on the server side (the vSEC:CMS gRPC/SOAP Service (11)) when the RSDM service starts. Communication is performed through the vSEC:CMS gRPC/SOAP Service (11) when registration is performed. The protocol used in this case is HTTP(S).
Additionally, the RSDM service can be configured to receive push notifications from the server side. The push notifications will be sent from the server side to the client using User Datagram Protocol (UDP) broadcasting. These push notifications are sent from the server side to notify the client that an event is waiting for it on the server that the client needs to process.
Ports and Protocols
The table below outlines the ports and protocols used by vSEC:CMS based on the architecture diagram above. It is assumed that there is no firewall between vSEC:CMS Service and any external component that the service communicates with.
This section is a guideline only, specifically describing the ports as the ports are configurable depending on your environment setup.
Application |
Rule Type |
Source System |
Destination System |
L7 Protocol/ Service |
Comments |
Default Port |
L4 Protocol |
vSEC:CMS Operator Console |
Inbound (from 2 to 10) |
External user |
MS CA Service |
DCOM/RPC |
The port used here depends on what is configured in the environment. Note
This is only applicable if proxy through server is not enabled in the CA connection configuration. |
135 |
TCP |
vSEC:CMS Operator Console |
Inbound (from 2 to 9) |
External user |
Directory |
LDAP(S) |
The port used here depends on what is configured in the environment. |
389 or 636 |
TCP |
vSEC:CMS Operator Console |
Inbound (from 2 to 11) |
External user |
vSEC:CMS SOAP/gRPC Service |
HTTP(S) |
The port used here depends on what is configured in the environment. |
80 or 443 |
TCP |
vSEC:CMS User Self-Service Console |
Inbound (from 12 to 11) |
External user |
vSEC:CMS SOAP/gRPC Service |
HTTP(S) |
The port used here depends on what is configured in the environment. |
80 or 443 |
TCP |
vSEC:CMS RSDM Service |
Inbound (from 12 to 11) |
External user |
vSEC:CMS SOAP/gRPC Service |
HTTP(S) |
The port used here depends on what is configured in the environment. |
80 or 443 |
TCP |
vSEC:CMS RSDM Service (optional) |
Outbound (from 1 to 11) |
CMS service |
RSDM service on the client |
Proprietary |
The port used here depends on what is configured in the environment. |
Confi-gurable on the client |
UDP |
vSEC:CMS Service |
From to 1 to 10 |
CMS service |
MS CA Service |
DCOM/RPC |
The port used here depends on what is configured in the environment. |
135 |
TCP |
vSEC:CMS Service |
From to 1 to 9 |
CMS service |
Directory |
LDAP(S) |
The port used here depends on what is configured in the environment. |
389 or 636 |
TCP |
vSEC:CMS Service |
From to 1 to 13 |
CMS service |
HSM |
Proprietary for HSM |
The port used here depends on what is configured in the environment. |
Depends on HSM |
TCP |
vSEC:CMS Service |
From to 1 to 4 |
CMS service |
Database |
ODBC |
This would only be required if MS SQL is used for the database. The port used here depends on what is configured in the environment. |
1433 |
TCP |
Hardware Requirements
vSEC:CMS can be installed on following server platforms:
Virtual servers are supported.
- Microsoft Windows 2016 Server;
- Microsoft Windows 2019 Server;
- Microsoft Windows 2022 Server.
The server minimum hardware requirement:
- At minimum 2 Processor with 2 GHz or faster;
- Memory 8 GB RAM or greater;
- Available disk space on server of 40 GB or greater for the operating system plus 2GB or greater for the vSEC:CMS database.
For optimal performance though the following hardware requirements are recommended:
Server recommended hardware requirement where the vSEC:CMS is installed:
- At minimum 2 Intel Xeon processors with 2 GHz or faster;
- Memory 16 GB or greater;
- Available disk space on server of 40 GB or greater for the operating system plus 2GB or greater for the vSEC:CMS database;
- Gigabit-LAN (1.000 Mbit/s).
Client recommended hardware requirements for any workstation that vSEC:CMS operator console is installed on:
- At minimum 2 Intel i7 processors with 3.6 GHz or faster;
- Memory 8 GB or greater;
- Gigabit-LAN (1.000 Mbit/s).
Software Requirements
Depending on the credential that you are using it will be necessary to have the appropriate credential drivers installed on your host. Please check with the credential provider that you have the correct credential drivers installed.
Additionally, for versions prior to 6.0 Microsoft .NET Framework 4.7.2 should be installed on any host where vSEC:CMS components are installed. From version 6.0 and above Microsoft .NET Framework 4.8 should be installed.
You can validate what version of Microsoft .NET Framework is installed on your host by running the Powershell command below to see the full version information:
Supported Credentials
Using vSEC:CMS it is possible to manage a wide range of credentials. For the complete list of supported smart cards see here.
PKI Support
Using vSEC:CMS it is possible to use a wide range of PKI providers. For the complete list of currently supported PKI providers see our product flyer here.
Depending on which CA you use it may be that not all specific workflows and processes are covered therefore please contact Versasec at info@versasec.com for specific information on your CA specific workflows to ensure that they are covered by vSEC:CMS.
Comments
0 comments
Please sign in to leave a comment.