Open vchrisb opened 2 months ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/187454040
The labels on this github issue will be updated when the story is started.
Ok, thank you. I know understand what you want and I have a plan in my mind howto solve it... the Prio is currently so that I want solve PR 2813 and then I can start to create some PRs for this fix. I think I will solve this issue with more than one PR, because the issue now exists in some parts, but finally the client credential flow should work and JWT bearer as well
@peterhaochen47 , FYI
thank you @strehle I did some more testing and had success with jwt bearer grant.
I updated the initial issue with the findings
Ok cool, seems like there's at least a workaround / a hack.
We'll keep the issue open and in mind but likely won't pursue a fix immediately, because being compatible with a non-standard OIDC is not on our current roadmap. Nevertheless, your issue will help others & help us gather data point about the demand for this.
My last comment might have been misleading.
For the jwt bearer token grant that is probably right, but the original ask is to support a trust relation. To use the jwt bearer token grant for this problem, is already a workaround by itself.
AWS, Azure, GCP and Vault do support a trust with amongst others GitHub and Gitlab. From a bit more research, I think they actually use OIDC Token Exchange RFC 8693?
Here is the original github roadmap issue: https://github.com/github/roadmap/issues/376
Hi @vchrisb great stuff! I did not fully get it yet but it seems this requirement matches very much with one of our own: We have Azure Entra as Identity provider and would like to enable API developers to take an Azure Entra Bearer token from there clients and then use this token to execute API calls to a Cloudfoundry instance using UAA (knowing the same identities) on behalf the identy from the Azure token.
Hi @vchrisb , I have been able to use this pattern to create a web app offering SSO with Microsoft Entra which exchanges the Azure id-token to a UAA issued access-token and uses it to call the CF Api with it.
In this scenario it is actually ok to have a uaa client that is used be the server side part of the app to do the token exchange. It is a security gain in any case.
Now in your case I was wondering: Wouldn't it make sense to put a reverse proxy between your github runner and the cf api that actually does the token exchange using a uaa client?
What version of UAA are you running?
76.26.0
77.1.0
How are you deploying the UAA?
I am deploying the UAA
What did you do?
JWT Bearer Token Grant
by adding the Github OIDC Provider:I added the Github OIDC provider using non existing credentials and used the
repository_owner
claim as theuser_name
:The
sub
can't be used for theuser_name
, as it includes unsupported characters like/
and:
. I used therepository_owner
claim for theuser_name
.UAA client required for authentication:
Finally the request to get an
access_token
(uaa
has to be used for requesting theid_token
)The resulting
access_token
:Example Github workflow to retrieve the
id_token
using a custom github action vchrisb/setup-cf:It is possible to get an uaa
access_token
using theJWT Bearer Token Grant
, but this has limitations:sub
, or combination of claims, can't be used for theuser_name
client_secret
is requiredclient_credentials Grant
:I also tried using the
client_credentials Grant
withprivate_key_jwt
to retrieve an UAA access_token by providing a Githubid_token
. For that I created a UAA client, which name matched thesub
claim of theid_token
. I configured the client's jwks_uri with the one of Github. An authentication does fail, because theiss
claim does not include theclient_id
, which is required by the specs for this flow.Conversation on that in UAA Slack.
What did you expect to see? What goal are you trying to achieve with the UAA?
I would like to be able to access the cloud foundry api from a Github workflow using temporary credentials.
Background
From Github Security hardening with OpenID Connect:
Github Actions does provide an
id_token
to workflows with following relevant claims from Understanding the OIDC token:sub
, e.g.repo:octo-org/octo-repo:environment:prod
, the template used to generate thesub
value can be configurediss
is alwayshttps://token.actions.githubusercontent.com
aud
can be configured when requesting theid_token
in the workflowExample Job to retrieve the
id_token
:The Github OIDC provider is solely exposing the JSON web key (JWK) endpoint:
https://token.actions.githubusercontent.com/.well-known/jwks
to be used to validate the Githubid_token
.Github OIDC openid-configuration
The Github documentation does have examples how to create a trust relation with AWS, Azure, GCP and Vault.
(The Github actions OIDC provider is not the same as the Oauth2 provider for Github Oauth2 Apps.)
Ask
I want to use a short live token to interact with the cloud foundry api. For that, I would like to be able to create a trust relation from UAA to Github, (and other CI systems like GitLab) to use the
id_token
provided in the workflow to retrieve an UAA clientaccess_token
. The UAA client might be created using thesub
claim of theid_token
or a pre created client might be pattern matched against thesub
. The client will be used to assign a cloud foundry space role to it.