Reinforcing Authentication for TAP-TC API Calls

Objective

To reinforce the existing Basic Authentication for API calls from TAP to the client’s TeamConnect by implementing Certificate-Based Authentication (Mutual TLS - mTLS) at the client's API gateway service layer, which acts as a reverse proxy. This will provide a more robust authentication process while maintaining compatibility with the current TeamConnect authentication logic. 

Background

Previously, TAP used Basic Authentication for calls to the client's TeamConnect. To enhance security, the client required the implementation of mTLS. The client’s API gateway service functioned as a reverse proxy, handling the mTLS authentication from TAP and then forwarding the original request, including the Basic Authentication credentials, to the TeamConnect endpoint. This created a dual-layer authentication scheme.

Functional Requirements

The following are the key functional requirements for this enhancement: 

Certificate Setup

Mitratech/CloudOps team will create the private key (.pfx) and certificate chain and install them on the TAP virtual machines. The corresponding public key will be shared with the client for installation in their infrastructure (such as F5 or other gateway components). The CloudOps team will proactively manage certificate issuance, monitoring, and renewal as part of their standard maintenance process, using alerts and notifications.

Note: Client certificates will be issued per environment (one for non-production and one for production). If required, the setup can be extended to support certificates issued per tenant and per environment.

Infrastructure Considerations

• Network Component Assessment in Development Environment: An assessment is done to determine if load balancers, API gateways, or other networking components in the path require updates or specific configurations to support mTLS.
• Firewall Rule Adjustment in Production Environment: Verified if firewall rules or network policies need adjustments to allow mTLS traffic between TAP and the API gateway service.

Authentication Flow

• TAP- Gateway mTLS Authentication: TAP will initiate communication and authenticate with the client's API gateway service using certificate-based authentication (mTLS).
• Gateway Forwarding with Basic Auth: Upon successful mTLS authentication, the gateway service must forward the original request to TeamConnect while retaining the existing Basic Authentication credentials (username and password) in the request message.
• TeamConnect Processing: TeamConnect must continue to process authentication based on the Basic Authentication credentials received from the API gateway service, without requiring any changes to its existing authentication logic.

Technical Pre-requisites 

• Test Environment Setup: A dedicated test environment with the client’s gateway proxy configured for mTLS is established for validation. A simulated test environment for internal testing was created where an IIS website was set up as the reverse proxy, and client certificate authentication was enabled at the Azure application gateway level.
• Successful Authentication Verification: Verified that both SOAP and REST API calls from TAP successfully authenticate using the configured certificates through the gateway proxy.
• Basic Auth Forwarding Confirmation: Ensured that TeamConnect consistently receives and processes the username-password credentials as expected, confirming that the gateway proxy correctly forwards them after mTLS.
• Logging and Monitoring: Implemented comprehensive logging and monitoring mechanisms for all authentication attempts and failures to facilitate troubleshooting and auditing.
• Certificate Management Strategy: Mitratech/CloudOps will manage this process.
• Compatibility Assurance: Ensured that all changes are fully compatible with the current version of the client-hosted TeamConnect and any planned future versions.
• Test Case Creation: Developed detailed test cases specifically for this new authentication implementation, covering various scenarios including successful handshakes, authentication failures, and certificate expiry.
• IIS Certificate Authentication Validation: Validated the certificate-based handshake with IIS certificate authentication configuration in relevant environments (QA, UAT/Staging).
• Expired/Revoked Certificate Handling: Tested the system's ability to properly handle expired or revoked client certificates.

Glossary of Terms

• Gateway service: A component of the client’s network infrastructure, specifically a reverse proxy and application delivery controller from the gateway Networks, used to secure and manage traffic.
• Mutual TLS (mTLS): A two-way authentication process where both the client (TAP) and the server (gateway proxy) verify each other's digital certificates during the TLS handshake.
• Basic Authentication: A simple authentication scheme where credentials (username and password) are sent in the HTTP header.
• TAP: The client application initiates API calls.
• TeamConnect: The client's backend system that processes the API calls.
• Reverse Proxy: A server that sits in front of web servers and forwards client requests to those web servers, often used for security, load balancing, and caching.
• Server Key Store: Where the server stores its private key and public certificate.
• Server’s trust store: Where the server stores trusted client certificates for validation.
• Client Key Store: Where the client stores its private key and public certificate.
• Client’s trust store: Where the client stores trusted server certificates for validation.
• ClientKeyExchange/ServerKeyExchange: Messages used during the TLS handshake for exchanging public keys.
• ChangeCipherSpec: A message indicating a transition to encrypted communication.