+1
David On Wed, Dec 13, 2017 at 11:36 AM, Brian Bouterse <[email protected]> wrote: > +1 to this > > > On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
