Autorization on Gateway

[landrzejewski]

I wonder if everything is fine with mapping roles on the Gateway. Regardless of the role assigned to the user at Keyklock level, Spring always sees ROLE_USER. After decoding the token, the roles are fine, so it looks like Spring can't read them and uses the default one. I tried to fix this based on examples shown at the service level, but it didnt worked. Can I ask you to verify this problem? Currently, roles cannot be verified at the Gateway level

[robbertvanwaveren]

not 100% sure which gateway you refer too, considering there are multiple gateway examples. But I believe neither do any RBAC. This is just because there is no mapping implemented, like at the service layer. Should be pretty much copy/paste from those if you really need it.

However, I personally believe that services should do their own RBAC and an API Gateway is not really the right place for it. As this would probably mean most significant service level changes would need an API Gateway level change as well. Effectively losing a part of the ability for separate deployment and autonomy over its business logic. (usually services are maintained by other teams as the gateway)

[landrzejewski]

Thank you for your answer. I meant Gateway in the spring-cloud-gateway-oidc-tokenrelay example. I agree with what you wrote, but I have a special case to solve - behind the gateway there is a regular static web application. Therefore, authorization on the Gateway would completely solve the problem. I tried to adopt the code from the services but I failed. Could you show a simple example with role mapping at Gatway level?

[timtebeek]

Hi @landrzejewski ; I'm afraid I don't have any samples of role mapping in a gateway right now; Up to now I've only used @AuthenticationPrincipal OidcUser user as argument to @Controller @GetMapping methods. This allows you to extract claims, but does not necessarily map them to roles on the user. An example of that can be found here.

The mock flights and mock hotels service in the spring-cloud-gateway-oidc-tokenrelay sample both use web mvc rather than webflux like the gateway, so the examples you see in there with a UsernameSubClaimAdapter might not transfer over well. I've not yet found a clear parallel in WebFluxSecurityConfiguration to set the same, but perhaps I've overlooked it before, or it has been added since I last implemented this sample.

Would it be possible to host the static web application inside a spring service similar to the mock flights service? Might not be ideal, but it could be a way around this problem for you for now.

[robbertvanwaveren]

A bit of a hack, but it's working and should get you started I hope. Please note that it seems Spring Security's OAuth client implementation specifically is not build for custom RBAC it seems.

@Bean
public OidcReactiveOAuth2UserService customUserService() {
	return new OidcReactiveOAuth2UserService() {
		@Override
		public Mono<OidcUser> loadUser(final OidcUserRequest userRequest) throws OAuth2AuthenticationException {
			OidcIdToken idToken = userRequest.getIdToken();
			Mono<OidcUser> userMono = super.loadUser(userRequest);
			return userMono.map(oidcUser -> {
				final Set<GrantedAuthority> augmentedAuthorities = new HashSet<>(oidcUser.getAuthorities());

				idToken.getClaimAsStringList("groups").stream()
					.map(String::toUpperCase)
					.map(roleName -> "ROLE_" + roleName)
					.map(SimpleGrantedAuthority::new)
					.forEach(augmentedAuthorities::add);

				return new DefaultOidcUser(augmentedAuthorities, idToken, oidcUser.getUserInfo()) {
					@Override
					public String getName() {
						return oidcUser.getName();
					}
				};
			});
		}
	};
}

[landrzejewski]

Wonderful! That's exactly what I needed, it works perfectly. Thank you very much for help!

[timtebeek]

Great to hear @landrzejewski ; Does that resolve your issue, or do you recon we'd best include this in the existing gateway sample?

As @robbert1 already indicated is isn't the cleanest of code, so I'm leaning towards leaving it out for now; possibly with a reference to here if needed. At least until there's a cleaner API to do the same.

[landrzejewski]

I think leaving this example here is ok - people who will need this information will be able to find it. Spring Security is changing rapidly so there may soon be a cleaner way to solve this problem. By the way, you have created very cool and helpful tutorials.

[timtebeek]

Perfect; I'll leave the issue open so the information is easier to find. We can pick it up again once we see a more agreeable API emerge in Spring Security. And thanks for the nice feedback! :)