Transactional authorization using jwt based subject (jwtSubject)

Troubleshooting
, , ,
1

I am looking to implement policy evaluation for transactional authorization using IG policyEnforcement filter. However, we have a requirement to use jwtSubject instead of ssoTokenSubject. wondering if anyone had done this before.

I am trying to implement example as described in doc Policy enforcement :: ForgeRock Identity Gateway.

Any input or pointers would be helpful.

Thanks,
Ragha

2

greetings @halliragha ,

Firstly, I’m always happy to hear when a customer decides to use the policy framework for fine grained authorizations, which may or may not include Advices or Transaction Authorization. Now if we could only get more customers to use the OAuth2 Claims implementation… as opposed to providing a claims script in the OAuth2 Provider… Another challenge for another day.

Within the policy itself, there is a provision for the Subject criteria to reference an OIDC/Jwt Claim. Have you tried that? What was your outcome please?

3

First thing is to understand the ‘jwt’ parameter of the Subject in an authorization policy. I wrote about this many years ago! Yet another user name and password: Fun with OpenAM13 Authz Policies over REST - the ‘jwt’ parameter of the ‘Subject’
Then you need to pass the id_token from IG to AM. See Filters :: ForgeRock Identity Gateway for details about the jwtSubject config option for the filter.
Sorry - I don’t have an example, but hope this helps!

2 Likes
4

I remember reading that! And was so hopeful to see a future where dynamic OAuth2 scopes, derived via the policy framework would take hold.

One thing is certain, having IG now certainly does simplify my integration needs.

1 Like
5

thanks for your inputs, I have tested the policy evaluation with subject as JWT. However, policy evaluation works with jwt subject only when there is no transactional environment condition in the policy.

AM returns 200 OK with below response when add transactional environment condition as below:

{
  "type": "Transaction",
  "authenticationStrategy": "AuthenticateToTreeConditionAdvice",
  "strategySpecifier": "JourneyStepUpAuth"
}

[
    {
        "resource": "http://localhost:80/stepup",
        "actions": {},
        "attributes": {},
        "advices": {},
        "ttl": 0
    }
]

Thanks,
Ragha

6

Perhaps i misunderstood you.
Firstly,
The successful outcome of Auth-N is always an ssotoken/ssotokenid.
It seems your actor has no ssotokenid. Therefore “how” did you wish to complete the Auth-N of a step-up flow, if there is no previous session to “step-up”?
If you just want to Auth-N, ?forceAuth=true , would accomplish that.

Secondly, correct. That would be the first response from Auth-Z. In turn, the client (and actor) must be redirected to the Auth-N interface, in order to initiate the step-up, Auth-N process.

Incidentally, I notice your AM is deployed on “localhost”???