Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Username Invalid token for Singularity CE endpoint #442

Open
pfunzowalter opened this issue Dec 3, 2023 · 5 comments
Open

Username Invalid token for Singularity CE endpoint #442

pfunzowalter opened this issue Dec 3, 2023 · 5 comments

Comments

@pfunzowalter
Copy link

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.

@vsoch
Copy link
Member

vsoch commented Dec 3, 2023

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?

@pfunzowalter
Copy link
Author

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.

@vsoch
Copy link
Member

vsoch commented Dec 3, 2023

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.

@pfunzowalter
Copy link
Author

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.

@vsoch
Copy link
Member

vsoch commented Dec 3, 2023

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants