Page Comparison

As a WAM component, the EmpowerID Application Gateway provides Web environments with seamless access to all of the identity management facilities of EmpowerID. This means that organizations can use the EmpowerID Application Gateway 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 IdP, the EmpowerID RBAC / ABAC engine controls all facets of access for those users in accordance with the policy applied to them.

EmpowerID Application Gateway Components

The EmpowerID Application Gateway controls access to web applications and APIs without requiring the installation of an agent. To configure the Application Gateway, 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 Application Gateway 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 Application Gateway 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 Application Gateway components in the EmpowerID Web interface, you configure the Application Gateway files with the appropriate information for your environment. The below diagram shows all the components and configuration files associated with the EmpowerID Application Gateway. A description of each follows the diagram.

Web Access Management Applications

Web Access Management (WAM) applications represent the specific sites protected by the EmpowerID Application Gateway. 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 Application Gateway 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 Application Gateway 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 Application Gateway checks to see if there are any directs them to the EmpowerID Identity Provider, where they must log in. Once authenticated, the Application Gateway 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 Application Gateway, 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:

In addition to creating the above applications in EmpowerID, you need to configure the EmpowerID Application Gateway 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.

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;
        }
    }    
}