This topic has 2 replies, 2 voices, and was last updated 6 years, 10 months ago by dalegre.

  • Author
    Posts
  • #6329
     dalegre
    Participant

    We’re having trouble with an unexpected policy decision.
    Having OpenAM on high availability behind a load balancer with these two policies

    Policy A
    Rules -> URL Policy : https://portal.intranet.es:443/auditor/*
    URL Policy : https://portal.intranet.es:443/auditor/*?*
    Allow GET y POST
    Subjects -> Authenticathed users

    Policy B
    Rules -> URL Policy : https://portal.intranet.es:443/auditor/login?idApp=52
    Allow GET y POST
    Subjects -> Authenticathed users
    Conditions -> Authentication Chaining using CERT as REQUIRED

    With this scenario in mind
    Following the URL https://portal.intranet.es:443/auditor/login?idApp=52
    OpenAM prompts the CERT, type in the code and successfully logs in.

    Following any other URL https://portal.intranet.es:443/auditor/login?idApp=00
    should prompt the username/password screen.

    The problem is when attempting to access the resource with the parameter ‘?idApp=52’, which should fall under Policy B, instead of CERT, OpenAM randomly prompts the username/password screen and upon correct authentication, allows access to the resource.
    In both cases, the logs are identical, except for the final decision. They always show the CERT condition but it’s apparently ignored.

    Architecture:
    OpenAM: 10.0.1 Behind LB
    Weblogic 10

    • This topic was modified 6 years, 10 months ago by dalegre.
    #6331
     Peter Major
    Moderator

    Both of your policies are actually matching the requested resource, hence either of them can grant access. Please also keep in mind that during policy evaluation OpenAM reorders the query string, so using idApp=52 in the rule may not actually work if you have other parameters in the query string.

    #6332
     dalegre
    Participant

    Thanks for your reply,

    When we attemped to open that resource (https://portal.intranet.es:443/auditor/login?idApp=52) we didn’t use any other parameters, and the decisions is “randomly” taken apparently…

    We can put here the logs…

    Thanks in advamce

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?