API call doesn't work with OIDC auth in harbor

[drehpehs]

If you are reporting a problem, please make sure the following information are provided:

Expected behavior and actual behavior:
I would like to use API call with OIDC user account to retrieve the project data, however, OIDC user account can get "public" projects only. Even I have the project admin role or was set as admin account. It still can get "public" projects.

Steps to reproduce the problem:
Regarding to https://github.com/goharbor/harbor/wiki/Harbor-FAQs#api
$ curl -X GET -u '<USER>:<CLI_secret>' -H "Content-type: application/json" -k -i 'https://<HOST>/api/projects'
Return public projects only
decode(base64) _xsrf=xxxxxx of the Set-Cookie in header.
$ curl -X GET -u '<USER>:<CLI_secret>' -H "Content-type: application/json" -H 'X-Xsrftoken:<_xsrf raw value>' -k -i 'https://<HOST>/api/projects'
Still public projects only

Versions:
Please specify the versions of following systems.

• harbor version: [1.10.0], [1.10.1]
• docker engine version: [18.09.0]
• docker-compose version: [1.24.1]

Additional context:
However, I found it works and can get all authorized projects in the UI. Then I try to use the cookie of the browser, then make the API call.
$ curl -X GET -u '<USER>:<CLI_secret>' -H "Content-type: application/json" -H 'X-Xsrftoken:<_xsrf raw value>' -k -i 'https://<HOST>/api/projects' -H 'Cookie: sid=xxxx; _xsrf=xxxxxx'
Can get all authorized projects for this OIDC user.

• Harbor config files: You can get them by packaging harbor.yml and files in the same directory, including subdirectory.
• Log files:
  /var/log/harbor/core.log
  [ERROR] [/core/filter/security.go:430]: failed to authenticate <USER>: Not supported

[oscarlofwenhamn]

Same issue here. I noticed that using the Admin user, the API works as usual even with OIDC enabled, but for OIDC users they can only access public stuff.

I found it works and can get all authorized projects in the UI

This might be exactly what you mean, but I noticed I can access all the stuff via the API Explorer, which somehow makes it feel even weirder.

[reasonerjt]

It is by design you can't use CLI secret to call the API, that's why it's called "CLI" secret
you need to call API with you ID token

[drehpehs]

It is by design you can't use CLI secret to call the API, that's why it's called "CLI" secret
you need to call API with you ID token

Thanks for your reply.
But excuse me, which token you mean?

It works with Database and LDAP auth mode, I can use the username and password to call the API without any problem. But as for OIDC mode, how can I make API call with the ID token you mentioned?

[oscarlofwenhamn]

#10597 seems related.

[xaleeks]

@drehpehs This cli secret is basically created for you (OIDC user) to interact with Harbor on the command line and is only available for OIDC because that's the design we've taken. By token, he is referring to the ID token that OIDC spec leverages which is where the real authentication takes place. The secret (generated by Harbor for you) just fronts as your key because native docker can't handle redirection.

[drehpehs]

@drehpehs This cli secret is basically created for you (OIDC user) to interact with Harbor on the command line and is only available for OIDC because that's the design we've taken. By token, he is referring to the ID token that OIDC spec leverages which is where the real authentication takes place. The secret (generated by Harbor for you) just fronts as your key because native docker can't handle redirection.

@xaleeks
Thanks for your reply and answer.
But actually even I use the credential for the real authentication you mentioned, it still doesn't work.
$ curl -k -i -u '<USER>:<PASSWORD>' -X GET 'https://<HOST>/api/projects' -H 'Content-type: application/json' -H 'X-Xsrftoken:<_xsrf raw value>'

Unless we bring the cookie in Header.

related: #10563

[reasonerjt]

Basic auth is not supported in OIDC mode you have to call the the api like this
curl -H "Authorization: Bearer $id_token" -X GET ........
The id token is what you get from your IDP, different IDP has different approach to get the id token for a user, please consult your admin for that

[drehpehs]

Basic auth is not supported in OIDC mode you have to call the the api like this
curl -H "Authorization: Bearer $id_token" -X GET ........
The id token is what you get from your IDP, different IDP has different approach to get the id token for a user, please consult your admin for that

@reasonerjt
Thanks for your reply.
Actually I already tried this approach before, and it is the same as swagger UI provided.
If I directly use CLI to query the API. I only can retrieve public project data even the $id_token is correct.
Not pretty sure am I the only one has this issue or not. But I wonder if you try to remove the cookie and send the request (GET /projects) on swagger UI? You still can get all projects including private data?

[danielfbm]

I believe @reasonerjt means that the behavior changes according to the configured login mechanism. For OIDC is better to understand how it works, here is some useful documentation.
Long story short: using OIDC after login you will receive a JWT value called ID Token, this should be used in a Bearer Authorization header to access the API. The same approach is used by other tools that implement OIDC integration, like Kubernetes

[xaleeks]

Hi I'm closing seems there was some misunderstanding on the mechanism in OIDC. Feel free to add more comments if you need more help

[brianmajor]

Just wanted to note that, as drehpehs says, using the Authorization header with the ID Token from the OIDC provider does indeed authenticate the user and grant access to private data through the API.

[brianmajor]

But also, if I'm reading the OIDC/OAuth2 specs correctly, it should be the access_token that grants access to the API, not the id_token.