<div dir="ltr">Hi John,<div><br></div><div>Responded inline</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><br></div></div></div></div>
<br><div class="gmail_quote">On Fri, Feb 3, 2017 at 7:36 PM, John Roberts <span dir="ltr"><<a href="mailto:John.Roberts@hsc.utah.edu" target="_blank">John.Roberts@hsc.utah.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Now that we have OAuth running, a number of questions came up:</p>
<ol>
<li>Can we force both web and API authentication to exclusively
use OAuth and disallow the standard user/password login page?
Essentially, we'd be offloading authentication and user
name/password management entirely to the external OAuth server.<br></li></ol></div></blockquote><div>This feature isn't supported at the moment, but it would be straightforward to write a plugin to do this, or enhance the existing OAuth plugin to allow it. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><ol><li>
</li>
<li>Does OAuth work with the Girder API?</li>
<ul>
<li>Would we need to modify girder_client, for example?</li>
<li>What if 2-factor is turned on for the OAuth server?</li></ul></ol></div></blockquote><div>Yes, all interaction with the Girder server actually goes through the same HTTP API, and all authenticated API requests use the same secure token authentication system, regardless of whether the user logged in via OAuth or a password managed by Girder. If multi-factor authentication is required on the provider side during the OAuth workflow, I don't think that should be a problem since I imagine that would be invisible to Girder.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><ol><ul>
</ul>
</ol>
<p>My current read of the girder_client is that it will not handle
OAuth as a means of authentication. I haven't figured out whether
the underlying Girder API has a hook for directly invoking the
Oauth authentication process.</p></div></blockquote><div>Since OAuth is built around interactive user authentication in a web browser, using it in the girder_client is not possible; instead, we recommend using the API keys exposed by Girder to allow OAuth users to make authenticated requests via girder_client. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<p>My colleague envisions users interacting with data on Girder
using API calls from a Jupyter hub client. Perhaps we could
manage the authentication process using apikeys in that case, if
OAuth isn't integrated in the Girder API authentication methods.<br></p></div></blockquote><div>API keys would work in this case. Once you get the authentication token from either a normal password login or via an API key, you can make authenticated API requests in a uniform way.</div><div><br></div><div>I'm curious what you guys are doing regarding Jupyter integration; we actually have some other efforts ongoing at the moment to implement Jupyter + Girder integration, there may be some opportunity to collaborate here. Could you describe what you're doing in that regard?</div><div><br></div><div>Thanks,</div><div><br></div><div>Zach</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p>
</p>
<p>Thanks,<br>
John.<br>
</p>
</div>
<br>______________________________<wbr>_________________<br>
Girder-users mailing list<br>
<a href="mailto:Girder-users@public.kitware.com">Girder-users@public.kitware.<wbr>com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/girder-users" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/girder-users</a><br>
<br></blockquote></div><br></div></div>