[
https://issues.apache.org/jira/browse/SOLR-16897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747659#comment-17747659
]
Lamine edited comment on SOLR-16897 at 7/26/23 8:54 PM:
--------------------------------------------------------
Hi [~epugh]
I am not sure how others achieve this, but i suspect they are based on the
local web server approach.
A key issue with using a local web server is that many OAuth/OIDC providers
don't support redirection to localhost, not to mention CORS restrictions
preventing you from calling the service from a localhost. So, I guess most of
the time this solution won’t work.
The main challenge here lies in securely returning the tokens to the CLI after
user authentication.
One (not very elegant) approach is to prompt the user to manually copy and
paste the tokens from the browser into the terminal. I think I have seen this
longtime ago but don't remember what was tool.
A less secure alternative, similar to what you described, is to generate a UID,
pass it to the browser, undergo browser-based authentication through Solr
Admin, and then keep polling the server until a valid response for that UID is
received. However, this presents a security risk as a MITM could potentially
retrieve the tokens if the attacker gains access to the UID. You can still
minimize this by keeping a very short TTL for the tokens and deleting them
after the first success.
Still, you need find a way how/where to store the tokens if you want to
maintain a session and run multiple commands without requiring the user to
authenticate each time. If you use a local tmp file for example, who ever has
access to it would have access to the tokens, hence to Solr...
Actually I was going to post this before I got another idea. To circumvent the
limitations imposed by localhost redirection restrictions, we can use Solr as a
proxy between the OAuth/OIDC server and the local web server. The workflow
would be: OAuth/OIDC server --> Solr Server --> Localhost
If you believe it's worth pursuing, I can spend some time exploring this
approach.
was (Author: JIRAUSER282315):
Hi [~epugh]
I am not sure how others achieve this, but i suspect they are based on the
local web server approach.
A key issue with using a local web server is that many OAuth/OIDC providers
don't support redirection to localhost, not to mention CORS restrictions
preventing you from calling the service from a localhost. So, I guess most of
the time this solution won’t work.
The main challenge here lies in securely returning the tokens to the CLI after
user authentication.
One (not very elegant) approach is to prompt the user to manually copy and
paste the tokens from the browser into the terminal. I think I have seen this
longtime ago but don't remember what was tool.
A less secure alternative, similar to what you described, is to generate a UID,
pass it to the browser, undergo browser-based authentication through Solr
Admin, and then keep polling the server until a valid response for that UID is
received. However, this presents a security risk as a MITM could potentially
retrieve the tokens if the attacker gains access to the UID. You can still
minimize this by keeping a very short TTL for the tokens and deleting them
after the first success.
Still, you need find a way how/where to store the tokens if you want to
maintain a session and run multiple commands without requiring the user to
authenticate each time. If you use a local tmp file for example, who ever has
access it to would have access to the tokens, hence to Solr...
Actually I was going to post this before I got another idea. To circumvent the
limitations imposed by localhost redirection restrictions, we can use Solr as a
proxy between the OAuth/OIDC server and the local web server. The workflow
would be: OAuth/OIDC server --> Solr Server --> Localhost
If you believe it's worth pursuing, I can spend some time exploring this
approach.
> add support of OAuth 2.0/OIDC 'code with PKCE' flow (back-end)
> --------------------------------------------------------------
>
> Key: SOLR-16897
> URL: https://issues.apache.org/jira/browse/SOLR-16897
> Project: Solr
> Issue Type: Improvement
> Reporter: Lamine
> Priority: Minor
>
> This is the "back-end" part of '[code with
> PKCE|https://issues.apache.org/jira/browse/SOLR-16896]' contribution.
> The back-end code is mainly for configuration. This is where the different
> options are configured.
> This PR adds _tokenEndpoint_ and _authorizationFlow_ options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
