Open pfunzowalter opened 9 months ago
I'm not familiar with that OIDC plugin or what it would mean to interact with the registry here, perhaps ask the folks that maintain it?
Okay, But Interestingly I can use the same tokens to interact with the registry using the Singularity Registry Client and the push and pull in this case works okay.
I'm curious how that works, because it looks like this OIDC provider is a web UI based one (e.g., it redirects to an external site to login) and the interactions you are showing above are from the command line.
Yes, I logged in via the Web interface in the app. just that in this case using OIDC instead of SAML or the other four methods that come with the code. After a successful login using OIDC to the app in the web interface, I need to retrieve the Secrets (eg TOKEN=5027225717bf0030465db1e7099e496022c42181) by clicking the username-->token, which I eventually use when I need to push images to the registry. So to add the token for our registry endpoint I use the command line as shown above. My issue is that it looks like the token I am retrieving, in this case, is invalid when adding it to Singularity Client.
I think those are two different entry points to auth - one is logging you into a web UI via a callback with a code (OIDC) https://www.pingidentity.com/en/resources/identity-fundamentals/authentication-authorization-standards/openid-connect.html and the command line is still hitting the Django auth system, but not going through that handshake.
It isn't clear to me how this plugin alters the auth flow so it's probably out of scope for me to work on it / debug. But if you look into it and find a solution, please feel free to open a PR with docs for how to add this support. Thanks!
Describe the bug Hi, I am currently having trouble adding an endpoint to authenticate and then push containers for our registry. The issue arises due to an access token being invalid. I am using the mozilla-django-oidc as a login plugin to the registry. I have tried to add the token manually to the remote.yaml file as suggested here but it does not work. The bug looks like below.
The Client logs
`singularity --debug remote status DEBUG [U=10368,P=2900230]persistentPreRun() Singularity version: 3.11.3 DEBUG [U=10368,P=2900230]persistentPreRun() Parsing configuration file /usr/local/etc/singularity/singularity.conf DEBUG [U=10368,P=2900230]handleConfDir() /users/walter/.singularity already exists. Not creating. DEBUG [U=10368,P=2900230]handleRemoteConf() Ensuring file permission of 0600 on /users/walter/.singularity/remote.yaml INFO [U=10368,P=2900230]RemoteStatus() Checking status of default remote. SERVICE STATUS VERSION URI Keyserver OK v1.0.0 https://sregistry.idia.ac.za Library OK v1.0.0 https://sregistry.idia.ac.za Token OK v1.0.0 https://sregistry.idia.ac.za
Authentication token is invalid (please login again). FATAL [U=10368,P=2900230]func61() error response from server: Unknown`
Here are the Application logs
sregistry-uwsgi-1 | Unauthorized: /v1/token-status sregistry-uwsgi-1 | [pid: 29|app: 0|req: 8/20] 154.114.10.245 () {34 vars in 486 bytes} [Sun Dec 3 05:39:43 2023] GET /v1/token-status => generated 38 bytes in 493 msecs (HTTP/1.1 401) 8 headers in 273 bytes (1 switches on core 1) sregistry-uwsgi-1 | [pid: 28|app: 0|req: 3/21] 165.73.97.100 () {58 vars in 1151 bytes} [Sun Dec 3 05:40:07 2023] GET / => generated 8739 bytes in 352 msecs (HTTP/1.1 200) 7 headers in 222 bytes (1 switches on core 3)
To Reproduce It is documented here. Expected behavior Documented here.
If applicable, add versions and screenshots to help explain your problem.