I moved the JWT content to the 3.1+ page. With this change Pulp 3.0 MVP will only support Basic auth (the one via the base64 encoded header). If you reload the MVP page you can see the latest.: https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viable_Product
On Wed, Dec 13, 2017 at 12:11 PM, David Davis <davidda...@redhat.com> wrote: > +1 > > > David > > On Wed, Dec 13, 2017 at 11:36 AM, Brian Bouterse <bbout...@redhat.com> > wrote: > >> +1 to this >> >> >> On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley <dal...@redhat.com> wrote: >> >>> - close issues 3163 and 3164 >>>> - move JWT auth use cases from the MVP document[2] to the 3.1+ >>>> document[3]. >>>> - add a story for removing "djangorestframework-jwt" from pulp 3.0 >>> >>> >>> s/story/task, and >>> >>> - remove the JWT auth documentation from the 3.0 docs >>> >>> +1 >>> >>> On Tue, Dec 12, 2017 at 5:01 PM, Dennis Kliban <dkli...@redhat.com> >>> wrote: >>> >>>> tl;dr We should support only basic auth for 3.0 and implement JWT >>>> authentication in 3.1+ >>>> >>>> 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 "djangorestframework-jwt" 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 >>>> >>>> - close issues 3163 and 3164 >>>> - move JWT auth use cases from the MVP document[2] to the 3.1+ >>>> document[3]. >>>> - add a story for removing "djangorestframework-jwt" from pulp 3.0 >>>> >>>> [0] https://pulp.plan.io/issues/3163 >>>> [1] https://pulp.plan.io/issues/3164 >>>> [2] https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl >>>> e_Product/#Authentication >>>> [3] https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP) >>>> >>>> >>>> On Fri, Dec 1, 2017 at 3:48 PM, Brian Bouterse <bbout...@redhat.com> >>>> wrote: >>>> >>>>> +1 to just those use cases. Since we can rollback the change I updated >>>>> the MVP with this change: 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 >>>>> >>>>> 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 ^. >>>>> >>>>> Anyone feel free to suggest other changes or edit and send links with >>>>> the diff. >>>>> >>>>> On Fri, Dec 1, 2017 at 2:47 PM, David Davis <davidda...@redhat.com> >>>>> wrote: >>>>> >>>>>> I would just do: >>>>>> >>>>>> As a JWT authenticated user, I can refresh my JWT token if Pulp is >>>>>> configured with JWT_ALLOW_REFRESH set to True (default is False). >>>>>> >>>>>> Having two user stories means two separate items in redmine, and both >>>>>> of these user stories will probably be fixed in one commit/PR. >>>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse <bbout...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> +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. >>>>>>> >>>>>>> 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: >>>>>>> >>>>>>> As a JWT authenticated user, I can receive a new JWT if Pulp is >>>>>>> configured with JWT_ALLOW_REFRESH=True >>>>>>> As a Pulp administrator, my Pulp system disallows JWT renewal by >>>>>>> default (JWT_ALLOW_REFRESH=False) >>>>>>> >>>>>>> What about these use case changes to the MVP to reflect this convo? >>>>>>> >>>>>>> On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet <jau...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I think @misa's point is that if a valid token becomes compromised, >>>>>>>>> it could be renewed for a long-maybe-forever time. >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>>> Being secure-by-default, with the option to do useful-but-dangerous >>>>>>>> things, is a great design approach. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev