make an SA an oauthclient#8878
Conversation
|
|
||
| // AdditionalSecrets holds other secrets that may be used to identify the client. This is useful for rotation | ||
| // and for service account token validation | ||
| AdditionalSecrets []string `json:"additionalSecrets,omitempty"` |
There was a problem hiding this comment.
@openshift/api-review AdditionalSecrets allows us to rotate secrets and allows us to accept multiple SA tokens as valid client secrets.
|
Any suggestions for how to write an automated test to check these flows? |
|
@sgallagher this flow works. Tested using an app from @stevekuznetsov |
|
I'm not exactly sure what needs to be done to test, but in terms of the app if it's useful, we should:
Although it would seem like a CLI OAuth client would be better. |
453145f to
76a0883
Compare
|
@soltysh unit tests to confirm the safety of what we return, if not the complete working flow. |
539592e to
66a58ae
Compare
8e40abd to
1b46039
Compare
|
|
||
| // AdditionalSecrets holds other secrets that may be used to identify the client. This is useful for rotation | ||
| // and for service account token validation | ||
| AdditionalSecrets []string |
1b46039 to
25de1a1
Compare
|
LGTM (including tests). Thanks @deads2k !!! |
25de1a1 to
a80d1b1
Compare
|
Oops On Wed, May 18, 2016 at 3:35 PM, OpenShift Bot notifications@github.com
|
Indeed. I think I just thought of a problem I want to solve anyway. SA clients should never get grants automatically given to them. Removing the tag until I get that sorted. |
|
Yeah... On Wed, May 18, 2016 at 4:04 PM, David Eads notifications@github.com
|
|
@stevekuznetsov had a pull open to let the grant method be per client. Probably need that now |
Setting up a switch just for SAs makes this mergeable. Allowing configuration per oauth client later would be good, but being able to say prompt or deny now on SAs is safe. |
a80d1b1 to
28dc558
Compare
|
@soltysh @openshift/api-review take a look at the last commit. It provides a cluster-admin with a switch to control the grant options for SA oauth clients. I think its required for this pull. |
|
[test] |
28dc558 to
f1536e7
Compare
| "redirect_uri": []string{clusterAdminClientConfig.Host}, | ||
| "approve": []string{"true"}, | ||
| }).Encode()) | ||
| authenticatedAuthorizeHTTPRequest3, err := http.NewRequest("POST", clusterAdminClientConfig.Host+"/oauth/approve", postBody) |
There was a problem hiding this comment.
Maybe use the OpenShiftApprovePrefix constant here, instead of hardcoding the /oauth/approve endpoint.
There was a problem hiding this comment.
Maybe use the OpenShiftApprovePrefix constant here, instead of hardcoding the /oauth/approve endpoint.
done
|
The last commit, LGTM, just a small nit 😉 |
f1536e7 to
e99d31e
Compare
|
[merge] |
|
continuous-integration/openshift-jenkins/test Running (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/3927/) |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5949/) (Image: devenv-rhel7_4239) |
|
Evaluated for origin test up to e99d31e |
e99d31e to
026ba1f
Compare
|
Evaluated for origin merge up to 026ba1f |
Still sorting out how to find the correct redirect URIs and figuring out how I can test it, but I'd like feedback on some API changes and the UPSTREAM patch I need to handle tokens.
Only some SA tokens are valid as client secrets, so users have to opt-in and they can still share SA tokens in general for other systems and purposes without exposing themselves to impersonation like this.