<div dir="ltr">+1 to this<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley <span dir="ltr"><<a href="mailto:dalley@redhat.com" target="_blank">dalley@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> - close issues 3163 and 3164 <br></div><div> - move JWT auth use cases from the MVP document[2] to the 3.1+ document[3]. <br></div> - add a story for removing "<span class="m_-6076658154598544932m_-5879830825752069860gmail-m_-8559512635347714889gmail-pl-s">djangorestframework-jwt" from pulp 3.0</span></blockquote><div><br></div></span><div>s/story/task, and<br></div><div><br></div><div>- remove the JWT auth documentation from the 3.0 docs</div><div><br></div><div>+1<br></div></div><div class="m_-6076658154598544932HOEnZb"><div class="m_-6076658154598544932h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 12, 2017 at 5:01 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">tl;dr We should support only basic auth for 3.0 and implement JWT authentication in 3.1+<br><div><br>We currently have 2 stories[0-1] related to JWT authentication that we wanted to implement for 3.0. As @bmbouter, @daviddavis, and I tried to groom them earlier today, we decided that we are not ready to commit to using "<span class="m_-6076658154598544932m_-5879830825752069860m_-8559512635347714889gmail-pl-s">djangorestframework-jwt</span>" app for handling JWT authentication. This app has some behaviors that we want to override and also comes with several configuration options that we don't want to support long term. I am proposing that we remove JWT authentication from the MVP and move it to the 3.1+ list. I'd like to <br></div><div><br></div><div> - close issues 3163 and 3164 <br></div><div> - move JWT auth use cases from the MVP document[2] to the 3.1+ document[3]. <br></div><div> - add a story for removing "<span class="m_-6076658154598544932m_-5879830825752069860m_-8559512635347714889gmail-pl-s">djangorestframework-jwt" from pulp 3.0<br></span></div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/3163" target="_blank">https://pulp.plan.io/issues/31<wbr>63</a><br></div><div>[1] <a href="https://pulp.plan.io/issues/3164" target="_blank">https://pulp.plan.io/issues/31<wbr>64</a></div><div>[2] <a href="https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viable_Product/#Authentication" target="_blank">https://pulp.plan.io/projects/<wbr>pulp/wiki/Pulp_3_Minimum_Viabl<wbr>e_Product/#Authentication</a></div><div>[3] <a href="https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)" target="_blank">https://pulp.plan.io/projects/<wbr>pulp/wiki/31+_Ideas_(post_MVP)</a><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-6076658154598544932m_-5879830825752069860h5">On Fri, Dec 1, 2017 at 3:48 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-6076658154598544932m_-5879830825752069860h5"><div dir="ltr"><div><div>+1 to just those use cases. Since we can rollback the change I updated the MVP with this change:  <a href="https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viable_Product/diff?utf8=%E2%9C%93&version=125&version_from=124&commit=View+differences" target="_blank">https://pulp.plan.io/projects/<wbr>pulp/wiki/Pulp_3_Minimum_Viabl<wbr>e_Product/diff?utf8=%E2%9C%93&<wbr>version=125&version_from=124&c<wbr>ommit=View+differences</a><br><br></div>I also added an explicit use case saying that basic auth can authenticate to all urls. I think that got lost in the language revisions. It's also in the diff ^.<br><br></div>Anyone feel free to suggest other changes or edit and send links with the diff.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Dec 1, 2017 at 2:47 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br></span><div><div class="m_-6076658154598544932m_-5879830825752069860m_-8559512635347714889h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I would just do:<div><br></div><div>As a JWT authenticated user, I can refresh my JWT token if Pulp is configured with <span style="font-size:12.800000190734863px">JWT_ALLOW_REFRESH set to True (default is False).</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Having two user stories means two separate items in redmine, and both of these user stories will probably be fixed in one commit/PR.</span></div></div><div class="gmail_extra"><span class="m_-6076658154598544932m_-5879830825752069860m_-8559512635347714889m_-6136323963884408423HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_-6076658154598544932m_-5879830825752069860m_-8559512635347714889m_-6136323963884408423m_-5007439799391258438gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div></font></span><div><div class="m_-6076658154598544932m_-5879830825752069860m_-8559512635347714889m_-6136323963884408423h5">
<br><div class="gmail_quote">On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>+1 to using JWT_ALLOW_REFRESH as the name, I read the other name from some other docs. +1 to adding a refresh token endpoint and some docs.<br><br></div>We need to update this area in the MVP which is currently in red. We could replace the use case in red with:  "As an API user, I can authenticate any API call with a JWT" and then add the following two use cases:<br><br></div>As a JWT authenticated user, I can receive a new JWT if Pulp is configured with JWT_ALLOW_REFRESH=True<br></div>As a Pulp administrator, my Pulp system disallows JWT renewal by default (JWT_ALLOW_REFRESH=False)<br><br></div>What about these use case changes to the MVP to reflect this convo?<br></div><div class="m_-6076658154598544932m_-5879830825752069860m_-8559512635347714889m_-6136323963884408423m_-5007439799391258438HOEnZb"><div class="m_-6076658154598544932m_-5879830825752069860m_-8559512635347714889m_-6136323963884408423m_-5007439799391258438h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think @misa's point is that if a valid token becomes compromised, it could be renewed for a long-maybe-forever time.<br><br>I'm reading a desire to have Pulp exhibit both of these types of behaviors, and both for good reasons. What if we introduce a setting JWT_REFRESH. If enabled, JWT_REFRESH will allow you to receive a new JWT when authenticating with an existing JWT. Defaults to False.<br><br>I'm picking False as the default on the idea that not renewing tokens would be a more secure system by limiting access in more case than when JWT_REFRESH is True. In the implementation, when JWT_REFRESH is set to True it would fully disable the JWT_REFRESH_EXPIRATION_DELTA setting so that it could be refreshed indefinitly. The user would never know about JWT_REFRESH_EXPIRATION_DELTA.</blockquote><div><br></div></span><div>Being secure-by-default, with the option to do useful-but-dangerous things, is a great design approach.<br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div></div></div><br></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>