[Pulp-dev] Pulp 3: using JWT to request a JWT
Our MVP doc currently states "As an API user, I can authenticate any API call (except to request a JWT) with a JWT. (not certain if this should be the behavior) [in progress]" The uncertainty was due to the "except to request a JWT" clause. I propose that Pulp 3 should support requesting a new JWT by using an existing JWT. Automated systems that integrate with Pulp would benefit from being able to renew tokens using an existing token. Enabling this feature with django-rest-framework-jwt requires also selecting the maximum amount of time since original token was issued that the token can be refreshed. The default is 7 days. Pulp users should be able to supply this value. Thy should also be able to specify how long each token is good for. What do others think? ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
I’m not sure I fully understand this last paragraph about setting a maximum amount of time per token. Regardless, I would not add the ability to request new JWT tokens using JWT authentication in the MVP unless it’s easy to implement. I think we want that eventually but what we have today supports most of what users want or need from JWT auth. David On Tue, Nov 28, 2017 at 5:34 PM, Dennis Kliban wrote: > Our MVP doc currently states "As an API user, I can authenticate any API > call (except to request a JWT) with a JWT. (not certain if this should be > the behavior) [in progress]" > > The uncertainty was due to the "except to request a JWT" clause. > > I propose that Pulp 3 should support requesting a new JWT by using an > existing JWT. Automated systems that integrate with Pulp would benefit from > being able to renew tokens using an existing token. > > Enabling this feature with django-rest-framework-jwt requires also > selecting the maximum amount of time since original token was issued that > the token can be refreshed. The default is 7 days. Pulp users should be > able to supply this value. Thy should also be able to specify how long each > token is good for. > > > What do others think? > > ___ > 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
On Tue, Nov 28, 2017 at 8:32 PM, David Davis wrote: > I’m not sure I fully understand this last paragraph about setting a > maximum amount of time per token. Regardless, I would not add the ability > to request new JWT tokens using JWT authentication in the MVP unless it’s > easy to implement. I think we want that eventually but what we have today > supports most of what users want or need from JWT auth. > The change I am proposing is just a configuration change in settings.py. We need to set JWT_ALLOW_REFRESH to True and determine what we want the default value for JWT_REFRESH_EXPIRATION_DELTA to be. The first will enable the feature, the second will determine the length of time that can pass from the creation of the very first token (using name and password) until the user has to use the username and password again. In the time in between, the user can use the JWT to get a new JWT. More docs on this are here[0]. [0] https://getblimp.github.io/django-rest-framework-jwt/ > > David > > On Tue, Nov 28, 2017 at 5:34 PM, Dennis Kliban wrote: > >> Our MVP doc currently states "As an API user, I can authenticate any API >> call (except to request a JWT) with a JWT. (not certain if this should be >> the behavior) [in progress]" >> >> The uncertainty was due to the "except to request a JWT" clause. >> >> I propose that Pulp 3 should support requesting a new JWT by using an >> existing JWT. Automated systems that integrate with Pulp would benefit from >> being able to renew tokens using an existing token. >> >> Enabling this feature with django-rest-framework-jwt requires also >> selecting the maximum amount of time since original token was issued that >> the token can be refreshed. The default is 7 days. Pulp users should be >> able to supply this value. Thy should also be able to specify how long each >> token is good for. >> >> >> What do others think? >> >> ___ >> 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
+1 On 11/28/2017 04:34 PM, Dennis Kliban wrote: > Our MVP doc currently states "As an API user, I can authenticate any API call > (except to request a JWT) with a > JWT. (not certain if this should be the behavior) [in progress]" > > The uncertainty was due to the "except to request a JWT" clause. > > I propose that Pulp 3 should support requesting a new JWT by using an > existing JWT. Automated systems that > integrate with Pulp would benefit from being able to renew tokens using an > existing token. > > Enabling this feature with django-rest-framework-jwt requires also selecting > the maximum amount of time since > original token was issued that the token can be refreshed. The default is 7 > days. Pulp users should be able to > supply this value. Thy should also be able to specify how long each token is > good for. > > > What do others think? > > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > signature.asc Description: OpenPGP digital signature ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
+1. I think one should be able to get a JWT with a JWT. This user experience: > I can authenticate any API call with a JWT token. ...is nicer than this user experience: > I can authenticate any API call with a JWT token. Oh, wait, exept getting a new JWT token. I wonder why? Is there some security risk here? I wonder if there's other API calls that also don't let me use JWT tokens? Perhaps I should use basic auth for all authentication? ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
Jeremy, I don't think I understand your comment. You *will* have to use basic auth to refresh the token when the original one expires. So there are limitations to a JWT, and for good reasons. A JWT is a weaker authenticator than a username+password because it expires. Because it is timestamped, it reduces the risk of compromising your account if someone sniffs the traffic. Refreshing the token with a JWT seems marginally useful to me. On Wed, Nov 29, 2017 at 1:02 PM, Jeremy Audet wrote: > +1. I think one should be able to get a JWT with a JWT. This user > experience: > > > I can authenticate any API call with a JWT token. > > ...is nicer than this user experience: > > > I can authenticate any API call with a JWT token. Oh, wait, exept > getting a new JWT token. I wonder why? Is there some security risk here? I > wonder if there's other API calls that also don't let me use JWT tokens? > Perhaps I should use basic auth for all authentication? > > ___ > 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
> > Jeremy, I don't think I understand your comment. > > You *will* have to use basic auth to refresh the token when the original > one expires. > Right. I understand that. I'm not arguing that we allow the user to generate a valid JWT token using an expired, invalid JWT token. I'm arguing that we allow the user to generate a valid JWT token using an unexpired, valid JWT token. This allows use cases such as a client (web browser, CLI tool, etc) being able to re-authenticate itself without re-prompting the user for a username and password. This is especially relevant if the token expiration time is set to a short value, such as 15 minutes. So there are limitations to a JWT, and for good reasons. A JWT is a weaker > authenticator than a username+password because it expires. Because it is > timestamped, it reduces the risk of compromising your account if someone > sniffs the traffic. > If there's security concerns here, then that's important, and they should be weighted heavily. Note that there's an easy-to-use mechanism for invalidating a user's tokens. > Refreshing the token with a JWT seems marginally useful to me. > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
I like the ability to refresh tokens. I imagined it would be allowed forever with no limit (effectively disable JWT_REFRESH_EXPIRATION_DELTA). If an admin wants to lock out the user they easily can regardless of renewal. No one suggested this, but I believe we should not expose either of these options in the Pulp settings at least for now. If we expose this JWT plugin's feature set to Pulp users, then Pulp will have to carry that feature set if we ever switch plugins. Allowing renewal does have an undesirable quality in that you can't issue a JWT and trust the user has a limited, known amount time on the system. The other option is to not allow renewal and instead recommend that users who want longer, or never-expiring tokens can get them like this: http://docs.pulpproject.org/en/3.0/nightly/integration_guide/rest_api/authentication.html#offline-token-generation I'm slightly in favor of the "allow endless-renewal from a JWT" approach because what it lacks in desirable qualities, it ensures that during all normal usage, the user doesn't have to have to get out a Python shell. What is the right behavior here? On Wed, Nov 29, 2017 at 2:57 PM, Jeremy Audet wrote: > Jeremy, I don't think I understand your comment. >> >> You *will* have to use basic auth to refresh the token when the original >> one expires. >> > > Right. I understand that. I'm not arguing that we allow the user to > generate a valid JWT token using an expired, invalid JWT token. I'm arguing > that we allow the user to generate a valid JWT token using an unexpired, > valid JWT token. This allows use cases such as a client (web browser, CLI > tool, etc) being able to re-authenticate itself without re-prompting the > user for a username and password. This is especially relevant if the token > expiration time is set to a short value, such as 15 minutes. > > So there are limitations to a JWT, and for good reasons. A JWT is a weaker >> authenticator than a username+password because it expires. Because it is >> timestamped, it reduces the risk of compromising your account if someone >> sniffs the traffic. >> > > If there's security concerns here, then that's important, and they should > be weighted heavily. > > Note that there's an easy-to-use mechanism for invalidating a user's > tokens. > > >> Refreshing the token with a JWT seems marginally useful to me. >> > > ___ > 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
To me, the reason to use a token is to grant a client *temporary* access on behalf of the user who authenticated to begin with. Perpetual renewal makes the token as powerful as the username+password, and that seems wrong. Yes, you can invalidate the user's tokens, but it requires someone to notice that the token got compromised. Time (if an expiration is set) handles that for you. Imagine I authenticate with username + password, I get a token, and I use it a few times. At some point, someone steals the token. If they can renew it, they will forever impersonate me, until I notice and I request the token to be invalidated. If the original token and all its refreshes eventually expire, then they will have to wait for me to use the system again, in order to either steal my username + password, or the next token (arguably because if they did it once, they can do it again). If that won't happen any time soon, my account will be safe. Another scenario: someone tcpdumps my traffic (yes, somehow they have the SSL cert, work with this assumption for now). They can come back 3 days from now, browse the tcpdump output, and renew the token. That would not be possible with a short-lived token and no renewal past expiration. SSL will absolutely help and makes it less likely to mess up. But if you get your token via HTTPS, and somewhere way down into the API there is an (unsafe) redirect to HTTP that the client blindly obeys and sends the token (they never should), then your traffic is no longer protected so the token can be stolen. This scenario sounds like https://en.wikipedia.org/wiki/HTTP_cookie where browsers know not to send cookies over non-HTTPS if Secure is set. Sorry for the long diatribe. On Wed, Nov 29, 2017 at 4:18 PM, Brian Bouterse wrote: > I like the ability to refresh tokens. I imagined it would be allowed > forever with no limit (effectively disable JWT_REFRESH_EXPIRATION_DELTA). > If an admin wants to lock out the user they easily can regardless of > renewal. No one suggested this, but I believe we should not expose either > of these options in the Pulp settings at least for now. If we expose this > JWT plugin's feature set to Pulp users, then Pulp will have to carry that > feature set if we ever switch plugins. > > Allowing renewal does have an undesirable quality in that you can't issue > a JWT and trust the user has a limited, known amount time on the system. > The other option is to not allow renewal and instead recommend that users > who want longer, or never-expiring tokens can get them like this: > http://docs.pulpproject.org/en/3.0/nightly/integration_ > guide/rest_api/authentication.html#offline-token-generation > > I'm slightly in favor of the "allow endless-renewal from a JWT" approach > because what it lacks in desirable qualities, it ensures that during all > normal usage, the user doesn't have to have to get out a Python shell. > > What is the right behavior here? > > On Wed, Nov 29, 2017 at 2:57 PM, Jeremy Audet wrote: > >> Jeremy, I don't think I understand your comment. >>> >>> You *will* have to use basic auth to refresh the token when the original >>> one expires. >>> >> >> Right. I understand that. I'm not arguing that we allow the user to >> generate a valid JWT token using an expired, invalid JWT token. I'm arguing >> that we allow the user to generate a valid JWT token using an unexpired, >> valid JWT token. This allows use cases such as a client (web browser, CLI >> tool, etc) being able to re-authenticate itself without re-prompting the >> user for a username and password. This is especially relevant if the token >> expiration time is set to a short value, such as 15 minutes. >> >> So there are limitations to a JWT, and for good reasons. A JWT is a >>> weaker authenticator than a username+password because it expires. Because >>> it is timestamped, it reduces the risk of compromising your account if >>> someone sniffs the traffic. >>> >> >> If there's security concerns here, then that's important, and they should >> be weighted heavily. >> >> Note that there's an easy-to-use mechanism for invalidating a user's >> tokens. >> >> >>> Refreshing the token with a JWT seems marginally useful to me. >>> >> >> ___ >> 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
Good points. > Another scenario: someone tcpdumps my traffic (yes, somehow they have the SSL cert, work with this assumption for now). They can come back 3 days from now, browse the tcpdump output, and renew the token. That would not be possible with a short-lived token and no renewal past expiration. Renewal with expired tokens isn't being proposed. This is a straw man argument. ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
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. On Thu, Nov 30, 2017 at 12:21 PM, Jeremy Audet wrote: > Good points. > > > Another scenario: someone tcpdumps my traffic (yes, somehow they have > the SSL cert, work with this assumption for now). They can come back 3 > days from now, browse the tcpdump output, and renew the token. That would > not be possible with a short-lived token and no renewal past expiration. > > Renewal with expired tokens isn't being proposed. This is a straw man > argument. > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
Your proposal is basically what we have today (except it’s called JWT_ALLOW_REFRESH in django-rest-framework-jwt rather than JWT_REFRESH). You can configure settings for django-rest-framework-jwt from the server.yaml file [0] so users can turn on/off JWT_ALLOW_REFRESH. It defaults to False. The only thing we need to add is a refresh token endpoint (see [0]) and some docs. [0] https://getblimp.github.io/django-rest-framework-jwt/#additional-settings [1] https://getblimp.github.io/django-rest-framework-jwt/#refresh-token David On Thu, Nov 30, 2017 at 2:14 PM, Brian Bouterse 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. > > > > On Thu, Nov 30, 2017 at 12:21 PM, Jeremy Audet wrote: > >> Good points. >> >> > Another scenario: someone tcpdumps my traffic (yes, somehow they have >> the SSL cert, work with this assumption for now). They can come back 3 >> days from now, browse the tcpdump output, and renew the token. That >> would not be possible with a short-lived token and no renewal past >> expiration. >> >> Renewal with expired tokens isn't being proposed. This is a straw man >> argument. >> > > > ___ > 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
> > 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
+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 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse 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? > +1 > > On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
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 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 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
On Fri, Dec 1, 2017 at 2:47 PM, David Davis 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. > > I wrote up a redmine ticket for this: https://pulp.plan.io/issues/3163 > > David > > On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse > 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 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
+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 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 > 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 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
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_Viable_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 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 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 >> 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 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
> > - 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 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_ > Viable_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 > 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 >> 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 >>> 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 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
+1 to this On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley 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 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 >> 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 >>> 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 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 > 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
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
+1 David On Wed, Dec 13, 2017 at 11:36 AM, Brian Bouterse wrote: > +1 to this > > > On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley 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 >> 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 >>> 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 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 > 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 >> 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 >>> >>> >> > > _
Re: [Pulp-dev] Pulp 3: using JWT to request a JWT
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 wrote: > +1 > > > David > > On Wed, Dec 13, 2017 at 11:36 AM, Brian Bouterse > wrote: > >> +1 to this >> >> >> On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley 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 >>> 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 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 > 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 >> 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 >>> 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
