This topic has 2 replies, 2 voices, and was last updated 4 years, 10 months ago by chris-fry.

  • Author
  • #19590

    Hi all – a bit of a design question;

    I’ve just started playing around with Authorization Policies in Access Manager.

    It looks like there are many ways to approach these (akin to directory design) e.g. using a single policy set, or perhaps one set per application, one per information asset class (might be better for auditing) etc. Then there’s policy naming which could include a summary of the resources protected, a summarised business rule etc.

    Are there any reference materials that provides guidance for structuring and naming policies and policy sets?



    • This topic was modified 4 years, 10 months ago by chris-fry.
     Scott Heger

    Start here:

    In general, though, Policy Sets (formerly known as Applications) were designed to allow you to group together policies that pertain to a particular application. Then when AuthZ requests come from a particular application it requests which Policy Set to use. Policy Agents do this and by default they use the Policy Set (Application) called “iPlanetAMWebAgentService”. It is a configurable item in agent profiles though. If making AuthZ requests via REST you also specify the “application” to specify with Policy Set to be used. If the “application” is not specified via REST then by default the “iPlanetAMWebAgentService” Policy Set will be used.

    If all your applications use the same resource type and have basically the same policy structure then you could get away with a single general Policy Set with policies that apply across the board. When you start getting more fine grained and have different resource types and lots of different policies per application is when you would break them apart and call them specifically from each application.

    As for naming conventions, see the guide above for what characters are allowed and then be descriptive enough to make administration easy.


    Hi Scott, thanks for your reply.

    We’ve reached an approach that I think will work for our use case.

    We will use multiple policy sets (and avoid using the default set), grouping policies by technology type (because URL format is highly affected by this) and if required owning business unit (because in some cases a popular technology in an organisation may have multiple deployments managed by different groups). I’ll probably put some rough guidelines together like aiming for up to 5-10 policies per set.

    This should ensure sets remain manageable, perform well and limit the impact of policy mistakes.

    If anyone has other approaches, particularly for large-scale deployments that have worked for them, I’d love to hear them.

    – Chris

    • This reply was modified 4 years, 10 months ago by chris-fry.
Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?