Feature request: Configuration option whether to accept or reject broker clone tokens

thomas-br commented 4 years ago

Current State

In the current state of the XsuaaJwtDecoder and the XsuaaAudienceValidator, access tokens issued from binding information of clones of xsuaa instances with the broker-plan (here called as broker clone tokens or clone tokens) are accepted by default. With the broker plan clones can be created from a master xsuaa instance, that are bound to a specific org / tenant and enable tenant specific technical authentication. As an example the binding information / credentials could be given to the respective tenants to enable API access instead of a pure browser flow access based on the IDP configuration.

Gap Scenario

The current state implies that these clone tokens are automatically accepted as fully trusted and authenticated tokens which holds true from pure broker scenarios. In other application setup scenarios a mixed form is also valid, that API access exists besides browser scenarios. But those two scenarios do have a different trust levels, as the entry-point for browser access and user tokens is always the approuter. Having existing clone binding credentials provided to tenants moves the token control to the outside.

In specific setups it is required to reject clone-tokens per service, which might not be intended to be called directly but rather only with tokens coming from the "xsuaa master instance / binding".

Requested Feature

Offer a configuration parameter, for example through the XsuaaJwtDecoderBuilder to decide whether these clone-tokens should be accepted (default case) or rejected instead on a service level.

nenaraab commented 4 years ago

Hi @torsten-sap can you please evaluate this use case... and if this is valid... how shall we call the feature?

nenaraab commented 4 years ago

Hi @thomas-br

I've discussed internally and another idea came up to reflect the different trust levels:

the master could set "authorities-inheritance": false in order to not inherit the master scopes to the clones.

In that case, the AudienceValidation will not fail, but the scope check would fail. Would that be feasible?

thomas-br commented 4 years ago

Hi @nenaraab,

This would not work for us I think. We actually need the inheritance of scopes but just need to avoid that clone tokens can be used for accessing a service generally.

nenaraab commented 4 years ago

Hi @thomas-br we did some progress here:

please have a look at this PR: https://github.com/SAP/cloud-security-xsuaa-integration/pull/369

You can test the PR also with your current client lib version. To do so pls just replace the "isClone()" method with this code snippet:

private boolean isClone(Jwt token) {
            if(token instanceof Token) {
                // workarount till 2.7.8
                // return ((Token) token).isClone(configuration.getAppId());
                return configuration.getAppId().contains("!b") && ((Token)token).getClientId().endsWith("|" + configuration.getAppId());
            }
            return false;
        }

nenaraab commented 4 years ago

@thomas-br could you evaluate our proposal in the meanwhile? So that we finalize it and ship it as part of the next version...

nenaraab commented 4 years ago

Unfortunately, it makes no sense to enhance the Token object, as spring provides a Jwt object to the XsuaaAudienceValidator.

private boolean isClone(Jwt token) {
            return configuration.getAppId().contains("!b") 
                    && token.containsClaim(TokenClaims.CLAIM_CLIENT_ID) 
                    && token.getClaimAsString(TokenClaims.CLAIM_CLIENT_ID).endsWith("|" + configuration.getAppId());
        }

nenaraab commented 4 years ago

Hi @thomas-br,

The ticket is in status "Author Action" without any activity for 30 days or longer. Thus, closing the ticket. Please reopen if the issue is still relevant or the solution provided can not be applied.

Best regards, Nena

SAP / cloud-security-services-integration-library