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 are certain that a particular AM service endpoint is not used in your deployment, you can block access to the endpoint.
For more information, see 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/openam/.
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-
Lists service configuration information. Use this page when translating configuration changes made in the console into corresponding
ssoadmcommands. showServerConfig.jsp-
Displays system configuration information, including the deployment URL, OS, Java VM, configuration directory, and more.
validat*.jsppages-
These files serve pages and provide endpoints for the classic, JATO-based UI when testing and verifying SAML v2.0 federation.
User interface JSP files
Some classic, JATO-based UI pages rely on JSP files in the com_sun_web_ui/jsp/ directory.
They are not intended to be used directly as external endpoints.
Authentication JSP files
The JSP files in the config/auth/default*/ directories provide templates and endpoints
to serve classic, JATO-based UI pages of the AM admin UI that allow users to authenticate.
To adapt the current UI for your deployment, see UI customization instead.
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 serve the Legacy OAuth 2.0/OpenID Connect authentication module.
They are not intended to be used directly as external endpoints.
SAML v2.0 JSP files
The JSP files in the saml2/jsp/ directory provide endpoints used in SAML v2.0 deployments.
See Federate identities for descriptions of externally useful endpoints.
WS Federation JSP files
The JSP files in the wsfederation/jsp/ directory provide endpoints used in WS-Federation deployments.
WEB-INF URL patterns
The AM .war file includes a deployment descriptor file, WEB-INF/web.xml.
The deployment descriptor lists services implemented as servlets,
and <url-pattern> elements that map services to AM endpoints.
When protecting an AM server, consider blocking external access to unused services based on their URL patterns.
The web.xml file changes from release to release. If you remove endpoints from this file to
disable access to parts of the AM configuration, make sure you review web.xml
when you upgrade to a new release of AM. Remove the restricted endpoints and
decide whether to disable the new endpoints.
You can find more information about securing your deployment by restricting access to endpoints in 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:
- Authenticate over REST
-
How to use the AM REST APIs to authenticate to AM.
- Policies over REST, Policy sets over REST, Resource types over REST, and Policy set application types over REST
-
How to use the AM REST APIs for policy management.
- Request policy decisions over REST
-
How to use the AM REST APIs for requesting authorization decisions from AM.
- Reset registered devices over REST
-
How to use the AM REST APIs to reset, or remove a user’s 2FA devices.
- OAuth 2.0 endpoints
-
How to use OAuth 2.0-specific endpoints to request access and refresh tokens, as well as introspecting and revoking them.
- OAuth 2.0 administration REST endpoints
-
How to use AM REST APIs to perform OAuth 2.0 administrative tasks such as registering, reading, and deleting clients.
- OpenID Connect 1.0 endpoints
-
How to use OpenID Connect-specific endpoints to retrieve information about an authenticated user, as well as validate ID tokens and check sessions.
- Retrieve forgotten usernames, Reset forgotten passwords, and Register a user
-
How to use the AM REST APIs for user self-registration and forgotten password reset.
- Configure realms over REST
-
How to use the AM REST APIs for managing AM identities and realms.
- Manage scripts (REST)
-
How to use the AM REST APIs to manage AM scripts.
- Capture troubleshooting information
-
How to use the AM REST APIs to record information that can help you troubleshoot AM.
- Manage sessions using REST
-
How to use the AM REST APIs to manage AM sessions.
- Consume REST STS instances and Query, validate, and cancel tokens
-
How to use the AM REST APIs to manage AM’s Security Token Service, which lets you bridge identities across web and enterprise identity access management (IAM) systems through its token transformation process.
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.
For an example, refer to /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.
For an example, refer to OpenID Connect Discovery.