Missing external Scopes when assertion is used in /oauth/token request

[gryffindor-001]

SECURITY NOTICE: If you have found a security problem in the UAA, please do not file a public github issue. Instead, please send an email to [email protected]

Thanks for taking the time to file an issue. You'll minimize back and forth and help us help you more effectively by answering all of the following questions as specifically and completely as you can.

What version of UAA are you running?

76.31.0

What output do you see from curl <YOUR_UAA>/info -H'Accept: application/json'?

{
    "app": {
        "version": "76.31.0"
    },
    "showSelfServiceLinks": false,
    "links": {
        "uaa": "https://xxxx/uaa",
        "passwd": "/forgot_password",
        "login": "https://xxxx/uaa",
        "register": "/create_account"
    },
    "zone_name": "uaa",
    "entityID": "https://xxxx/uaa/saml/metadata",
    "commit_id": "------",
    "idpDefinitions": {},
    "prompts": {
        "username": [
            "text",
            "User Identifier"
        ],
        "password": [
            "password",
            "Password"
        ]
    },
    "timestamp": "2024-11-29T02:03:14+0530"
}

How are you deploying the UAA?

I am deploying the UAA

• locally only using gradlew

What did you do?

Requested a token for an ldap user using https://{{hostname}}:{{uaa_port}}/uaa/oauth/token and the following parameters as body

client_id:client_id
client_secret:secret
grant_type:password
token_format:jwt
username:[email protected]
password:password
response_type:token

Then using the access_token obtained from above, requested another token using https://{{hostname}}:{{uaa_port}}/uaa/oauth/token with:

client_id:client_id
client_secret:secret
token_format:jwt
grant_type:urn:ietf:params:oauth:grant-type:jwt-bearer
assertion:{{user_token}}
response_type:token id_token

What did you expect to see? What goal are you trying to achieve with the UAA?

Expected to see a new token with all the scopes for the user.

What did you see instead?

For LDAP user the token obtained from the assertion (second api request) call is missing external scopes. The token only contains default scopes. For a UAA user the flow worked perfectly and the second token had all the scopes (default and any additional scopes given) but for a LDAP/domain user external scopes were missing.

Scopes granted when first token is requested

Scopes granted when assertion=user_token was used

Here, scada.test1.abc is not a default scope which is missing when assertion=user_token in passed in body instead of username, password of the user.

Please include UAA logs if available.
uaa.log

[strehle]

HI,
I need more information about your client configurations.
If you dont want share your client configuration here , then contact me in slack or uaa channel.

your tokens should contain an origin claim. That is the next information I would ask for...

The scopes (groups assignments UAA internally) are linked to the origin (IDP) or if UAA then UAA internal groups, but that can be the reason why you loose some assignments during the token exchange

[gryffindor-001]

Hi, Thanks for the update. Can we have a private slack channel for further discussion? There might be some information which can be sensitive for our product. I have joined the cloudfoundry slack (Daivesh Pandya). Let me know what all information you need from me regarding the client and I will be able to do it there. Thanks and Regards Daivesh

…

On Tue, 14 Jan 2025 at 21:44, Markus Strehle ***@***.***> wrote: HI, I need more information about your client configurations. If you dont want share your client configuration here , then contact me in slack or uaa channel. your tokens should contain an origin claim. That is the next information I would ask for... The scopes (groups assignments UAA internally) are linked to the origin (IDP) or if UAA then UAA internal groups, but that can be the reason why you loose some assignments during the token exchange — Reply to this email directly, view it on GitHub <#3213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANVMBDEGZYYVCMI7OV3F4RD2KUZXHAVCNFSM6AAAAABUPYV5MOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJQGM4TSMRZGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[strehle]

Hi,
I answered you via slack.
I dont see any issue during token exchange. My first token was auth-code from an OIDC idp and the 2nd one was created via jwt-bearer. Both tokens has the expected scope, because the user is assigned to the groups in both calls. And

uaac group get myGroup.test.write

shows origin of my IDP.

There should not be other logic in LDAP than in SAML or OIDC.

[strehle]

FYI

I setup and tested with ldap group and added scope/authority to client, e.g. thirdmarissa

1. password grant with a ldap user and requesting a scope .e.g. thirdmarissa
2. do jwt bearer with and without special scope request

=> receive always thirdmarissa

used ldap setup from desc: #3255