Information needed to add PingAccess applications

When you use templates to PingAccess applications to PingCentral, you provide the application context root and then define its resources, application policy, and resource policies. This section describes these items in detail and explains why you are prompted to provide this information.

There are three different types of PingAccess applications: Web, API, and Web + API. With Web + API applications, administrators can configure both Web and API settings for an application. These applications can switch between web and API processing behaviors on the fly based on whether the inbound request contains a web session cookie (Web) or an OAuth token (API).

Resources
Path patterns
Rules and policies

Resources

Each application consists of one or more resources, which you define in PingCentral. Resources are components of an application that require different levels of security. When you define resources within an application, you also define security regarding those resources.

Resources are protected by rules, which let you specify who can access your applications and resources, how and when they can do so, and what modifications can be made to the requested content. When rules, or sets of rules, are applied to applications and resources, they are called policies. Policies are applied to requests, which determine whether users are granted or denied access to the requested resource.

To access an application, users enter a URL. This URL consists of a virtual host, a context root, and the name of the resource they want to access.

A screen capture identifying the virtual host, context root, and resource within a URL.

When you use a template to add a PingAccess application to PingCentral, you are prompted to provide the context root and define the resources within it. For more information, see Application resources in the PingAccess User Interface Reference Guide.

Path patterns

When handling requests, PingAccess uses resource path patterns to match resources. There are two different types of path patterns: Basic and Regex.

Basic patterns: The default path pattern type, which defines a path to a specific resource or a pattern that matches multiple paths. Basic patterns can contain any number of "*" wildcards. For example:
```
/path/x/*
```
matches any of these request paths:
```
/path/x/
/path/x/index.html
/path/x/y/z/index.html
```

Regex patterns: Regex patterns contain regular expressions and allow for more flexibility in resource matching as they support resource ordering. For example:

/[^/]+/[a-z]+\.html

matches any of these request paths:

/images/gallery.html
/search/index.html

However, it would not match any of these request paths:

/images/gallery2.html
/search/pages/index.html
/index.html

Although Regex path patterns function in an agent deployment, system performance might decrease if they are used. Agents are unable to interpret Regex path patterns, so they must consult PingAccess for policy decisions for each resource with a Regex path pattern.

When one or more path patterns match a request, PingAccess uses the first matching pattern it identifies, so the order in which path patterns are evaluated is important. By default, PingAccess orders path patterns automatically so that the most specific patterns are matched first. However, if more explicit control is needed, or if you are using regular expressions, enable resource ordering to manually specify the order in which path patterns are evaluated.

For example, an application might have three resources, such as:

/images/logo.png (Basic)
/images/* (Basic)
/.+/[a-z]\.png (Regex)

A request to resource /images/logo.png is matched by all 3 path patterns, yet each resource can have different policy requirements. Resource ordering allows you to specify which of these path patterns is parsed first, further allowing you to control the policy that is applied to a particular request.

When you define the application resources in PingCentral, you are prompted to provide path pattern information. For more information, see Path patterns reference in the PingAccess User Interface Reference Guide.

Rules and policies

Rules let you specify who can access your applications and resources, how and when they can do so, and what modifications can be made to the requested content. There are two different types of rules: access control rules and processing rules. Access control rules determine whether users can access a resource, and processing rules determine how requests are processed.

When you put rules together, they are called policies.

Application policies: Rules applied to the application as a whole. You can define Web rules and API rules for Web + API applications.
Resource policies: Rules applied to specific resources. Every application has at least one resource.

Rules can limit access based on information such as user attributes, client network range, time of day. You can combine rules to create rule sets, which are reusable and can be applied to many different resources and applications. Rule sets grant requests if any or all of the constituent rules are successful:

Any: An any rule set is evaluated from top to bottom and stops at the first rule that has its criteria met. If all rules fail, the request is denied.
All: An all rule set is evaluated from top to bottom and stops when it gets to the first rule that does not have its criteria met. If one rule fails, the request is denied.

Since rules within a rule set are evaluated from top to bottom, the order in which rules display in rule sets is important. In PingCentral, you can customize policies by dragging rules from the Available Rules list to the Policy list and changing the order to meet your needs.

A screen capture showing how the Available Rules list and the Policy list display side-by-side in PingCentral.

For more information, see Rules in the PingAccess User Interface Reference Guide.