So after 3 years at ForgeRock on my path to accreditation, I am finally going through AM-400 again and I wanted to try and re-write and extract my notes into something useful and really simple to understand, I hope you like it, please bear in mind I am always learning so this might not be the most detailed but certainly easier to understand for a visual mind!
AM (Access Management) uses authentication to verify the identity of users and non-human entities (such as IoT devices, browsers, cars, fridges). It acts like border control at an airport, where all users are directed to AM for identity verification.
I will discuss only Stateful server-side scenario for the purpose of the analogy, please be aware that a stateless option is also available where the token SSOTokenID is provided on request bypassing the need for a CTS.
A successful authentication results in an AM session (SSOToken), which represents the user to all AM-enabled devices. The SSOToken is not given directly to the user or device, but a reference to it (SSOTokenID) is provided. AM can retrieve the related session using the SSOTokenID and respond to the request accordingly.
AM has a flexible and modular architecture with multiple plugin points. It’s 100% Java-based and has three main sections: protected resources, API layer, and core services. The API layer, consisting of REST APIs and ForgeRock Common REST API, is exposed to the outside world and used by edge devices to communicate with AM. The core services include the authentication management service.
AM has a configurable behavior, controlled by its properties. The code that implements this behavior is found in the AM Service Provider Interfaces (SPIs). The graphic also shows that AM has an admin console, a command-line interface (CLI), and an embedded configuration store. You’ll learn more about the admin console throughout the class. The embedded configuration store is an instance of ForgeRock Directory Services (DS), which is installed automatically when AM is installed. although embedded DS which is not used anymore in 7.x is not recommended for production in 6.x either.
When accessing a website, application, or service protected by AM, it’s like arriving at an international airport and needing to go through border control. Just like the airport, the end user needs to authenticate themselves to AM in order to gain access to the protected resource or service.
Imagine the AM login page as the airport’s border control checkpoint, and the end user accessing it as a traveler trying to enter the country. The AM user interface (the login page) acts like a REST client and accesses AM’s authentication service, much like the traveler presenting their passport to the border control officer.
Just like how the border control officer checks the traveler’s passport against a database of authorized individuals, AM checks the user’s credentials against a store to verify their identity. Credentials can be a combination of username and password, a smartcard reading, or a certificate.
Once the authentication process is complete, AM will grant the user access to the protected resource or service, much like the border control officer stamping the traveler’s passport and allowing them to enter the country.
The stamped passport lets you in and creates a session that holds information about your identity and the authentication process, and it allows you to access other protected resources without having to re-authenticate. This is similar to the stamp in your passport allowing you to travel to other destinations without having to go through border control again. The session reference is called an SSOTokenID and it’s like the passport stamp, it identifies you and your session to AM.
In summary, AM’s authentication process is similar to the border control process at an airport, where you must present your credentials and have them verified before being granted access to protected resources.
If you like this and want more Id love to keep sharing what I have learned