Multiple Applications' Roles visible in tokens

Help
,
1

We’re trying to implement Application Specific Roles and only have the roles associated with the application being signed into visible in the corresponding token(s).

We’re using the RBAC extension with the published rule and we have multiple clients with roles specific to each.

for example:
Application A has roles (A1, A2)
Application B has roles (B1, B2)

and we’ve added the custom rule here:

After the rbac extension generated rule.

What we’re seeing is that a user authenticating against Application A is seeing roles A1/A2 (expected) but is also seeing B1/B2 which is not the expected behaviour.

What we expected is that only roles A1/A2 would be visible to Application A, not B1/B2.

I realise that we have to filter the “roles” by client Id but how / where should that be implemented?
As in where are the client specific roles exposed in the context object?

Thanks,
Brett

2

Hi @bdellegrazie,

We have an FAQ that relates to this topic: How do I create the same roles in different applications?

If you would like to only include the roles for a specific app in the tokens, then you could namespace the roles and filter the roles using the namespace for the app. You can see which app it is in the Context Object: Context Object Properties in Rules

1 Like
3

Hi @stephanie.chamblee ,

Thanks for your response however, isn’t this what the API call /api/users/{userId}/policy/{clientId} against the RBAC extension is intended to do?

Thanks in advance

4

Hi @bdellegrazie,

Are you using the Authorization Core or the Authorization Extension?

The rule you linked in the original post should only work when using the Authorization Core, however, the /api/users/{userId}/policy/{clientId} endpoint is for the Authorization Extension.

You can read more about the differences here:

That is correct about that endpoint if using the authorization extension! The extension attaches roles to specific applications whereas the authorization core does not.

5

Hi @stephanie.chamblee ,

I am using the Authorization Extension - so this makes perfect sense, thank you.
One related question - the “connectionName” element - does that need to be prefixed by the connection type, e.g. “samlp” - so a SAML connection called “onelogin” would be passed as “samlp|onelogin” for example?

I keep getting a 400 error from this API and I’m struggling to figure out why - even with an empty set of groups.

Thanks in advance

6

I believe it should match the connection name you get back from GET/api/v2/connections, but I’ll have to look into whether you need to set up this mapping.

When you look at your tenant logs (Auth0 dashboard > Monitoring > Logs) after making the request, can you find the error? Or do you receive any error message with the 400 response?

7

Hi @stephanie.chamblee ,

I see nothing in Monitoring > Logs other than the successful authorization request to get the API key to talk to the Authorization Extension - unfortunately, the extension call logs are not visible since I’m calling this (for debugging) externally.

I’m deliberately making other requests just prior (get groups for user, get roles for user) to ensure I have the correct API key and URls etc. - they’re all successful.
Just the POST call to evaluate the policy fails and I can’t quite figure out why.

Thanks in advance

8

I see, that makes sense. I found a support ticket in our system about this with this response from engineering:

Per engineering, “The connectionName parameter does matter in cases where you are evaluating group relationships through mappings. The endpoint needs to be aware of which connection you want to use to find external groups through mapping.” But outside those situations the value of connectionName doesn’t matter, as you observed. Engineering put a note in their backlog about improving this, but I think with the focus on improving our Authorization Core functionality, it probably won’t be fixed before the authn extension is deprecated in favor of Core.

Since you are not passing groups, can you try passing an empty string for connectionName ({“connectionName”:“”})?

9

HI @stephanie.chamblee ,

Using the realtime logs extension - that’s providing more information:
(I’ve elided personal details)

This is the curl request:

# Get User Policy for Client ID
curl --fail --max-time 10 --request POST \
  --url "${AUTH0_AUTHZ_API}/users/${TARGET_USER_ID}/policy/${TARGET_CLIENT_ID}" \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --header "Authorization: Bearer ${AUTH0_AUTHZ_API_TOKEN}"
  --data-binary @- << EOF
{
  "connectionName": "onelogin",
  "groups": []
}
EOF

This is the response:

210624/134711.923, [log,error] data: Request: POST /api/users/:userid/policy/:clientId
2:47:11 PM:
 210624/134711.923, [log,error] data: Response: {
"data": {
"isJoi": true,
"name": "ValidationError",
"details": [
{
"message": "\"value\" must be an object",
"path": "value",
"type": "object.base",
"context": {
"key": "value"
}
}
],
"_object": null
},
"isBoom": true,
"isServer": false,
"output": {
"statusCode": 400,
"payload": {
"statusCode": 400,
"error": "Bad Request",
"message": "\"value\" must be an object",
"validation": {
"source": "payload",
"errors": [
{
"key": "value",
"path": "value",
"message": "\"value\" must be an object",
"type": "object",
"constraint": "base"
}
]
}
},
"headers": {}
}
}
10

Hm, I’m not sure why your cURL command is not working, but I tried it out in my own tenant and I’m seeing the same error. However, when I send the request like this, I am getting a 200:

curl --request POST \
  --url 'https://{extension_url}/users/{user_id}/policy/{client_id}' \
  --header 'Authorization: Bearer {access_token}' \
  --header 'content-type: application/json' \
  --data '{ "connectionName": "Username-Password-Database"}'

Note: connectionName is required, but the request is successful with any string

11

Hi @stephanie.chamblee ,

Thank you very much - I’ve just located my error - missing line continuation (\) on the line before the --data-binary option - this caused the cURL command to be wrong.

It’s all working now - really appreciate your time.

Thanks!

1 Like
12

Great! Glad the issue is resolved.

13

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.