Next Steps
AM can do much more than authenticate users. In addition to being the right foundation for building highly available, Internet-scale access management services, AM has a rich set of features that make it a strong choice for a variety of different deployments. Find out more about them:
| Discover how end users can create their own accounts, reset their passwords, and others. | Create seamless end user journeys using AM, Web Agents and Java Agents, or IDM. | Create seamless end user journeys by federating identities using the SAML v2.0 standard. |
| "OAuth 2.0 and OAuth 2.0-based Standards Federation" Protect applications and authorize clients to perform tasks on behalf of users with AM's OAuth 2.0, OpenID Connect 1.0, and User-Managed Access 2.0 standards. | "Policy Enforcement Points and Access Policies" Control who access your applications by writing policies that AM will evaluate to grant or deny access to your resources. AM's policy enforcement points or IG will enforce AM decisions and protect your applications or endpoints. | Discover the REST, RESTful, and Java APIs that AM exposes. |
User Self-Service Features
AM provides user self-registration and password reset services that allow users access to applications without the need to call your help desk.
AM has access to the identity repositories where user profiles are stored. AM is therefore well placed to help you manage self-service features that involve user profiles.
User Self-Registration. AM provides user self-registration as a feature of AM's REST APIs. New users can easily self-register in AM without assistance from administrators or help desk staff.
For information on configuring self-registration, see "Configuring User Registration".
For details on building your own self-registration application using the REST API, see User Self-Service Guide.
Password Reset. With AM's self-service password reset, users can help reset passwords, as well as update their existing passwords. AM handles both the case where a user knows their password and wants to change it, and also the case where the user has forgotten their password and needs to reset it, possibly after answering security questions.
For details on setting up password reset capabilities, see "Configuring the Forgotten Password Reset Feature".
For details on building your own application to handle password reset using the REST API, see Retrieving Forgotten Usernames.
Dashboard Service. Users often have a number of applications assigned to them, especially if your organization has standardized SaaS, for example for email, document sharing, support ticketing, customer relationship management, web conferencing, and so forth. You can create an interface for users to access these web-based and internal applications using AM's dashboard service.
The AM cloud dashboard service makes this relatively easy to set up. For basic information on using the service, see Dashboards.
AM's user-facing pages are fully customizable and easy to skin for your organization. The Installation Guide has details on how to customize user-facing pages.
Single Sign-On
Single sign-on (SSO) and cross-domain single sign-on (CDSSO) are core features of AM. Once you have set up AM, you protect as many applications in the network domain as you want. Simply install web or Java agents for the additional servers, and add policies for the resources served by the applications. Users can authenticate to start a session on any site in the domain and stay authenticated for all sites in the domain without needing to log in again (unless the session ends, or unless a policy requires stronger authentication.
Many organizations manage more than one domain. When you have multiple distinct domains in a single organization, cookies set in one domain are not returned to servers in another domain. In many organizations, sub-domains are controlled independently. These domains need to be protected from surreptitious takeovers like session cookie hijacking. AM's CDSSO provides a safe mechanism for your AM servers in one domain to work with web or Java agents from other domains, while allowing users to sign-on once across many domains without needing to reauthenticate. CDSSO allows users to sign on in one of your domains and not have to sign on again when they visit another of your domains.
For details on how to configure web and Java agents for CDSSO, see "Implementing CDSSO".
SAML v2.0 Federation
Security Assertion Markup Language (SAML) 2.0 grew out of earlier work on SAML v1.x and the Liberty Alliance. SAML defines XML-based, standard formats and profiles for federating identities. SAML v2.0 is supported by a wide range of applications including major software as a service (SaaS) offerings. AM can function as a hub in deployments where different standards are used. For details on AM's SAML v2.0 capabilities, see the SAML v2.0 Guide.
When your deployment serves as an identity provider for a SAML federation, AM makes it easy to develop applications called Fedlets that your service providers can easily deploy to participate in the federation. For details, see Implementing SAML v2.0 Service Providers by Using Fedlets.
OAuth 2.0 and OAuth 2.0-based Standards Federation
OAuth 2.0 and OpenID Connect 1.0 are open standards for authorization using REST APIs to allow users to authorize third-party access to their resources. These standards make it easier to federate modern web applications. User-Managed Access (UMA) 2.0 takes OpenID Connect a step further, and lets the end user manage access to their resources.
AM can serve as the authorization server for your clients, or as a client to another authorization server. As an authorization server, AM supports capabilities such as:
Dynamic client registration
Using macaroons as access and refresh tokens
Client-based access and refresh tokens
Proof-of-possession
Scripted OpenID Connect claims
Authentication requirements for ID tokens.
For more information, see:
Policy Enforcement Points and Access Policies
AM can handle large numbers of access policies, each of which gives you control over user provisioning and user entitlements. For details, see the Authorization Guide.
AM also supports standards-based access policies defined using the eXtensible Access Control Markup Language (XACML). XACML defines an XML Attribute-Based Access Control (ABAC) language with Role-Based Access Control (RBAC) features as well. For details on using XACML policies with AM, see Importing and Exporting Policies.
AM also includes Web Agents and Java Agents, which are add-on components that operate as a policy enforcement point (PEP) for a website or application. For example, you can install a web agent to enforce AM's authorization decisions on Apache HTTP Server.
For details, see the ForgeRock Web Agents User Guide and the ForgeRock Java Agents User Guide.
Furthermore, ForgeRock Identity Gateway works with applications where you want to protect access, but you cannot install a web or Java agent. For example, you might have a web application running in a server for which no agent has been developed. Or you might be protecting an application where you simply cannot install an agent. In that case, IG functions as a flexible reverse proxy with standard SAML v2.0 capabilities. For details see the ForgeRock Identity Gateway documentation.
Modern APIs For Developers
For client application developers, AM offers REST and Java APIs.
AM REST APIs make the common CRUD (create, read, update, delete) easy to use in modern web applications. They also offer extended actions and query capabilities for access management functionality.
To get started, see Getting Started with REST.
AM Java APIs let your Java and Java applications call on AM for authentication and authorization in both AM and federated environments.
For details, see the ForgeRock Access Management Java API Specification.
AM provides built-in support for many identity repositories, web servers and web application containers, access management standards, and all the flexible, configurable capabilities mentioned in this chapter. Yet, for some deployments you might still need to extend what AM's capabilities. For such cases, AM defines Service Provider Interfaces (SPIs) where you can integrate your own plugins. For information about extension points, and some examples, see the following: