Authorization Extension - Roles - Problem

Get Help
, , ,
1

I describe the case.

All users are users of google.

In my frontend, I’m using angular-auth0.
Example:

   angularAuth0Provider.init({
        clientID:AUTH0_CLIENT_ID,
        domain: .AUTH0_DOMAIN,
        responseType: 'token id_token',
        scope: 'openid profile',
        redirectUri: REDIRECT,
        audience: 'https://example-api.com'
    });

Backend: auth0-spring-security-api

JwtWebSecurityConfigurer
            .forRS256(audience, domain)
            .configure(http)
            .authorizeRequests()
            .antMatchers("/ping", "/pong", "/version").permitAll()
            .antMatchers("/api/v1/bye/**").permitAll()
            .antMatchers("/api/v1/hello/**").authenticated()

To my backend, several different Clients access, some one single page, others non-interactive through the API.

To users of the one simple page, I need to create ROLES.
I use “Authorization Extension”

Add the rules,

function (user, context, callback) {
  var namespace = 'http://example.com/claims/'; 
  context.idToken[namespace + "permissions"] = user.permissions;
  context.idToken[namespace + "groups"] = user.groups;
  context.idToken[namespace + "roles"] = user.roles;
  
  context.accessToken[namespace + "permissions"] = user.permissions;
  context.accessToken[namespace + "groups"] = user.groups;
  context.accessToken[namespace + "roles"] = user.roles;
  
  callback(null, user, context);
}

The problem comes with configuring JwtWebSecurityConfigurer,

Try using,

 .antMatchers("/ping", "/pong", "/version").hasAuthority ("ROLE_USER")
 .antMatchers("/ping", "/pong", "/version").hasAnyRole ("ROLE_USER")
 .antMatchers("/ping", "/pong", "/version").hasRole ("ROLE_USER")

But none works, all return 403.

Any ideas?

2

Based on the discussion that happened in this GH issue reported in the associated library repository the authorities are obtained only by looking at the scope claim of the received access token.

The above implies that although you’re including roles information in the access token, you’re doing so through the means of a custom claim http://example.com/claims/roles while the library will only read authority information from the scope claim. The mismatch in the claim name will then cause any use of hasAuthority to result in a 403 because the authority was not available.

One possible alternative would be the rule performing a transformation from roles to scopes and set them as appropriate so that the library will then read them and in this way allowing the use of hasAuthority.