PingCentral

Information needed to promote PingAccess applications

When you promote PingAccess applications to PingAccess environments, you provide virtual host, access validation, web session, and identity mapping information, as appropriate.

PingAccess can be deployed in one of two ways:

  • Gateway deployment: In a gateway deployment, the destination is a site. Requests are routed to a PingAccess web server, which then forwards authorized requests to the target application or API on the site.

  • Agent deployment: In an agent deployment, the destination is an agent. Requests are intercepted at the web server hosting the target application or API by the PingAccess agent plugin. The agent communicates with the PingAccess policy server to validate access before allowing the request to proceed to the target application or API.

The key difference between these deployments is where the initial request is directed. In a gateway deployment, the initial request is routed to a PingAccess web server, so the destination is a site. In an agent deployment, the initial request is routed to the web server that hosts the target application or API, so the destination is an agent. When you promote PingAccess applications, you are prompted to provide the name of the site or agent.

Gateway deployment

This diagram shows how users are authenticated, and how access policies and identity mappings are applied to requests to access applications or APIs with a gateway deployment.

This diagram shows how users are authenticated, and how access policies and identity mappings are applied to requests to access applications or APIs with a gateway deployment.

  1. Users enter a URL that consists of a unique virtual host and context root.

    • Virtual host: The public-facing host name and host port. For example, den.ping.com:8443.

      A wildcard (*) can be used either to define either any host (*:8443, for example) or any host within a domain (*.ping.com, for example). If a request matches more than one virtual host, the most specific match is used.

    • Context root: The common root of all resources, specifies where in the URL path the application begins, and starts with a slash. In the example URL, den-ping.com:8443/mygreatapp/home, /mygreatapp/ is the context root.

      PingCentral prompts you for the context root when you add the application, and for the virtual hosts when you promote it.

  2. The PingAccess web server determines whether a PingAccess session cookie (Web) or an OAuth token (API) exists for the user. If it does not, a web session starts. Web sessions define the policy for web application session creation, lifetime, timeouts, and their scope.

    If you promote Web + API applications in PingCentral, you are required to select a Web session from a drop-down list. This information is not required to promote Web or API applications.

  3. You can configure API and Web + API applications to use access token validators to locally verify signed and encrypted access tokens. If you are promoting an API or Web + API application in PingCentral, you can specify the access validation method, whether it be a token provider or a token validator, if appropriate.

  4. Users are authenticated through the web session.

  5. Policies are applied to the request. Policies are rules, or sets of rules, that are applied to application resources. PingAccess makes policy-based decisions to grant or deny access to the requested resource.

    You can customize application and resource policies when you use templates to add applications to PingCentral.

  6. Identity mapping is applied to the request if the target application expects user information to be included to further authenticate the user.

    PingCentral prompts you for the name of the Web and/or API Identity mapping, as appropriate, when you promote it.

  7. The user accesses the target web application or API.

Agent deployment

The following diagram shows hows users are authenticated, and how access policies and identity mappings are applied to requests to access applications or APIs with an agent deployment.

This diagram shows hows users are authenticated, and how access policies and identity mappings are applied to requests to access applications or APIs with an agent deployment.

  1. Users enter a URL to request access to a resource and their requests.

  2. The PingAccess agent plugin intercepts the request. Agents use names and shared secrets to authenticate with the policy server. These names and secrets do not need to be unique. Any number of agents can have the same name and secret, and they are all treated equally by the policy server.

  3. If the agent does not have previously cached policies for the resource, it contacts the PingAccess policy server for instructions.

  4. The PingAccess policy server receives claims from the token provider, which provides instructions for handling the request.

  5. Policies are applied to the request and PingAccess makes policy-based decisions to grant or deny access to the requested resource.

  6. Identity mapping is applied to the request if the target application expects user information to be included to further authenticate the user.

  7. The user accesses the target web application or API.