--- title: App Policy Decision node description: The App Policy Decision node is a specialized version of the Policy Decision node designed to simplify the evaluation of application access policies within a journey. component: auth-node-ref version: latest page_id: auth-node-ref::app-policy-decision canonical_url: https://docs.pingidentity.com/auth-node-ref/latest/app-policy-decision.html keywords: ["Nodes & Trees", "Journeys", "Authentication"] superseded_by: https://docs.pingidentity.com/auth-node-ref/latest/app-policy-decision.html section_ids: example: Example prerequisites: Prerequisites example_journey: Example journey inputs: Inputs dependencies: Dependencies configuration: Configuration outputs: Outputs callbacks: Callbacks outcomes: Outcomes errors: Errors --- # App Policy Decision node The App Policy Decision node is a specialized version of the [Policy Decision node](policy-decision.html) designed to simplify the evaluation of application access policies within a journey. For example, use the node to restrict access based on user attributes, such as ensuring only end users in a specific finance group can access a finance portal. You don't need to configure the node because it automatically identifies the policy set and resource from the journey context. However, the node assumes the following prerequisites: * The node is used within an OAuth 2.0/OIDC or SAML application journey. * The application ID (OAuth 2.0 client ID or SP entity ID) is specified as the resource when the journey is invoked. * An access policy with that resource is defined within the application. The outcome of the policy evaluation, to accept or reject access, map to the node's outcomes. It doesn't handle advices or environment conditions. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | Consider the following security risks when designing journeys that include policy evaluation:- Brute force information disclosure An authenticated user can probe the policy framework by submitting different inputs to determine who or what passes or fails a policy evaluation. To prevent this, design journeys so that the policy framework isn't directly exposed to repeated probing. For example, block or lock out a session after a set number of failed attempts, just as you would for other authentication mechanisms. - Denial of service (DoS) Unauthenticated users could repeatedly trigger policy evaluations, which can consume significant resources and increase the risk of a DoS attack. To reduce this risk: \* Protect the deployment at the container or network edge, for example, with a reverse proxy. \* Place the policy node after the user has authenticated whenever possible, to limit the attack surface. + This can also prevent information disclosure, such as exposing group membership based on submitted usernames. | ## Example This example uses an App Policy Decision node to manage access to a finance portal application based on usernames. ### Prerequisites The following setup is assumed: * A test end user, added to the `Finance` group. * An OIDC application, with the following settings: * Client ID `finance-app` * Use a journey to authenticate users to this application example journey * A policy that allows access to an end user in the Finance group. * Resources `finance-app` * Actions `ACCESS:Allowed` * Subjects ``` { "type": "NOT", "subject": { "type": "NONE" } } ``` * Environments ``` { "type": "OR", "conditions": [ { "type": "IdmUser" "identityResource": "managed/alpha_user", "queryField": "/_id", "decisionField": "/effectiveGroups/*/_refResourceId", "comparator": "EQUALS", "value": "Finance" } ] } ``` > **Collapse: How to create this policy** > > 1. Go to Native Consoles > Access Management, go to Realms > *Realm Name* > Authorization > Policy Sets. > > 2. Click Customer Application Policy Set to add a policy. > > You *must* use this policy set for app authorization. > > 3. Click + Add a Policy. > > 4. Provide a name and select Authentication as the resource type. > > 5. Select `*` as the resource pattern and add the client application ID, `finance-app`, as the resource. > > 6. Click Create. > > 7. Add an action of type `Access` and save your changes. > > 8. Add a subject condition of type `Never Match` in a `Not` logical block and save your changes. > > 9. Add an environmental condition: > > 1. Click Add an Environment Condition, select `IDM User`, and add the following values: > > * Identity Resource > > `managed/alpha_user` > > * Query Field > > `/_id` > > * Decision Field > > `/effectiveGroups/*/_refResourceId` > > * Comparator > > `Equal to` > > * Value > > `Finance` > > 2. Click the checkmark ([icon: check, set=fa]) button to finish. > > 3. Click Add a Logical Operator, select `Any of..`, and move the enviromment condition into the logical block. > > 4. Save your changes. > > Verify that the policy summary looks like this: > > ![app policy decision idmuserpolicy](_images/app-policy-decision-idmuserpolicy.png) > > Learn about configuring policies in [Policies in the UI](https://docs.pingidentity.com/pingoneaic/am-authorization/policies-ui.html). ### Example journey ![Policy Decision node in an app authorization flow](_images/app-policy-decision-example.png) * The authorization journey is invoked specifying the OAuth 2.0 client ID as the resource, for example: `https://tenant-env-fqdn/am/oauth2/alpha/authorize?client_id=finance-app&redirectUri=http://www.example.com/signin&scope=openid&response_type=code` - The [Page node](page.html) containing the [Platform Username node](platform-username.html) and [Platform Password node](platform-password.html) prompts for credentials. - The [Data Store Decision node](data-store-decision.html) validates the username-password credentials. - A successful authentication routes the journey to the App Policy Decision node. The node has no configuration, but relies on the journey context and prerequisite configuration to identify the OAuth 2.0 client ID resource (`finance-app`). It can then locate the access policy to evaluate whether the end user is a member of the `Finance` group. - The outcome of the policy evaluation determines the path of the journey: * Accept The policy grants access. The [Message node](message.html) informs the end user they're authorized and the journey is successful. * Reject The policy rejects access. The [Message node](message.html) informs the end user they're not authorized. * Error An error in policy evaluation leads to the failure outcome. * Unknown Resource The node failed to identify the resource and the journey continues to the [Set Error Details node](set-error-details.html). ## Inputs If policy evaluation requires a subject, make sure the username is collected earlier in the journey. ## Dependencies This node requires the following configuration: * An application (OAuth 2.0 client or SAML SP entity) that uses a journey with an App Policy Decision node * An access policy defined within the application ## Configuration This node has no configurable properties. ## Outputs This node doesn't change the shared state. ## Callbacks This node doesn't send any callbacks. ## Outcomes * Accept Policy evaluation succeeded. * Reject Policy evaluation didn't succeed. * Error If an error occurs during policy evaluation. * Unknown Resource If the node failed to identify the OAuth 2.0 or SAML 2.0 resource. ## Errors The node logs an error if policy evaluation fails.