You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some identity services provide scopes, for which we can use it to leverage and determine allowed roles in turn for Hasura RBAC permission system. This is critical for M2M authorization flows and scopes are part of OIDC spec.
Just like we have claims_map, we can have one for honoring scope where we can assign session variables for particular scope which would drive the authorization further in Hasura.
module.exports=function(client,scope,audience,context,cb){varaccess_token={};access_token['https://foo.com/claim']='bar';access_token.scope=scope;access_token.scope.push('extra');// you can write your business logic to include admin role in claim map, for example - https://hasura.io/jwt/claimscb(null,access_token);};
In your action, you can modify to check if scope string contains "admin", and if yes, then pass x-hasura-allowed-roles : ['admin'] value under claims_map . You may modify it to your needs as you said you wish to honor other scopes as well. In a nutshell, mapping the scope to that role and adding the admin secret (in header) is the objective for this approach.
Then you can attach this action to particular flow (like M2M). This can solve your use case for extracting scopes and then determining allowed roles.
The text was updated successfully, but these errors were encountered:
Is your proposal related to a problem?
Some identity services provide scopes, for which we can use it to leverage and determine allowed roles in turn for Hasura RBAC permission system. This is critical for M2M authorization flows and scopes are part of OIDC spec.
Sample token example:
Describe the solution you'd like
Just like we have claims_map, we can have one for honoring scope where we can assign session variables for particular scope which would drive the authorization further in Hasura.
Describe alternatives you've considered
One suggestion on top of my mind is to use Actions in auth0 where you can write business logic to extract scopes and create a mapping for claims there, and you can pass claim with x-hasura-allowed-roles or x-hasura-default-role mapped to admin. For ref - https://auth0.com/docs/customize/actions/write-your-first-action#add-custom-logic
In your action, you can modify to check if scope string contains "admin", and if yes, then pass
x-hasura-allowed-roles : ['admin']
value underclaims_map
. You may modify it to your needs as you said you wish to honor other scopes as well. In a nutshell, mapping the scope to that role and adding the admin secret (in header) is the objective for this approach.Then you can attach this action to particular flow (like M2M). This can solve your use case for extracting scopes and then determining allowed roles.
The text was updated successfully, but these errors were encountered: