Security(Web)FilterChain in the bff tutorial

[rgambelli]

Hi all,

there is something I don't understand reading either bff tutorial, now moved here and the explanation contained in spring-addons-starter-oidc readme.

The readme states the a Security(Web)FilterChain is created If spring-boot-starter-oauth2-resource-server is on the classpath and unless com.c4-soft.springaddons.oidc.resourceserver.enabled=false and that's ok.

The tutorial bff project, which is obviously an oauth2 client depends only from spring-boot-starter-oauth2-client, it does not depends from spring-boot-starter-oauth2-resource-server, nevertheless in its application.yml there is this:

# SecurityFilterChain with oauth2ResourceServer() (sessions and CSRF protection disabled)
        resourceserver:
          permit-all:
          - /login-options
          - /error
          - /v3/api-docs/**
          - /swagger-ui/**
          - /actuator/health/readiness
          - /actuator/health/liveness

which seems saying that a second SecurityFilterChain is created too.

As I'm trying to implement a bff solution based where I have 4 spa applications which communicate with single bff which in turns send requests to different resource servers, but my bff hosts some REST api too, for example the login-options described in the pattern but other endpoints too which need to be secured with session token, I would like to understand if I need to depends from spring-boot-starter-oauth2-resource-server or not.

Thanks for the clarification, bye

[ch4mpy]

Hi,

I think you spotted an issue in the Baeldung repo.

Yes, the BFF should depend on spring-boot-starter-oauth2-resource-server for spring-addons-starter-oidc to create the "resource server" filter-chain: ReactiveSpringAddonsOidcResourceServerBeans is conditional on IsOidcResourceServerCondition which can be true only if HeaderBearerTokenResolver is on the classpath.

And also, yes, spring-addons-starter-oidc creates two distinct fiter-chains if the requires conditions are met:

• spring-boot-starter-oauth2-client and spring-boot-starter-oauth2-resource-server on the classpath
• com.c4-soft.springaddons.oidc.resourceserver.enabled=true (which is the default)
• non-empty com.c4-soft.springaddons.oidc.client.security-matchers

The "client" filter-chain having higher precedence, be careful not to hide your REST endpoints behind it with too wide client security-matchers.

Another caveat for your implementation: be aware that only an OAuth2 client can query a protected resource server endpoint (only OAuth2 clients can attach a Bearer token to the request). So, if you want your frontends to query the REST endpoints you host on the BFF itself, you might have to define a distinct route with the TokenRelay. For instance if your REST endpoint on the BFF is @RequestMapping("/bidule"), you might have to query /api/bidule from the frontend, with an entry under spring.cloud.gateway.routes having:

• Path=/api/bidule predicate
• the TokenRelay filter to add an access token
• StripPrefix=1 to loop to /bidule

So requests to /api/bidule from the frontend would be authorized with a session cookie and those internally forwarded to /bidule would be authorized with a Bearer access token.

Hope I was clear enough :/ This is just the regular BFF stuff but can be a bit confusing in this case...

P.S.

Your system will scale better if you put the less possible features in the BFF which is the only backend service needing sessions (actually, not really the only one as the authorization server uses sessions too, but this is another story). Resource servers can be stateless, which make it super easy to scale, but the later and the less you have to scale the BFF, the better (when scaling the BFF, you'll have to use Spring Session or a smart proxy routing all requests from a given device to the same instance). So long story short, if I were typing on your keyboard, I'd move these REST enpoints in standalone resource server service(s) ;)

[rgambelli]

Thank you, your information was very valuable in helping me better understand a series of aspects, in extreme summary bff endpoint must not appear in the client.security-matcher, am I wrong?

Regarding the creation of the SecurityFilterChain when you write this:

Yes, the BFF should depend on spring-boot-starter-oauth2-resource-server for spring-addons-starter-oidc to create the

"resource server" filter-chain: ReactiveSpringAddonsOidcResourceServerBeans is conditional on IsOidcResourceServerCondition which can be true only if HeaderBearerTokenResolver is on the classpath.

I have just debugged the tutorial project, so that one without spring-boot-starter-oauth2-resource-server and saw that a SecurityWebFilterChain is created! This one:

@Conditional(IsJwtDecoderResourceServerCondition.class)
    @Order(Ordered.LOWEST_PRECEDENCE)
    @Bean
    SecurityWebFilterChain springAddonsJwtResourceServerSecurityFilterChain

Indeed it is only thanks to that FilterChain that the login-options worked, I mean that commenting out resourceserver.permit-all the login-options was not been authorized, the AuthorizationWebFilter said Authorization failed...
Is it possible I found a bug? It seems yes

I would like to ask you another question about endpoints to a resource server (not to the bff-server):

1. should they be intercepted by client.security-matchers? From what I understand the answer is yes because that is where oauth2Login happens
2. should they appear in the client.permit-all ? From what I understand the answer is no as I want them to be authenticated, but if I look again to the baeldung tutorial, I see this:

client:
          client-uri: ${reverse-proxy-uri}${bff-prefix}
          security-matchers:
          - /api/**
          - /login/**
          - /oauth2/**
          - /logout
          permit-all:
          - /api/**
          - /login/**
          - /oauth2/**

I see that /api is in permit-all, why does it is in permit-all?

Then, with the spring.cloud.gateway.routes (id bff, the only one present in tutorial), the url /api/me is stripped thanks to StripPrefix=1 so resulting url is only /me, I don't understand what happens to that /me:

• goes through the two filter chains again, client and resourceserver (even if in the tutorial there is no ServerFilterChain as already said)? I believe not because differently it would not pass security matchers on client, so what happens exactly to the /me?

Really thanks and well done for the huge work about spring-addons

[ch4mpy]

in extreme summary bff endpoint must not appear in the client.security-matcher, am I wrong?

I would rather phrase: "client.security-matcher should match only the endpoints needing session and not REST endpoints with Bearer authorization".

So if what you mean by "bff endpoint" are the REST endpoints you expect to be authorized with access tokens, your assomption is true. But a BFF definitely has other endpoints at least for out2Login, logout and routed requests which are all authorized with sessions in the "client" filter-chain. For sure, client.security-matcher must match this other endpoints...

1. should they (BFF routes to downstream resource servers) be intercepted by client.security-matchers?

Yes, because this routes need the TokenRelay filter, which need to access the access token stored in session, which is maintained by the SecurityWebFilterChain with oauth2Login.

2. should they (BFF routes to downstream resource servers) appear in the client.permit-all ?

It "must" at minimum for the route to the downstream endpoints for which you want to "permit-all". For other downstream endpoints, it does not "have to" but it "can".

In the tutorial (and all my apps), resources access control is handled solely by resource servers. The frontends maintain user login state (to adapt UI depending on the user being identified or not) and would use route guards (or would handle the 401 returned by the resource server) to trigger login by themselves instead of relying on Spring's client with oauth2Login redirection. So permit-all on the BFF route is a perfect fit in that case.

If it was only to me, unauthorized requests would always be answered 401 Unauthorized appart maybe in apps with templates rendered by Spring (Thymeleaf and alike) where the 302 Redirect to login can be an interesting "hack".

Also, when opting for a systematic permit-all on the BFF for routed requests, you know that an access-control issue is to diagnose and fix only on the resource servers. That makes coders life easier.

what happens exactly to the /me?

/api/me is matched against Path=/api/** on the BFF. So it is routed to uri: ${scheme}://${hostname}:${resource-server-port} with the TokenRelay filter. It is the MeController which is in charge of processing GET requests to /me on this resource server. It returns some data from the access token taken in the session by the TokenRelay filter (or a payload with empty values if the session on the BFF is anonymous). Of course, as it is possible that the request is not authorized with an access token (in case of anonymous user), this requires that (/api)/me is in the permit-all of both the BFF properties and the resource server properties :

• /api/me is matched against /api/** in client.security-matchers => it is processed by the client fliter-chain on the BFF
• /api/me is matched against /api/** in client.permit-all in the BFF client fitler-chain => anonymous request is allowed (a token is attached by the TokenRelay filter only if the user is authenticated, but the request can be routed without an access token if user is anonymous)
• /me is matched against /me in resourceserver.permit-all on the resource server => an anonymous request routed by the BFF is accepted (the request has an access token only if the user is authenticated on the BFF)

Is it possible I found a bug?

Yes, you have. Thank you.

The cause is that HeaderBearerTokenResolver is defined in spring-security-oauth2-resource-server which is a (permanent) dependency of spring-addons-starter-oidc => spring-security-oauth2-resource-server always is on the classpath when spring-addons-starter-oidc is there.

A fix could be to mark the dependency on spring-security-oauth2-resource-server as <optional>true</optional> in spring-addons-starter-oidc pom. The same should be done for spring-security-oauth2-client and spring-webflux (instead of flagging it as provided).

Would you open a PR for that (and get your name associated to the improvement) or should I push a quick fix?

[rgambelli]

Thanks @ch4mpy for the clarification, I'm already using 7.6.5 release, now it's clear to me how returns 401 when request is not authenticated instead of triggering the redirect, it's all a matter of configuring correctly path matchers in client.security-matcher, permit-all and resourceserver.permit-all, really thanks.

Maybe I'll open a new thread asking help about the logout (I'm using keycloak) and generally about session expiration, I have some doubts but I'm doing more investigations before coming back here.
Bye

[ch4mpy]

@rgambelli a regression about session ending on the authorization server (RP-Initiated Logout in OpenID terms) was spotted a couple of days ago and 7.6.5 is exposed to it. You should give a try to 7.6.7, maybe your current problem will vanish.

[ch4mpy]

@rgambelli I'm glad you got enough info from what I posted, but reading it again, I think it could have been clearer. So I edited both in case someone else lands here some day.