| Style | ||
|---|---|---|
| ||
The EmpowerID Reverse Proxy or microservices gateway is a dockerized NGINX module that is a key component of any Zero Trust or microservices security architecture. As a a component of the EmpowerID WAM System, the Reverse Proxy stands in front of protected Web applications and Docker containers, restricting access to the resources served by those applications by intercepting all HTTP traffic bound for those applications, evaluating and processing each request using EmpowerID's hybrid RBAC / ABAC engine.
As a WAM component, the EmpowerID Reverse Proxy provides Web environments with seamless access to all of the identity management facilities of EmpowerID. This means that organizations can use the EmpowerID Reverse Proxy to provide the same level of security to the resources that live on their Web servers and API endpoints as they can to the resources that live in their directories and other such similar resource systems.
These facilities work together to allow authorized users unhindered access to any and all resources to which they are entitled, while denying illegitimate users the ability to do the same. Once users authenticate using OpenID Connect to our IdpIdP, the EmpowerID RBAC / ABAC engine controls all facets of access for those users in accordance with the policy applied to them.
EmpowerID Reverse Proxy Components
The EmpowerID Reverse Proxy controls access to web applications and APIs without requiring the installation of an agent. To configure the reverse Proxy, an OpenID Connect OAuth application record is created in EmpowerID with an associated SAML connection linked to it for use in defining attribute statements. The Reverse Proxy does not communicate with the SQL back-end and uses this OAuth connection when making API calls to the EmpowerID REST endpoints to retrieve its configuration and for real-time ABAC access checks. Web applications protected by the Reverse Proxy are created in EmpowerID as web applications with their protected URLs and paths registered as "Application Subcomponents." RBAC and ABAC policies can be applied to determine who may have access to these subcomponents/URL paths. After creating the appropriate reverse proxy components in the EmpowerID Web interface, you configure the reverse proxy application files with the appropriate information for your environment. The below diagram shows all the components and configuration files associated with the EmpowerID reverse proxy. A description of each follows the diagram.
Web Access Management Applications
Web Access Management (WAM) applications represent the specific sites protected by the EmpowerID Reverse Proxy. As such, each WAM application is a service provider represented in EmpowerID with a unique SAML Connection. Representing protected Web sites with SSO Connections allows EmpowerID to maintain a link between those Web sites, the protected resources (URLs) on those sites, and the users authorized to access them.
As a service provider, the reverse proxy responds to requests for resources in a manner familiar to most Web users:
- If the request is for a resource that is of a sensitive nature, users must prove their identities to EmpowerID and be authorized to access the requested resource before the request is serviced.
- On the other hand, if the request represents an unrestricted resource that requires no identity proofs to access, then the reverse proxy services the request without requiring users authenticate or checking to see if they have the appropriate delegations.
You create WAM applications in EmpowerID by navigating to the Applications and Connections page of the EmpowerID Web application and selecting Create Application. This opens a generic interface for all applications where you can select the SSO Connection specific to WAM applications.
This connection offers a form with a number of fields common to all SSO applications, such as the Name, Description, and Certificate fields, as well as additional fields specific to WAM applications. These include:
- the Base URL field,
- options to allow anonymous access to unprotected paths, and
- options to use the target host name when sending requests to the protected Web application.
The Base URL field is important because this is where you specify the address of the Web site to protect and the GUID of the SAML connection for that Web site, such as www.empowerid.com/5a1c4be2-4854-4bd5-b1a8-3d166afaa7c8. You can have as many WAM applications as needed to protect your sites; however, each WAM application can only be mapped to one SAML connection.
So if you have a Web site named www.empowerid.net and another named www.empowerid.com and you want to restrict access to resources on both, you must create two WAM applications with the appropriate Base URL value for each.
Application Subcomponents
With WAM applications, Application Subcomponents represent the paths on the Web server you want to protect. When you create a WAM application, you designate the path or paths on the Web server to restrict by adding an Application Subcomponent for each path.
When users first attempt to access a protected path, the reverse proxy checks to see if there are any directs them to the EmpowerID Identity Provider, where they must log in. Once authenticated, the reverse proxy makes an API call for all the resources on the Web server the user has access to. The EmpowerID RBAC / ABAC engine returns a real-time list of access back to the reverse proxy, where it is cached for a specified period of time and then updated. Caching times default to five minutes for RBAC data and two minutes for ABAC data.
EmpowerID provides a number of matching options for specifying these paths. The option you choose determines the scope of the Application Subcomponent and you can have more than one Application Subcomponent for a site. For example, you can have an Application Subcomponent for the base URL of a site and other Application Subcomponents for certain paths on that site. In this way, you can set up additional requirements such as multi-factor authentication for users accessing more sensitive URLs. The matching options for an Application Subcomponent are as follows:
...
| Info |
|---|
For step-by-step guidance on creating WAM applications, see Creating WAM Applications. |
OAuth Application
As mentioned above, the reverse proxy makes API calls to EmpowerID to collect RBAC data on each person in your environment. In order to make the necessary API calls, the SAML connection for the WAM application must have an OAuth application with an owner who has the access to make those calls. When you create the application, EmpowerID generates an API Key, a Client ID (Key), and a Client Secret that you use when you configure the reverse proxy
EmpowerID Reverse Proxy Configuration Files
In addition to creating the above applications in EmpowerID, you need to configure the EmpowerID Reverse Proxy for your specific environment. To do this, you can do one of two things, you can create a directory on your linux machine and create the appropriate files with hard-coded values or you can pass those values at runtime, using environment variables (e.g. env CLIENT_ID). The below code shows what the default proxy.nginx file looks like with elements to enable the modsecurity module. The modsecurity module protects against such Layer 7 attacks as SQL injection (SQLi) and cross-site scripting (XSS).
A description of the settings follows the code.
| Code Block | ||||
|---|---|---|---|---|
| ||||
load_module modules/ngx_http_modsecurity_module.so;
worker_processes 1;
error_log logs/error.log debug;
events {
multi_accept on;
worker_connections 1024;
}
env CLIENT_ID;
env CLIENT_SECRET;
env EMPOWERID_API_KEY;
env CERTIFICATE_THUMBPRINT;
env CERT_FILE_PASSPHRASE;
env SERVICE_PROVIDERS_GUIDS;
env DISCOVERY;
env HASACCESSTOPAGE_ENDPOINT;
env GET_RESULTS_ENDPOINT;
env TOKEN_ENDPOINT;
env SCHEMA_HOST_PORT;
http {
tcp_nodelay off;
tcp_nopush on;
upstream backend_hosts {
server 35.153.255.7;
}
resolver 8.8.8.8 ipv6=off;
# cache for discovery metadata documents
lua_shared_dict discovery 1m;
# cache for JWKs
lua_shared_dict jwks 1m;
lua_shared_dict sessions 10m;
lua_shared_dict empowerid_proxy_config 10m;
init_worker_by_lua_block {
local opts = {
redirect_uri_path = "/oauth2callback",
ssl_verify="no",
logout_path = "/logout",
cert_file="/usr/local/openresty/nginx/conf/file.pem",
oauth_grant_type="urn:ietf:params:oauth:grant-type:jwt-bearer",
discovery = os.getenv("DISCOVERY),
client_id = os.getenv("CLIENT_ID),
client_secret = os.getenv("CLIENT_SECRET"),
service_providers_guids = os.getenv("SERVICE_PROVIDERS_GUIDS"),
hasaccesstopage_endpoint = os.getenv("HASACCESSTOPAGE_ENDPOINT"),
empowerid_api_key = os.getenv("EMPOWERID_API_KEY"),
get_results_endpoint = ("GET_RESULTS_ENDPOINT"),
token_endpoint = OS.GETENV("TOKEN_ENDPOINT"),
certificate_thumbprint=os.getenv("CERTIFICATE_THUMBPRINT"),
cert_file_passphrase=os.getenv("CERT_FILE_PASSPHRASE"),
schema_host_port=os.getenv("SCHEMA_HOST_PORT")
}
require"empowerid.proxy"(opts)
}
server {
server_name FQDN of your EmpowerID server
listen 443 ssl;
modsecurity on;
modsecurity_rules_file/usr/local/openresty/nginx/conf/main.conf
ssl_certificate/usr/local/openresty/nginx/conf/certificate.crt;
ssl_certificate_key/usr/local/openresty/nginx/conf/keyfileencrypted.key
ssl_password_file/usr/local/openresty/nginx/conf/global.pass;
location~\.(gif|png|js|css|ico|woff|woff2)${
expires 1y;
proxy_pass http:/backend_hosts;
location / {
set $session_storage shm;
access_by_lua_block {
require"empowerid.proxy"()
}
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Connection "";
proxy_pass http://backend_hosts;
}
}
}
|
...