Role-based access to views

[heruan]

The OpenID Connect implementation in Spring inherits the concept of Granted Authorities and are accessible in the OAuth2AuthenticatedPrincipal interface. Authorities are string-valued attributes that express a high-level attribution of access rights to the authenticated user.

These authorities are configured in the OIDC provider's dashboard and are then transmitted into the JWT back to the application instance when the user is successfully authenticated, for example:

var user = (OidcUser) SecurityContextHolder.getContext().getPrincipal();
user.getAuthorities(); // => string collection of authorities, e.g. { "ROLE_ADMIN", "SCOPE_openid" }

With this setup, current Vaadin's authorization check performed by the ViewAccessChecker should work out-of-the-box ad documented in Enabling Security, e.g.

@Route("/admin")
@RolesAllowed("ROLE_ADMIN")
public class AdminView extends Board { ... }

We need to verify that each supported provider returns such authorities and document how to configure them in the provider's dashboards.

[DiegoCardoso]

I have assigned user to groups in Okta to see what would be returned by calling user.getAuthorities(), but I can't see the groups assigned to the user.

These are the groups assigned to my application:

(ROLE_BASIC_USER is only to make it different from ROLE_USER already being returned from getAuthorities)

And, as you can see, there's one user assigned under the ROLE_SUPERVISOR:

But, when I log the values coming from the user.getAuthorities() method, this is what I get:

AUTHORITIES: [ROLE_USER, SCOPE_email, SCOPE_groups, SCOPE_openid, SCOPE_profile]

I have done some configurations on Okta side and also added groups on the list of scope at the application.yml file, but nothing seems to work so far.

I have tested with Keycloak, but the results are pretty much the same.

---

I started to take a look on how to get more control over the authorities mapping and got some information from here.

You can register a mapping method with signature of public GrantedAuthoritiesMapper userAuthoritiesMapper() as a bean, but on my early tests, it didn't seem to be invoked.

Alternatively, a user service can be added, which gives us even more control, as described here:

	@Override
	protected void configure(HttpSecurity http) throws Exception {
		http
			.oauth2Login()
				.userInfoEndpoint()
					.oidcUserService(this.oidcUserService())
					...
	}

	private OAuth2UserService<OidcUserRequest, OidcUser> oidcUserService() {
		final OidcUserService delegate = new OidcUserService();

		return (userRequest) -> {
			// Delegate to the default implementation for loading a user
			OidcUser oidcUser = delegate.loadUser(userRequest);

			OAuth2AccessToken accessToken = userRequest.getAccessToken();
			Set<GrantedAuthority> mappedAuthorities = new HashSet<>();

			// TODO
			// 1) Fetch the authority information from the protected resource using accessToken
			// 2) Map the authority information to one or more GrantedAuthority's and add it to mappedAuthorities

			// 3) Create a copy of oidcUser but use the mappedAuthorities instead
			oidcUser = new DefaultOidcUser(mappedAuthorities, oidcUser.getIdToken(), oidcUser.getUserInfo());

			return oidcUser;
		};
	}