Applications operations
Applications represent the protected web applications and APIs that receive client requests.
Applications:
-
Correspond to a single target site.
-
Have a common virtual host and context root.
The combination of virtual host and context root must be unique for each application.
-
Use a common web session and identity mapping.
-
Consist of one or more resources. Each application contains at least a root resource. Use resources to partition the application into areas requiring distinct access control.
Application types
There are three application types:
-
Web
-
API
-
Web+API
Web+API applications allow administrators to configure both Web and API settings for an application. These applications are able to 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). If the inbound request contains neither, PingAccess uses the method you specify as the fallback type for the application.
Protecting applications
Applications can be protected by a PingAccess gateway or a PingAccess agent:
-
In a gateway deployment, the target application is specified as a site.
-
In an agent deployment, the application destination is an agent.
To protect applications, you can apply access control and request processing rules on the <application type> Policy tab of the application configuration.
SPA Support
About SPA support
Single-page application (SPA) support merges the conventional 401 unauthorized response of an API application with the traditional 302 redirect response of a Web application, returned when a client request does not contain an authentication token.
The SPA supported result is a 401 response containing a JavaScript body that can initiate a 302 redirect. API clients will ignore the JavaScript body and react appropriately to the 401 response. However, browser clients will disregard the 401 response and execute the JavaScript body, resulting in a redirect to the token provider to authenticate. Since clients self-select the portion of the response they’re prepared to process, the result is a seamless authentication experience regardless of the client type.
Benefits of SPA support
When SPA support is enabled for Web+API applications, where a variety of client types are expected to communicate with the application, a fallback type is no longer required. This is because both web and API clients are properly redirected to authenticate by the same response. For Web applications, authentication challenge responses fulfill the same role. You can find more information in Authentication.
It might also benefit Web or API application types, for example, if a new version of a Web application contains JavaScript framework components to call APIs. In this case, SPA support can help mitigate issues in responding to different client types for authentication, but it won’t enable the full features of the other application type. You would need to migrate the application to a Web+API configuration to take advantage of the full functionality, such as for authentication, rules, or identity mapping.
Enabling SPA support
SPA support is enabled by default for Web applications. If you want to modify SPA support for Web applications, do so using an authentication challenge policy.
For API and Web+API applications, you can configure SPA support directly.
You can find additional guidance on preparing a SPA to work with PingAccess in the SPA developer’s guide on GitHub. This guide contains a sample application before and after onboarding.