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 Web Access Management system is an extension of EmpowerID and, as such, it integrates seamlessly with all the facilities of EmpowerID, including the Identity Warehouse, RBAC Engine, SSO Connection framework and workflow automation services. All these work together to enable organizations with Web-based resources to leverage EmpowerID for the same end-to-end level of security they rely on for their directory-based resources. Everything from password management to on-demand identity provisioning to tight access controls and SSO capabilities for WAM users is included with EmpowerID. There is no need for separate plug-ins or other applications.
The interface of the EmpowerID Web Application (as well as its WPF counterpart, the EmpowerID Management Console) serves as the Policy Administrative Point for EmpowerID Web Access Manager, providing functionality for configuring and managing the policies and identities within your infrastructure. From here, administrators, managers and other delegated people can provision and terminate users, create policies, assign roles and define who can do what with a given resource.
In Web Access Management, EmpowerID serves as an Identity Provider on behalf of a protected Web application. This means users must have an identity that can be vouched for by EmpowerID before they can access a protected resource. At the most basic level, this requires users have an EmpowerID Person, as it is the object used in conjunction with policy to determine what a given persona can or cannot do with a resource. EmpowerID's Identity Services are extremely flexible, able to be configured as an authentication hub that supports trusted relationships with all major Identity Providers using industry-standard protocols like SAML, WS-Federation, OpenID, and OAuth. In this way organizations can allow users with oft-used identities supplied by entities outside of their realm, such as Google, Facebook, or Twitter, among others, to access resources using a familiar login. The only prerequisite is those outside entities must be trusted by EmpowerID and those identities must be linked to an EmpowerID Person. Web applications themselves only need to trust EmpowerID; EmpowerID takes care of the rest.
In addition, EmpowerID allows organizations to step up their authentication requirements by providing the facilities for multi-factor authentication to support scenarios where more stringent security requirements must be met. For example, if certain pages contain material that is more sensitive than others, organizations can require users accessing those pages to verify their identities with another set of proofs. Multi-factor authentication options include device authentication, one-time passwords sent to mobile phones, knowledge-based authentication (Q&A), and a standards compliant OATH server for issuing hardware or software one-time password tokens.
The EmpowerID Identity Warehouse serves as the Policy Information Point for EmpowerID Web Access Manager. It is a multi-tenanted directory service that stores the relationship of a Person to the accounts they own for both traditional identity management as well as single sign-on.The EmpowerID Identity Warehouse stores each identity, role, policy, and resource that comprises an EmpowerID deployment as an managed object within a corresponding table in the Identity Warehouse. The Identity Warehouse is a key component in any SSO solution architecture, enabling organizations to house external identities without compromising internal AD security. External users can securely authenticate against the EmpowerID Identity Warehouse using single or multi-factor authentication and gain access to only the applications you want to grant to them. The Identity Warehouse provides full self-service and delegated administration capabilities that allow end users to manage their passwords and identity associations from the EmpowerID Web application user interface.
The EmpowerID RBAC engine serves as the Policy Decision Point for EmpowerID Web Access Manager, providing real-time services for evaluating and enforcing security policies for all resources protected by EmpowerID. The engine uses a number of EmpowerID Jobs and processes to continuously monitor an environment, tracking resources, identities, and policies to ensure users access only those resources to which they are entitled. The RBAC engine constantly evaluates this "resultant access" information so that user access levels always match policy requirements. If a user is placed in a role that no longer qualifies that user for access to a given protected resource, the RBAC engine pulls that information from the Identity Warehouse and removes the access right from the user the next time RBAC recalculation occurs
A proxy server is a machine that sits between clients and servers, intercepting traffic between the two. Proxies are generally categorized as “forward proxies” and “reverse proxies.” A forward proxy is a proxy that sits closer to the client, intercepting outbound traffic and usually requires some type of configuration on the client side to work. A reverse proxy is a proxy that sits closer to the server and acts on behalf of that server, often assuming its name and IP address in order to intercept HTTP requests directed toward that server. Clients have no direct knowledge of reverse proxies. When a transaction occurs between the two, the client thinks it is interacting directly with the server itself, not the proxy.
From a high level, this is represented by the below image. In the image, User A and User B are anonymously trying to access a URL that is protected by EmpowerID, "." Because this URL is a protected resource, EmpowerID directs those users to the EmpowerID Login page, where those users must authenticate themselves by submitting a set of credentials from a trusted Identity Provider. Upon authentication, the EmpowerID Reverse Proxy checks to see whether those users have the delegations to access the URL and sees that User A does and User B does not. Since User A has the authority to access the resource, the EmpowerID Reverse Proxy retrieves the requested page from the Web application and delivers it to her. Since User B does not have the authority to access the resource, the EmpowerID Reverse Proxy serves him an "access denied" message. User C, however, has requested a page that is not protected by the EmpowerID Reverse Proxy and is therefore not redirected to the EmpowerID Login page, but given immediate access.
The EmpowerID Web Agent is used in systems where resources need to be protected, but exposing the Web server that serves up those resources to HTTP traffic from external users is not an issue. In this case, the EmpowerID Web Agent is deployed against that server in favor of the EmpowerID Reverse Proxy. The EmpowerID Agent is an HTTP module that can be plugged in to the authentication pipeline in IIS for a .NET application. This allows organizations to load the agent in their Web applications so that each time a request for authentication against those Web applications occur, the code within the EmpowerID Agent is called to determine whether the user is authenticated to EmpowerID. If the user is not authenticated, the user is directed to the EmpowerID Login page where she must provide her credentials and be authenticated by the EmpowerID IdP in order to access the application serviced by the EmpowerID Web Agent. After the user successfully authenticates, EmpowerID passes the credentials for that user to the application. The EmpowerID Web Agent does not determine what the user can or cannot do in the application; that is determined by the application itself.
The EmpowerID Web Agent can be configured for two different authentication modes, Reverse Proxy mode and SAML mode. Depending on which mode is used, the mechanism for retrieving the identity of users differs. In Reverse Proxy mode, identity information is passed to the application via an HTTP variable set in the HTTP header, eid_user. This variable contains the user's EmpowerID login name. When configured for Reverse Proxy mode, the agent assumes that a trusted reverse proxy is making the request to the Web application and has set the identity in the HTTP header variable. In SAML mode, the agent reads the SAML assertion generated by the EmpowerID IdP and pulls out the Name Identifier from that assertion and passes it to the application.
The EmpowerID Web Agent can be set for either forms-based or claims-based authentication. These modes are used to determine the identity type used by the .NET Web application being protected, enabling EmpowerID to run the appropriate code to set the identity of the user. Once users authenticate, the next time they try to access the application within the same session, the agent passes the identity information to the application. There is no need to authenticate a second time.
The following image provides an overview of the flow that occurs in EmpowerID's Web Access Management system. In the image, an anonymous user is attempting to access a protected Web resource. Because this resource is protected by EmpowerID and the current user is anonymous, the EmpowerID Reverse Proxy or EmpowerID Web agent (depending on the method being used for the specific resource) intercepts the request to enforce the security policy specified for the resource. The user's browser is redirected to the EmpowerID Login page, where the user must submit credentials for the process to continue. Depending on how your SSO Connector framework is setup, users can choose to authenticate with credentials from any accepted third-party identity providers (IdP), such as Google, Facebook, or Twitter. (The user must have an EmpowerID Person with an account linked to the third-party IdP being used.) EmpowerID then checks those credentials against the EmpowerID Identity Warehouse to verify the identity of the user. If authentication is successful, identifier information for the user is returned to the calling application (EmpowerID Reverse Proxy or EmpowerID Web Agent), where it is processed and used to either allow or deny access based on the delegations associated with the user.