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:
User self-service features
Discover how end users can manage their profiles.
Single sign-on
Create seamless end user journeys.
SAML v2.0 federation
Federate identities with the SAML v2.0 standard.
OAuth 2.0-based federation
Protect applications with OAuth 2.0, OpenID Connect 1.0, and UMA 2.0.
Access policies and policy enforcement
Centrally control access to your organization’s applications.
Modern APIs for developers
Discover the REST 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 that store user profiles. 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 Configure user registration.
For details on building your own self-registration application using the REST API, see Register a user.
-
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 Configure forgotten password reset.
For details on building your own application to handle password reset using the REST API, see Reset forgotten passwords.
-
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. UI customization 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 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 Implement 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 SAML v2.0.
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 Implement 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-side 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 Authorization.
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 Import and export 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.
Learn more in the Web Agents documentation and the Java Agents documentation.
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.
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 REST API.
-
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 page. 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: