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

Allow a user to authenticate in order to use the CLI #3

Open
AllanEngland opened this issue Jul 10, 2024 · 4 comments
Open

Allow a user to authenticate in order to use the CLI #3

AllanEngland opened this issue Jul 10, 2024 · 4 comments
Assignees
Labels
core functionality required by the CLI

Comments

@AllanEngland
Copy link

Ideally pop up a browser window to the same AAI as the GUI.
Successful authentication should return a token to the CLI that can be used for a series of commands.

@AllanEngland AllanEngland added the core functionality required by the CLI label Jul 10, 2024
@AllanEngland
Copy link
Author

I've been looking at this for a while with little success. The most recent things I've tried are;

Interacting with the default OIDC client before it's initiated.
Disabling the default OIDC client and programatically building another one.
Programatically building the api rest service with a bespoke authorisation header.

Some links to documentation
https://quarkus.io/guides/rest-client
https://quarkus.io/guides/security-openid-connect-client-reference#use-oidc-client-directly
https://quarkus.io/guides/security-oidc-code-flow-authentication

@pahjbo
Copy link
Member

pahjbo commented Aug 14, 2024

this shows the basics - we need to used device flow - https://blog.please-open.it/device_code/ - with the cli being a different registered client to the ui

@pahjbo pahjbo assigned pahjbo and AllanEngland and unassigned pahjbo Sep 10, 2024
@pahjbo
Copy link
Member

pahjbo commented Sep 10, 2024

In order to save out the key cloak config after changes you need to follow something like https://redmine.jb.man.ac.uk/issues/6642

@AllanEngland
Copy link
Author

I configured Keycloak with a new client and successfully tested device flow authentication with a few curl commands.

I've added a rudimentary flow to the cli app that kicks off the authentication process, fires up a browser window and polls waiting for authentication to complete. When it's complete the default OIDC Client is used to retrieve an access token. This works initially, however, any subsequent api requests fail. Here's a section of Quarkus debug log;

[io.qua.oid.cli.run.OidcClientImpl] (vert.x-eventloop-thread-5) Default OidcClient has acquired the tokens

[io.qua.oid.cli.rea.fil.run.AbstractOidcClientRequestReactiveFilter] (Quarkus Main Thread) Token acquisition will be delayed until this filter is executed to avoid blocking an IO thread

[io.qua.oid.cli.run.OidcClientImpl] (vert.x-eventloop-thread-5) Default OidcClient has failed to complete the urn:ietf:params:oauth:grant-type:device_code grant request:  status: 400, error message: {"error":"invalid_request","error_description":"Missing parameter: device_code"}

[io.qua.oid.cli.rea.fil.run.AbstractOidcClientRequestReactiveFilter] (vert.x-eventloop-thread-5) Access token is not available, cause: {"error":"invalid_request","error_description":"Missing parameter: device_code"}, aborting the request

[org.jbo.res.rea.com.cor.AbstractResteasyReactiveContext] (vert.x-eventloop-thread-5) Restarting handler chain for exception exception: io.quarkus.oidc.client.OidcClientException: {"error":"invalid_request","error_description":"Missing parameter: device_code"}

Now investigating why the default client goes from having the tokens to immediately trying (and failing) to get them again.

@pahjbo pahjbo self-assigned this Oct 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core functionality required by the CLI
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants