Web Access Management (WAM) is a web-centric Identity Management strategy that focuses on securing enterprise resources accessible to Internet users. The key principles of WAM include enforcement of corporate security policies, prevention of unauthorized access to enterprise resources, and the enablement of Web single sign-on (SSO) for simpler access to cross-domain resources. WAM implementations typically realize these through the enactment of authentication and access control policies that funnel all Web application users through a single security gate, where decisions about the users are made and enforcement of those decisions occur. In WAM terminology, this security gate is known as the "Policy Decision Point" or "PDP." The PDP decides what users can or cannot do based on the information it reads from a "Policy Information Point" or "PIP," which is written and managed by administrators and other delegated users through a console known as a "Policy Administration Point" or "PAP." The decisions of the PDP are then enforced by a "Policy Enforcement Point" or "PEP."
The EmpowerID Reverse Proxy is a component of the EmpowerID WAM System that sits between clients and Web servers, restricting access to the resources served by those servers by intercepting all HTTP traffic bound for those servers and redirecting it to EmpowerID for security evaluation and processing. 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 organizations can employ the EmpowerID Reverse Proxy to provide the same level of security to the resources that live on their Web servers 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 a user authenticates (using identities supplied by any number of accepted Identity Providers, including EmpowerID, Twitter, Facebook, Google, Salesforce, Paypal and so on), the EmpowerID RBAC engine controls all facets of access for that user in accordance with the policy applied to him. The below image shows the relationship of the EmpowerID Reverse Proxy to the other facilities of EmpowerID.
If you look closely at the above image, you will notice a difference between how EmpowerID interacts with the resources contained in an account store or another type of resource system—such as a file server—and the HTTP resources within a Web server. Namely, EmpowerID connects to and inventories the former, but not the latter. This means EmpowerID has no implicit knowledge of the actual resources on a Web server or even of the Web server itself. This information must be supplied from a secondary source. In EmpowerID, you supply this information through the creation of a special SSO application known as a "Web Access Management" application, adding to that application special components known as "Application Subcomponents."
Web Access Management (WAM) applications represent the specific sites being protected by the EmpowerID Reverse Proxy. As such, each WAM application is a service provider represented in EmpowerID with a unique SAML SSO 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 with 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 will be serviced. On the other hand, if the request represents an unrestricted resource that requires no identity proofs to access, then the reverse proxy will simply service the request without requiring users authenticate or, if already authenticated, checking to see if they have the appropriate delegations for the resource.
You create WAM applications in EmpowerID by navigating to the "Applications and Connections" page of the EmpowerID Web application and selecting "Create Application." Doing so opens the interface generic to all applications, allowing you to select the SSO Connection specific to WAM applications. This connection contains a form with a number of fields common to all SSO applications, such as the Name, Description, and Certificate fields, as well as an additional fields specific toWAM applications, including the Base URL field, as well as options for allowing anonymous access to unprotected paths and whether the target host name should be used when sending requests to the protected Web application. Of these fields, the Base URL field is important because this is where you specify the address of the Web site to be protected, such as "www.empowerid.com." You can have as many WAM applications as needed to protect your sites; however, each WAM application can only be mapped to one site. For example, 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.
With WAM applications, Application Subcomponents represent resources (URLs) you wish to protect on a given Web server. When you create a WAM application, you designate the path or paths on the Web server to be restricted by adding one Application Subcomponent for each path. Then when users first attempt to access the URL, the reverse proxy directs them to the EmpowerID Identity Provider, where they must log in and request access to the resource. Once access is granted, EmpowerID creates an account for that person that is linked to the appropriate SSO Connection (WAM application) via that Account Store ID for that connection.
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 setup additional requirements for users accessing more sensitive URLs, such as requiring multi-factor authentication. The matching options for an Application Subcomponent are as follows:
The default path for an Application Subcomponent is "/", which specifies everything on the Web server. If you want to control access to everything on the server, you simply create the Application Subcomponent without specifying a matching option.
For step-by-step guidance on creating WAM applications, see Creating WAM Applications.
In addition to creating the above two applications, you need to configure the EmpowerID Reverse Proxy for your specific environment. You do this by customizing the settings of the config.js file for the EmpowerID Reverse Proxy. This file is located in the top-level folder for the application, the node_httpProxy folder. A description of the file's settings follows.
For step-by-step guidance on configuring the EmpowerID Reverse Proxy, see Installing and Configuring the EmpowerID Reverse Proxy.
The following image depicts how this works. In the image, both users begin their sessions as anonymous users. User A attempts to access www.empowerid.com (indicated by the red 1). However, because ALLOW_ANONYMOUS is set to false, the user receives a 403 message indicating she needs is not authorized to view the resource. User B, however, knows the exact URL he wants to access—a URL for which a PURL exists—and navigates his browser to www.empowerid.com/customers (indicated by the blue 1). Because a PURL exists for this specific path, the EmpowerID Reverse Proxy redirects his browser to the Login page for the EmpowerID Web application, where he successfully authenticates against the EmpowerID IdP. The reverse proxy then fetches the requested resource for him. Later, within the same session, User B requests www.empowerid.com (indicated by the green 2). Because User B is already authenticated, and no further delegations are required for the URL, the reverse proxy fetches the resource and serves it to him.
The following table provides some example router configuration settings. Each example shows a specific router setting and how that setting affects the translation. As can be seen, the reverse proxy makes the translation based on the most specific path supplied to it. So, for example, if the router is configured for 'www.andysbeans.com/customers : www.andysbeans.com/allcustomers' and a user types www.andysbeans.com/customers/oh into her browser, the reverse proxy will translate that request to www.andysbeans.com/allcustomers/oh.
|'www.andysbeans.com : 10.0.0.4'|
|Client Request||Translated Request|
|Client Request||Translated Request|
'www.andysbeans.com/customers : 10.0.0.4/customers',
'www.andysbeans.com/admin : 10.0.0.5/admin'
|Client Request||Translated Request|
Once the above three components are in place, the EmpowerID Reverse Proxy is ready to protect your Web resources from unauthorized access. The flow for this is depicted below.
The user submits credentials back to EmpowerID. As EmpowerID is able to be configured as an authentication hub that supports trusted relationships with all major Identity Providers (IdP), users can be given the ability to authenticate with credentials as diverse as a Salesforce login, a social media login, or an EmpowerID login. The only prerequisite is EmpowerID must be configured to trust the third-party IdP and users must have an EmpowerID Person that can be linked to the IdP account.
In addition to the above steps, the EmpowerID Reverse Proxy pulls configuration data (RBAC data) from the EmpowerID Identity Warehouse according to the schedule set for it in the configuration file mentioned above. This data allows the reverse proxy to serve as the Policy Enforcement Point for your Web Access Management system and contains the following information:
So for reverse proxies, EmpowerID is able to determine who can access what by checking to see if a Application Subcomponent exists for the URL a person is trying to access. If one does exist, it checks the configuration data to see if there is a mapping of the person's Person ID to the WAM application Resource ID and the URLs or patterns associated with that application. If there is, access is granted; otherwise, access is denied.