[Pulp-dev] Pulp 3: using JWT to request a JWT

Wed Dec 13 17:11:36 UTC 2017

+1

David

On Wed, Dec 13, 2017 at 11:36 AM, Brian Bouterse <bbouters at redhat.com>
wrote:

> +1 to this
>
>
> On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley <dalley at 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 <dkliban at 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 <bbouters at 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 <daviddavis at 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 <bbouters at 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 <jaudet at 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 at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171213/d4134971/attachment.htm>