BFF and the spring add-on config

[naruraghavan]

Here is my spring addon config:

BFF:

spring:
  security:
    oauth2:
      client:
        registration:
          gas:
            client-id: ${CLIENT_ID_INT}
            client-secret: ${CLIENT_SECRET_INT}
            provider: gas
            authorization-grant-type: authorization_code
            scope:
              - openid
              - profile
              - email
              - phone
              - job_title
              - scoped_entitlement
              - authorization_group
              - entitlement_group
              - organizational_data
              - supervisor
              - group_type
        provider:
          gas:
            issuer-uri: ${ISSUER_URI_INT}
            authorization-uri: ${ISSUER_URI_INT}/as/authorization.oauth2
com:
  c4-soft:
    springaddons:
      oidc:
        ops:
          - iss: ${ISSUER_URI_INT}
            authorities:
              - path: authorities
                prefix: "ROLE_"
            aud: ${audience}
        # SecurityFilterChain with oauth2Login() (sessions and CSRF protection enabled)
        client:
          client-uri: ${client_uri}
          security-matchers:
            - /api/**
            - /login/**
            - /oauth2/**
            - /logout
            - /whoami
          permit-all:
            - /api/**
            - /login/**
            - /oauth2/**
          csrf: cookie-accessible-from-js
          post-logout-redirect-host: ${reverse_proxy_uri}
          oauth2-redirections:
            rp-initiated-logout: ACCEPTED
          back-channel-logout:
            enabled: true
        # 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

Resource Server:

com:
  c4-soft:
    springaddons:
      oidc:
        ops:
          - iss: ${ISSUER_URI_INT}
            username-claim: sub
          - authorities:
              - path: authorities
                prefix: "ROLE_"
            aud: aud
        resourceserver:
          permit-all:
            - /token
            - /me
            - /v3/api-docs/**
            - /swagger-ui/**
            - /actuator/health/readiness
            - /actuator/health/liveness

1. How do I know to specify the JSON path? The spring OAuth module initiates the auth flow and gives me an OidcUser object mapping of the attributes I receive from my auth server.
2. The TokenRelay= generates an invalid Bearer token. No dots in the token resulting in JWS-SET cannot be retrieved error message at the resource server.
3. I tried creating a bearer token myself with all the attributes needed, but it resulted in an invalid signature at the resource server.
4. I tried different permutations to arrive at:

• authorities:
  • path: authorities
    prefix: "ROLE_"

but this does not work because I do not know where to go next.

All in all, I am stuck. Please advise.

[ch4mpy]

The TokenRelay= generates an invalid Bearer token

This token is most probably a valid opaque token (not a JWT). Check your authorization server documentation about what kind of token it issues and under which condition.

If the g in gas stands for Google, it is most likely that the tokens you get are intended to be used only with Google APIs, and cannot be used efficiently to authorize requests to your resource servers. In that case, you'll have to set up an authorization server of your own, federating Google identities. Keycloak does this pretty well. This is a scenario where Spring Authorization Server is relatively easy to configure too. You might also find cloud offers like Auth0 which can do that.

How do I know to specify the JSON path?

• use an online evaluator like this one. Most have links to some documentation about syntax
• when configuring a resource server, get the JSON payload by decoding an access JWT (use a tool like postman to get a token and then https://jwt.io to decode it)
• when configuring an OAuth2 client with oauth2Login (like a BFF), get the payload from
  • an ID token if the authorization server complies with OpenID and you have set the issuer-uri for the provider
  • the body of the response to the userinfo endpoint otherwise

[naruraghavan]

Thanks for the quick response. I did not expect that. Impressed!

"gas" stands for global authentication service from my company using Ping Identity IDP. For some reason, the userinfo endpoint always returns null. I do see IDToken and all the other attributes in the payload. I'll do some digging with the info you gave me. I will come back if anything. Thanks a bunch. If this works, your work will simplify several boilerplate filters and handlers to just a few lines of yml entries.

[ch4mpy]

According to Ping Identity docs, they issue JWTs. You can find here and there (Google searches about Ping Federate) references to access token (opaque) references and JWTs. Apparently, getting one or the other is a matter of client configuration on the authorization server.

According to the same doc, they don't ask for an aud (audience) parameter for authorization request. So you can remove that from your yaml. You can remove the authorization-uri too: it listed in the OpenID configuration (check in the payload of ${ISSUER_URI_INT}/.well-known/openid-configuration which should be publicly accessible).

Double check that your ${ISSUER_URI_INT} is looking something like

• if using their cloud offers, https://auth.pingone.com/5caa81af-ec05-41ff-a709-c7378007a99c/as
• otherwise, whatever is listed in the OpenID configuration as issuer (OpenID configuration is exposed as ${issuer}/.well-known/openid-configuration, so search a bit around if it doesn't work immediately with what you have configured as ${ISSUER_URI_INT} so far)

Enable DEBUG logs and share your BFF logs after a login attempt.

logging:
  level:
    org:
      springframework:
        security: DEBUG

Also, once you are sure about the conf, get access and ID tokens using Postman and post the decoded payloads (as I don't want to access your resource servers, I don't need the signed encoded strings, I just need the JSON payloads to see structure and the issuer value it contain)

I don't see the gateway conf, can you add it?

Last this /token endpoint on the resource server looks very suspicious: it is a key point of the BFF pattern to hide tokens from the "outside".

[naruraghavan]

Access token: 0001iRy2klwuLmVdUPjTGdIQz5uw
Id token decoded (I have redacted the values, but the ISS value matches ISSUER_URI_INT)

{
  "sub": "...",
  "aud": "...",
  "jti": "uUlU937Qltwzr4S4tyvy7C",
  "iss": "...",
  "iat": 1719102363,
  "exp": 1719103263,
  "auth_time": 1719101358,
  "acr": "gas:strong",
  "country": "US",
  "global_cost_center_source": "...",
  "company_identifier": "...",
  "group_type": "0",
  "business_field": "...",
  "basic_start_authorization": "true",
  "updated_at": 20240622,
  "department_description": "...",
  "department": "...",
  "working_company_id": "...",
  "email": "...",
  "postal_address": "...",
  "business_category": "..",
  "global_cost_center": "...",
  "email_verified": true,
  "phone_number_verified": false,
  "given_name": "...",
  "cost_center": "...",
  "name": "....",
  "phone_number": "...",
  "family_name": "....",
  "supervisor": "..",
  "position_id": "...",
  "pi.sri": "VB4Ej2cJ3w2MMOA6UGWwidGyGYA.ZW0y",
  "sid": "VB4Ej2cJ3w2MMOA6UGWwidGyGYA.ZW0y"
}

[naruraghavan]

I added the /token endpoint to a thymeleaf page to see what happened. Since there is a problem with token validation at the resource server, I always get 401—an invalid bearer token. I will remove this route and the page after testing.

[naruraghavan]

here is the GW config:

  cloud:
    gateway:
      routes:
        - id: bff
          uri: ${resource_server_uri}
          predicates:
            - Path=/api/**
          filters:
            - DedupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin
            - TokenRelay=
            - SaveSession
            - StripPrefix=1
 

[naruraghavan]

Lastly, here is the redacted wellknown openid config:

{
    "issuer": "...",
    "authorization_endpoint": ".../as/authorization.oauth2",
    "token_endpoint": ".../as/token.oauth2",
    "introspection_endpoint": ".../as/introspect.oauth2",
    "userinfo_endpoint": ".../idp/userinfo.openid",
    "scopes_supported": [
        "openid"
    ],
    "end_session_endpoint": ".../idp/startSLO.ping",
    "ping_end_session_endpoint": ".../idp/startSLO.ping",
    "revocation_endpoint": ".../as/revoke_token.oauth2",
    "jwks_uri": ".../pf/JWKS",
    "response_types_supported": [
        "code"
    ],
    "grant_types_supported": [
        "refresh_token",
        "authorization_code"
    ],
    "acr_values_supported": [
        "gas:standard",
        "gas:strong"
    ],
    "subject_types_supported": [
        "public"
    ],
    "id_token_signing_alg_values_supported": [
      "RS256"
    ],
    "frontchannel_logout_supported": true,
    "code_challenge_methods_supported": [
        "S256"
    ],
    "token_endpoint_auth_methods_supported": [
        "client_secret_basic",
        "client_secret_post"
    ],
    "ping_revoked_sris_endpoint": ".../pf-ws/rest/sessionMgmt/revokedSris"
}

[naruraghavan]

With my current setup, the BFF is functional and sends a BEARER token to the resource server, with www-authenticate with the access token. I get a 401 unauthorized for /bff/api/me with a Bearer error="invalid_token", error_description="Could not retrieve JWT claim-set", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1" . I try adding the spring.security.oauth2.resourceserver.jwt.jwk-set-uri: ${ISSUER_URI_INT}/pf/JWKS, without any luck.

While debugging, I see the error here:

    @Override
    public Mono<Authentication> authenticate(Authentication authentication) throws AuthenticationException {
        Assert.isTrue(authentication instanceof BearerTokenAuthenticationToken, "Authentication must be of type BearerTokenAuthenticationToken");
        JWTClaimsSet jwtClaimSet;
        try {
            jwtClaimSet = JWTParser.parse(((BearerTokenAuthenticationToken) authentication).getToken()).getJWTClaimsSet();
        } catch (ParseException e) {
            throw new InvalidBearerTokenException("Could not retrieve JWT claim-set");
        }
        return this.jwtAuthenticationManagerResolver.resolve(jwtClaimSet).flatMap(authenticationManager -> {
            if (authenticationManager == null) {
                throw new InvalidBearerTokenException("Could not resolve the Authentication manager for the provided JWT");
            }
            return authenticationManager.authenticate(authentication);
        });
    }

with the InvalidBearerTokenException java.text.ParseException: Invalid JWT serialization: Missing dot delimiter(s). When I inspect the authentication object, I see the following:

BearerTokenAuthenticationToken [Principal=0001IDloRM82b9Zo2kiOxr4L3mGb, Credentials=[PROTECTED], Authenticated=false, Details=null, Granted Authorities=[]]

[naruraghavan]

With Postman, I was able to get values from the /userinfo endpoint:

{
    "sub": "...",
    "email_verified": true,
    "authorization_group": [
        "APPXXXXX.Start_Authorization"
    ],
    "phone_number_verified": false,
    "given_name": "...",
    "basic_start_authorization": "true",
    "personal_data_hint": "...",
    "updated_at": 20240622,
    "name": "...",
    "entitlement_group": [
        "APPXXXXX.UI",
        "APPXXXXX.API"
    ],
    "phone_number": "...",
    "app_id": "APPXXXXX",
    "family_name": "...",
    "email": "..."
}

If the user has the Start_Authorization for a given app (APPXXXX), he can proceed. The entitlement group further clarifies what finer-grained control the user has to have to access other app functionalities. This is where I get stuck when I integrate your framework for the authorities config. What should it map to?

[ch4mpy]

That's some decently detailed info. Thank you.

0001iRy2klwuLmVdUPjTGdIQz5uw is an opaque token, not a JWT. No chance that a JWT decoder can read it. That's why you get a 401 on the resource server. You can read the claims associated with it by submitting it to the introspection_endpoint listed in your OpenID configuration (I know that you are not using Auth0, but token introspection is an OAuth2 standard and their doc should apply to you too).

Can you please post here the payload you get when introspecting an access token and specify which claim(s) you want to be mapped as Spring Security authorities (with which prefix for each)?

May I ask how you got this token? Breakpoint in the BFF and reading the Authentication from the SecurityContextHolder? Postman? other? If you have used something else than a breakpoint in the BFF, can you please double-check that you used exactly:

• the client ID, client secret, and scope configured for the BFF
• authorization and token endpoints listed in the OpenID configuration

spring-addons can be configured to use opaque token introspection instead of JWT decoding, but I strongly advise that you don't do that because of the impact on performance. Instead, please contact the Ping Identity support to ask them why you get opaque access tokens and how to get JWTs instead. They might be interested the company ID contained in your issuer URI (I don't need it, but they will probably), as well as the client ID and scope you use.

[naruraghavan]

I need a special client role to do token introspection. I am in the process of requesting for one. This is why the introspection call for the access token is failing even in Postman, with the following:

{
    "error_description": "This endpoint requires client authentication"
    "error": "invalid_client"
}

That said, I set breakpoints in BFF and the resource server code to see how things work. I used Postman to see what comes back from the userinfo endpoint since userinfo is always null on the spring side (within the code).

Per documentation, the response from the token introspection will not contain any authority info. As I mentioned perviously, the UserInfo Endpoint gives me that info.

{
    "sub": "...",
    "email_verified": true,
    **"authorization_group": [
        "APPXXXXX.Start_Authorization"
    ],**
    "phone_number_verified": false,
    "given_name": "...",
    "basic_start_authorization": "true",
    "personal_data_hint": "...",
    "updated_at": 20240622,
    "name": "...",
    **"entitlement_group": [
        "APPXXXXX.UI",
        "APPXXXXX.API"
    ],**
    "phone_number": "...",
    "app_id": "APPXXXXX",
    "family_name": "...",
    "email": "..."
}

The authorization_group and entitlement_group provides that info. A user can have access to the application (APPXXXXX) only if he has the authorization_group with the "APPXXXXX.Start_Authorization" entry. Additional fine-grained access control is in the entitlement_group. Somehow, from an "Authority" perspective, it has to be mapped to the entitlement_group from the/UserInfoEndpoint.

[ch4mpy]

User info endpoint is used by Spring when the OAuth2 authorization server doesn't comply with OIDC (when it does not expose OpenID configuration at .well-known/openid-configuration and you provide with all endpoints in yaml).

I the case of OpenID, Spring OAuth2 clients with oauth2Login use the ID token instead of the userinfo endpoint. This is more efficient because it saves a request to the authorization server (ID token is included in the token response already).

Anyway, you don't need the authorities on the BFF, you need it on the resource server when evaluating access control rules. So ID token claims and userinfo response structure are not important for access co'trol.

As exposed earlier, token introspection is something to avoid: it causes a loop from the resource server(s) to the authorization server for each and every request (increases latency of each REST call and load on the authorization server).

So the structure of the introspection endpoint response is, by far, less important than having the authorization server configured to issue access JWTs (instead of opaque) to your OAuth2 client (the one configured in the BFF yaml), and to have the entitlement_group included in access token claims. I have no expertise with Ping Identy authorization server configuration and can't help you with that. As their doc states that it should issue JWTs, please contact the support to update the conf of the client on your authorization server.

[naruraghavan]

Thanks. Unfortunately, I cannot request a global change like that. Given the constraint, what is my best course of action?

1. Force Spring to read from the Userinfo endpoint - how do I force Spring to get all the authorities from the userinfo endpoint and map it to authorities? I came across the Spring doc to configure it for doing the authorities mapper, but unfortunately, as you said, the user info endpoint is never called. I only see attributes from the decoded "idToken". How do I force it? Is it even possible?
2. Write a class to submit a GET against the userinfo endpoint and merge the attributes with the OidcUser

what do you recommend?

[ch4mpy]

Please read my preceding comment with attention: reading userinfo on the BFF would have absolutely no influence on the authorities the resource server gets from the access token.

What have you asked exactly to Ping Identity support and what is their exact answer?

[naruraghavan]

Per support, they want me to read from the user info endpoint in BFF and send a bearer token down to the resource server with all the necessary authorities.

I am considering having an OidcTokenRelay to set a header with the manufactured JWT token with all the entitlement_group values and send it to the resource server. How would the resource server validate the JWT token I manufacture and send?

[ch4mpy]

they want me to read from the user info endpoint in BFF and send a bearer token down to the resource server with all the necessary authorities

You might have misinterpreted the support answer as this would violate OAuth2 actors responsibilities. From the editor of an authorization server, that would be very surprising. Tokens, all of it (including the access token relayed by the BFF) are manufactured and signed by the authorization server (certainly not by a client). This is the reason why I asked the exact question and answer you exchanged.

The resource server can trust only tokens signed by the authorization server (or validated by it on the introspection endpoint). This will never work with a token crafted on the client.

If you can't get the support help you configure Ping Identity authorization server to issue access JWTs with the claims you need, you should probably consider, as already mentioned earlier for Google, using an authorization server of your own in front of Ping Identity (use it as identity provider). Keycloak, Spring Authorization Server, and many cloud offers like Auth0 can do that, issuing JWTs and letting you manage user roles as you need. But I'm convinced that Ping Identity can't help you get access JWTs with the claims you need. Otherwise, their solution would be little to not attractive at all.

[naruraghavan]

One additional observation:

When I have "basic_start_authorization" as the only scope in my BFF, the userinfo is invoked. It fails with a 403 forbidden response from the IDP. When I invoke the userinfo endpoint in Postman, the same request goes through, and I get the JSON payload back. If I do a CURL with the authorization header, the access_token obtained by Postman always works, whereas the access_token obtained by Spring (within the UserRequest object) always fails with a 403. Somehow, the access_token is wrong in Spring. Any ideas? e.g. Postman --> Bearer 00010JYtWf7hM6nWHmoXT5m7dVMK; Spring: Bearer 0001TiHZdBxmxq3tFjGGpEzNbudq

[naruraghavan]

One last attempt in using spring-addons:

1. My BFF has spring add-on properties in application.yml and is helping with some of the instrumentation
2. My resource server is validating the opaque token from my IDP and is successful
3. With the opaque token being my constraint for access token type, how can I have spring add-on play a role in other aspects without JWT claim sets validation etc.?

Should I abandon the idea of using spring add-on and continue my journey? Please advise.

[ch4mpy]

If you don't want to follow guidance, don't ask for it, it will save everybody's time.

About access token introspection

With the opaque token being my constraint for access token type

This is a constraint you choose (for probably no other reason than a tunnel effect):

• opake token introspection is inefficient
• there are too many references in Ping Federate documentations, Q&A, forums, etc. to switch from "token reference" (what they call their opaque token format) to JWT access tokens for this to be impossible
• even in the case where opting out "token reference" was not possible easily, you could put a decent authorization server in front of Ping Federate to issue JWTs (I wrote twice about that in this thread already)

As a side note, spring-addons is compatible with access token introspection. One of the tutorials is even dedicated to this subject. So, my position on this is motivated only by the fact that introspection only has drawbacks, and no advantage, compared to JWT decoding (not because spring-addons can't be used in that case: it can).

About spring-addons features

how can I have spring add-on play a role in other aspects without JWT claim sets validation etc.?

spring-addons is not just about JWT claim sets validation. It is about easing OAuth2 clients and resource servers security configuration in an OIDC environment. You can use it to configure just the client (BFF), just the resource server (REST API with JWT decoding or token introspection), or both. The complete feature list is in the spring-addons-starter-oidc README.