Service endpoints
A service endpoint is an entry point to a web service. This page lists AM service endpoints that are accessible by default.
If you’re certain a particular AM service endpoint isn’t used in your deployment, you can block access to the endpoint.
Learn more in Secure network communication.
JSP files
Some AM JSP pages are directly accessible as service endpoints.
The following sections describe the files for those JSP pages.
Directory paths in this section are relative to AM’s deployment path,
for example, /path/to/tomcat/webapps/am/.
Top-level JSP files
You will find these files in the top-level directory of AM’s deployment path.
Logback.jsp-
Provides a page to configure debug logging.
See Debug logging for details.
encode.jsp-
Provides a page to encode a cleartext password for use in SAML entity configurations.
getServerInfo.jsp-
Supports requests for server information. This page is used internally by AM.
isAlive.jsp-
Displays a "Server is ALIVE" message when AM is ready to serve requests.
proxyidpfinder.jsp-
Supports access to a remote identity provider through the federation broker.
services.jsp-
Only used for ssoadm, which has been removed.
showServerConfig.jsp-
Displays system configuration information, including the deployment URL, OS, Java VM, configuration directory, and more.
Authentication JSP files
The JSP files in the config/auth/default*/ directories were used only for authentication modules.
OAuth 2.0 JSP files
The JSP file, oauth2/registerClient.jsp, provides a template page
to register an OAuth 2.0 client application without using the main console.
The JSP files in the oauth2c/ directory were used only for authentication modules. They weren’t intended to be used directly as external endpoints.
WS Federation JSP files
The JSP files in the wsfederation/jsp/ directory provide endpoints used in WS-Federation deployments.
|
Previous versions of AM provided JSPs for SAML 2.0 standalone mode. These JSPs are now deprecated. You can still invoke the JSPs because they’re mapped to URLs for backward compatibility, but any customizations to the JSPs will be lost. Learn more in the release notes. |
Configure access to endpoints
When protecting an AM server, consider blocking external access to unused services.
You can either configure a reverse proxy (nginx, for example) to prevent access to endpoints,
or configure the deployment descriptor file, WEB-INF/web.xml, to use a custom version of
AmServletInitializer.
The Guice dependency injection framework initializes servlets and filters programmatically,
but you can still customize filters that don’t use Guice, such as SecureCookieFilter or SetHeadersFilter.
Register new filters by adding <filter> and <filter-mapping> elements to your web.xml file. If you’re overriding an existing filter, you only need to define the <filter> element, as AmFilterInitializer handles the corresponding mapping.
Find an example of customizing the SecureCookieFilter in
Exclude cookies from the filter.
The web.xml file and AM endpoints may change from release to release.
Review the API documentation and release notes to check for changes.
Learn more about securing your deployment by restricting access to endpoints in Protecting PingAM with PingGateway, How do I remove admin UI access in PingAM and Best practice for blocking the top level realm in a proxy for PingAM.
REST API endpoints
REST API endpoints are discussed in detail as follows:
| What do you want to do? | APIs |
|---|---|
Authenticate to AM and log out |
|
Create and configure authentication trees |
|
Manage a user’s registered devices |
|
Manage policies |
|
Request authorization decisions |
|
Use OAuth 2.0-specific endpoints to request access and refresh tokens, as well as introspect and revoke them |
|
Perform OAuth 2.0 administrative tasks such as registering, reading, and deleting clients |
|
Use OpenID Connect-specific endpoints to retrieve information about an authenticated user, as well as validate ID tokens and check sessions. |
|
Implement user self-registration and forgotten password reset |
|
Manage AM identities and realms |
|
Manage AM scripts |
|
Record information to help you troubleshoot AM |
|
Manage AM sessions |
|
Manage AM’s Security Token Service to bridge identities across web and enterprise identity access management (IAM) systems |
Well-known endpoints
The endpoints described in this section are Well-known URIs supported by AM:
/.well-known/openid-configuration-
Exposes OpenID Provider configuration by HTTP GET as specified by OpenID Connect Discovery 1.0. No query string parameters are required.
/uma/.well-known/uma2-configuration-
Exposes User-Managed Access (UMA) configuration by HTTP GET as specified by UMA Profile of OAuth 2.0. No query string parameters are required.
Find an example in /uma/.well-known/uma2-configuration.
/.well-known/webfinger-
Lets a client retrieve the provider URL for an end user by HTTP GET as specified by OpenID Connect Discovery 1.0.
Find an example in OpenID Connect Discovery.