What are ForgeRock AM Policies and Policy Sets?

ForgeRock AM's policy engine provides fine-grained authorization (FGAC) — the ability to define rules that control which subjects can perform which actions on which resources, and under what conditions. This is distinct from authentication (proving who you are); policies govern what you are allowed to do once authenticated.

The policy model has three key components:

Policy Set (Application) — A container that groups related policies. Each policy set defines the resource type patterns it governs (e.g., URL patterns for web applications) and the actions that can be controlled (e.g., GET, POST, DELETE). Before creating individual policies, you must have a policy set that covers the resource type in question. AM ships with default policy sets for web agents (URL-based), OAuth2 scopes, and others.

Policy — An individual rule within a policy set. A policy specifies:

• Resources — URL patterns or resource identifiers the policy applies to (e.g., https://app.example.com/api/*)
• Actions — HTTP methods or custom actions and whether they are allowed or denied
• Subjects — Who the policy applies to (authenticated users, specific groups, OAuth2 clients)
• Conditions — Environmental or contextual constraints (IP range, time of day, authentication level, device trust)
• Response Attributes — Additional attributes injected into the policy response that agents can use (e.g., user roles to pass as headers)

Policy Decision Point (PDP) vs Policy Enforcement Point (PEP) — AM acts as the PDP — it evaluates policies and returns decisions. Java agents, web agents, and IG act as PEPs — they intercept requests, call AM's policy endpoint, and enforce the decision by allowing or denying the request.

Policies are evaluated using AM's REST API: POST /json/policies?_action=evaluate. IG filters and AM Web/Java agents call this endpoint transparently on every protected request.