Re: API GW route configuration
Jeremy, this is correct. However, in the current implementation the list of route/capabilities is hard coded, and is not yet derived from the api_capability table. The first email on this thread relates to this issue, raising some points for thought. Also, as Eric mentioned, the login route is forwarded to an auth server that check u/p and provides jwt. In order for Mojo auth to work for api routes, the auth server makes a login call to TO and get a Mojo token. It puts it in the jwt along with the user's capabilities. For each api call, the gw extracts the token from the jwt and put it in the request cookie. This is considered a patch until Mojo auth is deprecated. The jwt is not stripped from the request. It is passed to the service that can choose to make an additional auth call if required. On Sat, May 13, 2017, 00:22 Jeremy Mitchell wrote: > @chris > > 2. I may have missed it, but how is the route from the Gateway to TO > secured? > > This is how I understand it but Amir is really the source of truth on this. > > User bob has the foo role. The foo role has 2 "capabilities" (foo-read and > foo-write). foo-read maps to GET /api/*/foos and GET /api/*/foos/:id. > foo-write maps to POST /api/*/foos and PUT /api/*/foos/:id. So basically > Bob can do 4 things. > > When Bob originally logged in, the API gateway checked his u/p and created > a token that includes all his capabilities (foo-read and foo-write). > > When bob makes a call to GET /api/*/foos, he passes in his token and the > API Gateway deconstructs it and looks for the required capability > (foo-read) and since Bob has that he continues on...if he didn't have that > capability, the API gateway would spit back a 403 forbidden. > > The question is...how does the api gateway know the foo-read capability is > required for that route (GET /api/*/foos)? And I believe Amir said it was > stored in a config file in the api gateway that was derived from the > api_capabilities table. a new table that is part of this PR - > https://github.com/apache/incubator-trafficcontrol/pull/544 > > Here's a little bit more regarding roles/capabilities but I think it's a > little out of date - > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910 > > Jeremy > > > > On Fri, May 12, 2017 at 2:04 PM, Eric Friedrich (efriedri) < > efrie...@cisco.com> wrote: > > > Will it actually be the API Gateway that creates the auth token? If not, > > it would be useful to show the presence of an auth service that actually > > services the auth requests to the gateway. > > > > I don’t know if we got to consensus on validating the JWT token. I think > > API GW should certainly validate, but I don’t think it is sufficient in > all > > cases. An endpoint in the underlying “API Namespace” might need to > perform > > an additional token auth. We should make sure to allow that option (but > not > > make it mandatory) > > > > —Eric > > > > > > > On May 12, 2017, at 3:23 PM, Chris Lemmons wrote: > > > > > > Awesome diagram. Worth at least 1k words, I think. :) > > > > > > I've got two observations: > > > 1. In "checks capabilities found in JWT", that should include "validate > > JWT > > > with auth server", which can be as simple as checking a timestamp. > > > 2. I may have missed it, but how is the route from the Gateway to TO > > > secured? > > > > > > On Fri, May 12, 2017 at 8:41 AM David Neuman > > > > wrote: > > > > > >> +1 on keeping in on the mailing list > > >> > > >> On Fri, May 12, 2017 at 7:52 AM, Eric Friedrich (efriedri) < > > >> efrie...@cisco.com> wrote: > > >> > > >>> Can we please keep the discussion on the dev@ list? Apache rules and > > >> all. > > >>> > > >>> “If it didn’t happen on the email list, it didn’t happen” > > >>> > > >>> > > >>> On 5/12/17, 9:50 AM, "Amir Yeshurun" wrote: > > >>> > > >>>Moving discussion to the wiki page. Commented on Jeremy's notes > > >>> > > >>>On Fri, May 12, 2017 at 7:41 AM Shmulik Asafi > > > >>> wrote: > > >>> > > Regarding sharing signing key with other services raised by Eric - > > >>> notice > > jwt support asymmetric keys. I.e. only the auth server has the > > >>> private key > > and other services have a public key. > > > > Also, there's another solution for "global invalidation" besides > > >>> switching > > keys, and that is setting a threshold for token issue date. > > >> Whenever > > there's an attack or whatever and we want to invalidate all tokens > > >>> we just > > need to set the threshold for 'now' thus forcing all users to issue > > >>> a new > > token. > > I think this is more reasonable and scalable than switching keys. > > > > On 12 May 2017 05:15, "Jeremy Mitchell" > > >>> wrote: > > > > > Here was the image I was trying to attach: > > > > > > https://cwiki.apache.org/confluence/display/TC/API+Gateway > > > > > > Jeremy > > > > > > On Thu, May 11, 2017 at 2:14 PM, Amir Yeshurun > > >>> wro
Re: API GW route configuration
@chris 2. I may have missed it, but how is the route from the Gateway to TO secured? This is how I understand it but Amir is really the source of truth on this. User bob has the foo role. The foo role has 2 "capabilities" (foo-read and foo-write). foo-read maps to GET /api/*/foos and GET /api/*/foos/:id. foo-write maps to POST /api/*/foos and PUT /api/*/foos/:id. So basically Bob can do 4 things. When Bob originally logged in, the API gateway checked his u/p and created a token that includes all his capabilities (foo-read and foo-write). When bob makes a call to GET /api/*/foos, he passes in his token and the API Gateway deconstructs it and looks for the required capability (foo-read) and since Bob has that he continues on...if he didn't have that capability, the API gateway would spit back a 403 forbidden. The question is...how does the api gateway know the foo-read capability is required for that route (GET /api/*/foos)? And I believe Amir said it was stored in a config file in the api gateway that was derived from the api_capabilities table. a new table that is part of this PR - https://github.com/apache/incubator-trafficcontrol/pull/544 Here's a little bit more regarding roles/capabilities but I think it's a little out of date - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910 Jeremy On Fri, May 12, 2017 at 2:04 PM, Eric Friedrich (efriedri) < efrie...@cisco.com> wrote: > Will it actually be the API Gateway that creates the auth token? If not, > it would be useful to show the presence of an auth service that actually > services the auth requests to the gateway. > > I don’t know if we got to consensus on validating the JWT token. I think > API GW should certainly validate, but I don’t think it is sufficient in all > cases. An endpoint in the underlying “API Namespace” might need to perform > an additional token auth. We should make sure to allow that option (but not > make it mandatory) > > —Eric > > > > On May 12, 2017, at 3:23 PM, Chris Lemmons wrote: > > > > Awesome diagram. Worth at least 1k words, I think. :) > > > > I've got two observations: > > 1. In "checks capabilities found in JWT", that should include "validate > JWT > > with auth server", which can be as simple as checking a timestamp. > > 2. I may have missed it, but how is the route from the Gateway to TO > > secured? > > > > On Fri, May 12, 2017 at 8:41 AM David Neuman > > wrote: > > > >> +1 on keeping in on the mailing list > >> > >> On Fri, May 12, 2017 at 7:52 AM, Eric Friedrich (efriedri) < > >> efrie...@cisco.com> wrote: > >> > >>> Can we please keep the discussion on the dev@ list? Apache rules and > >> all. > >>> > >>> “If it didn’t happen on the email list, it didn’t happen” > >>> > >>> > >>> On 5/12/17, 9:50 AM, "Amir Yeshurun" wrote: > >>> > >>>Moving discussion to the wiki page. Commented on Jeremy's notes > >>> > >>>On Fri, May 12, 2017 at 7:41 AM Shmulik Asafi > >>> wrote: > >>> > Regarding sharing signing key with other services raised by Eric - > >>> notice > jwt support asymmetric keys. I.e. only the auth server has the > >>> private key > and other services have a public key. > > Also, there's another solution for "global invalidation" besides > >>> switching > keys, and that is setting a threshold for token issue date. > >> Whenever > there's an attack or whatever and we want to invalidate all tokens > >>> we just > need to set the threshold for 'now' thus forcing all users to issue > >>> a new > token. > I think this is more reasonable and scalable than switching keys. > > On 12 May 2017 05:15, "Jeremy Mitchell" > >>> wrote: > > > Here was the image I was trying to attach: > > > > https://cwiki.apache.org/confluence/display/TC/API+Gateway > > > > Jeremy > > > > On Thu, May 11, 2017 at 2:14 PM, Amir Yeshurun > >>> wrote: > > > >> Hi Jeremy, > >> Note that attachments seems to be stripped off on this list and > >>> the > image > >> is unavailable. > >> > >> Your assumptions are correct. We need to figure out the easiest > topology > >> for UI routes to bypass the GW. Please reattach the picture so > >>> we can > get > >> more specific. > >> > >> Thanks > >> /amiry > >> > >> > >> > >> On Thu, May 11, 2017, 20:06 Jeremy Mitchell < > >>> mitchell...@gmail.com> > > wrote: > >> > >>> What is of utmost importance to me is the ability to ease > >> into > >>> this. > We > >>> have a TO UI right now that needs to be unaffected by the API > >>> gateway > > in > >> my > >>> opinion. Granted the old UI might go away at some point but > >>> until > that > >> time > >>> it needs to function as-is. > >>> > >>> To me, the simplest approach is to key off request URL. > >>> anything that > >>> starts with /api gets api gateway treatment, the rest passes > >> on > >>>
Re: API GW route configuration
Will it actually be the API Gateway that creates the auth token? If not, it would be useful to show the presence of an auth service that actually services the auth requests to the gateway. I don’t know if we got to consensus on validating the JWT token. I think API GW should certainly validate, but I don’t think it is sufficient in all cases. An endpoint in the underlying “API Namespace” might need to perform an additional token auth. We should make sure to allow that option (but not make it mandatory) —Eric > On May 12, 2017, at 3:23 PM, Chris Lemmons wrote: > > Awesome diagram. Worth at least 1k words, I think. :) > > I've got two observations: > 1. In "checks capabilities found in JWT", that should include "validate JWT > with auth server", which can be as simple as checking a timestamp. > 2. I may have missed it, but how is the route from the Gateway to TO > secured? > > On Fri, May 12, 2017 at 8:41 AM David Neuman > wrote: > >> +1 on keeping in on the mailing list >> >> On Fri, May 12, 2017 at 7:52 AM, Eric Friedrich (efriedri) < >> efrie...@cisco.com> wrote: >> >>> Can we please keep the discussion on the dev@ list? Apache rules and >> all. >>> >>> “If it didn’t happen on the email list, it didn’t happen” >>> >>> >>> On 5/12/17, 9:50 AM, "Amir Yeshurun" wrote: >>> >>>Moving discussion to the wiki page. Commented on Jeremy's notes >>> >>>On Fri, May 12, 2017 at 7:41 AM Shmulik Asafi >>> wrote: >>> Regarding sharing signing key with other services raised by Eric - >>> notice jwt support asymmetric keys. I.e. only the auth server has the >>> private key and other services have a public key. Also, there's another solution for "global invalidation" besides >>> switching keys, and that is setting a threshold for token issue date. >> Whenever there's an attack or whatever and we want to invalidate all tokens >>> we just need to set the threshold for 'now' thus forcing all users to issue >>> a new token. I think this is more reasonable and scalable than switching keys. On 12 May 2017 05:15, "Jeremy Mitchell" >>> wrote: > Here was the image I was trying to attach: > > https://cwiki.apache.org/confluence/display/TC/API+Gateway > > Jeremy > > On Thu, May 11, 2017 at 2:14 PM, Amir Yeshurun >>> wrote: > >> Hi Jeremy, >> Note that attachments seems to be stripped off on this list and >>> the image >> is unavailable. >> >> Your assumptions are correct. We need to figure out the easiest topology >> for UI routes to bypass the GW. Please reattach the picture so >>> we can get >> more specific. >> >> Thanks >> /amiry >> >> >> >> On Thu, May 11, 2017, 20:06 Jeremy Mitchell < >>> mitchell...@gmail.com> > wrote: >> >>> What is of utmost importance to me is the ability to ease >> into >>> this. We >>> have a TO UI right now that needs to be unaffected by the API >>> gateway > in >> my >>> opinion. Granted the old UI might go away at some point but >>> until that >> time >>> it needs to function as-is. >>> >>> To me, the simplest approach is to key off request URL. >>> anything that >>> starts with /api gets api gateway treatment, the rest passes >> on >>> thru...Here's a fancy picture to communicate what I >> envision... >>> >>> [image: Inline image 1] >>> >>> I'm assuming all requests (endpoints) go thru the api gateway >>> but maybe >>> i'm wrong in that assumption. Anyhow, i guess my point is the >>> UI should >>> continue to work with the mojo cookie and "api" calls should >>> use the > jwt >>> token...however, the UI also uses api endpoints so not sure >>> how that >> would >>> work... >>> >>> If it's too difficult for the api gateway to support UI and >> API routes, >> we >>> could always wait until the new UI (which leverages the API) >> is >> complete... >>> >>> Jeremy >>> >>> On Thu, May 11, 2017 at 10:23 AM, Chris Lemmons < >>> alfic...@gmail.com> >>> wrote: >>> > invalidate ALL tokens by changing the token signing key Interesting idea. That does mean that the signing key has to >>> be >> retrieved every time from the authentication authority, or it'd be >>> subject to > the exact same set of attacks. But a nearly-constant rarely >>> changing key >> could be communicated very efficiently, I suspect. And if the authentication system is a web API, it can even use Modified-Since to 304 >>> 99% of the >> time for maximum efficiency. It does have the downside that key-invalidation events are >>> fairly significant. You'd need to invalidate the keys whenever >>> someone's > access was reduced or removed.
Re: API GW route configuration
Awesome diagram. Worth at least 1k words, I think. :) I've got two observations: 1. In "checks capabilities found in JWT", that should include "validate JWT with auth server", which can be as simple as checking a timestamp. 2. I may have missed it, but how is the route from the Gateway to TO secured? On Fri, May 12, 2017 at 8:41 AM David Neuman wrote: > +1 on keeping in on the mailing list > > On Fri, May 12, 2017 at 7:52 AM, Eric Friedrich (efriedri) < > efrie...@cisco.com> wrote: > > > Can we please keep the discussion on the dev@ list? Apache rules and > all. > > > > “If it didn’t happen on the email list, it didn’t happen” > > > > > > On 5/12/17, 9:50 AM, "Amir Yeshurun" wrote: > > > > Moving discussion to the wiki page. Commented on Jeremy's notes > > > > On Fri, May 12, 2017 at 7:41 AM Shmulik Asafi > > wrote: > > > > > Regarding sharing signing key with other services raised by Eric - > > notice > > > jwt support asymmetric keys. I.e. only the auth server has the > > private key > > > and other services have a public key. > > > > > > Also, there's another solution for "global invalidation" besides > > switching > > > keys, and that is setting a threshold for token issue date. > Whenever > > > there's an attack or whatever and we want to invalidate all tokens > > we just > > > need to set the threshold for 'now' thus forcing all users to issue > > a new > > > token. > > > I think this is more reasonable and scalable than switching keys. > > > > > > On 12 May 2017 05:15, "Jeremy Mitchell" > > wrote: > > > > > > > Here was the image I was trying to attach: > > > > > > > > https://cwiki.apache.org/confluence/display/TC/API+Gateway > > > > > > > > Jeremy > > > > > > > > On Thu, May 11, 2017 at 2:14 PM, Amir Yeshurun > > wrote: > > > > > > > > > Hi Jeremy, > > > > > Note that attachments seems to be stripped off on this list and > > the > > > image > > > > > is unavailable. > > > > > > > > > > Your assumptions are correct. We need to figure out the easiest > > > topology > > > > > for UI routes to bypass the GW. Please reattach the picture so > > we can > > > get > > > > > more specific. > > > > > > > > > > Thanks > > > > > /amiry > > > > > > > > > > > > > > > > > > > > On Thu, May 11, 2017, 20:06 Jeremy Mitchell < > > mitchell...@gmail.com> > > > > wrote: > > > > > > > > > > > What is of utmost importance to me is the ability to ease > into > > this. > > > We > > > > > > have a TO UI right now that needs to be unaffected by the API > > gateway > > > > in > > > > > my > > > > > > opinion. Granted the old UI might go away at some point but > > until > > > that > > > > > time > > > > > > it needs to function as-is. > > > > > > > > > > > > To me, the simplest approach is to key off request URL. > > anything that > > > > > > starts with /api gets api gateway treatment, the rest passes > on > > > > > > thru...Here's a fancy picture to communicate what I > envision... > > > > > > > > > > > > [image: Inline image 1] > > > > > > > > > > > > I'm assuming all requests (endpoints) go thru the api gateway > > but > > > maybe > > > > > > i'm wrong in that assumption. Anyhow, i guess my point is the > > UI > > > should > > > > > > continue to work with the mojo cookie and "api" calls should > > use the > > > > jwt > > > > > > token...however, the UI also uses api endpoints so not sure > > how that > > > > > would > > > > > > work... > > > > > > > > > > > > If it's too difficult for the api gateway to support UI and > API > > > routes, > > > > > we > > > > > > could always wait until the new UI (which leverages the API) > is > > > > > complete... > > > > > > > > > > > > Jeremy > > > > > > > > > > > > On Thu, May 11, 2017 at 10:23 AM, Chris Lemmons < > > alfic...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> > invalidate ALL tokens by changing the token signing key > > > > > >> > > > > > >> Interesting idea. That does mean that the signing key has to > > be > > > > > retrieved > > > > > >> every time from the authentication authority, or it'd be > > subject to > > > > the > > > > > >> exact same set of attacks. But a nearly-constant rarely > > changing key > > > > > could > > > > > >> be communicated very efficiently, I suspect. And if the > > > authentication > > > > > >> system is a web API, it can even use Modified-Since to 304 > > 99% of > > > the > > > > > time > > > > > >> for maximum efficiency. > > > > > >> > > > > > >> It does have the downside that key-invalidation events are > > fairly > > > > > >> significant. You'd need to invalidate the keys whenever > > someone's > > > > access > > > > > >> was reduced or
Re: API GW route configuration
+1 on keeping in on the mailing list On Fri, May 12, 2017 at 7:52 AM, Eric Friedrich (efriedri) < efrie...@cisco.com> wrote: > Can we please keep the discussion on the dev@ list? Apache rules and all. > > “If it didn’t happen on the email list, it didn’t happen” > > > On 5/12/17, 9:50 AM, "Amir Yeshurun" wrote: > > Moving discussion to the wiki page. Commented on Jeremy's notes > > On Fri, May 12, 2017 at 7:41 AM Shmulik Asafi > wrote: > > > Regarding sharing signing key with other services raised by Eric - > notice > > jwt support asymmetric keys. I.e. only the auth server has the > private key > > and other services have a public key. > > > > Also, there's another solution for "global invalidation" besides > switching > > keys, and that is setting a threshold for token issue date. Whenever > > there's an attack or whatever and we want to invalidate all tokens > we just > > need to set the threshold for 'now' thus forcing all users to issue > a new > > token. > > I think this is more reasonable and scalable than switching keys. > > > > On 12 May 2017 05:15, "Jeremy Mitchell" > wrote: > > > > > Here was the image I was trying to attach: > > > > > > https://cwiki.apache.org/confluence/display/TC/API+Gateway > > > > > > Jeremy > > > > > > On Thu, May 11, 2017 at 2:14 PM, Amir Yeshurun > wrote: > > > > > > > Hi Jeremy, > > > > Note that attachments seems to be stripped off on this list and > the > > image > > > > is unavailable. > > > > > > > > Your assumptions are correct. We need to figure out the easiest > > topology > > > > for UI routes to bypass the GW. Please reattach the picture so > we can > > get > > > > more specific. > > > > > > > > Thanks > > > > /amiry > > > > > > > > > > > > > > > > On Thu, May 11, 2017, 20:06 Jeremy Mitchell < > mitchell...@gmail.com> > > > wrote: > > > > > > > > > What is of utmost importance to me is the ability to ease into > this. > > We > > > > > have a TO UI right now that needs to be unaffected by the API > gateway > > > in > > > > my > > > > > opinion. Granted the old UI might go away at some point but > until > > that > > > > time > > > > > it needs to function as-is. > > > > > > > > > > To me, the simplest approach is to key off request URL. > anything that > > > > > starts with /api gets api gateway treatment, the rest passes on > > > > > thru...Here's a fancy picture to communicate what I envision... > > > > > > > > > > [image: Inline image 1] > > > > > > > > > > I'm assuming all requests (endpoints) go thru the api gateway > but > > maybe > > > > > i'm wrong in that assumption. Anyhow, i guess my point is the > UI > > should > > > > > continue to work with the mojo cookie and "api" calls should > use the > > > jwt > > > > > token...however, the UI also uses api endpoints so not sure > how that > > > > would > > > > > work... > > > > > > > > > > If it's too difficult for the api gateway to support UI and API > > routes, > > > > we > > > > > could always wait until the new UI (which leverages the API) is > > > > complete... > > > > > > > > > > Jeremy > > > > > > > > > > On Thu, May 11, 2017 at 10:23 AM, Chris Lemmons < > alfic...@gmail.com> > > > > > wrote: > > > > > > > > > >> > invalidate ALL tokens by changing the token signing key > > > > >> > > > > >> Interesting idea. That does mean that the signing key has to > be > > > > retrieved > > > > >> every time from the authentication authority, or it'd be > subject to > > > the > > > > >> exact same set of attacks. But a nearly-constant rarely > changing key > > > > could > > > > >> be communicated very efficiently, I suspect. And if the > > authentication > > > > >> system is a web API, it can even use Modified-Since to 304 > 99% of > > the > > > > time > > > > >> for maximum efficiency. > > > > >> > > > > >> It does have the downside that key-invalidation events are > fairly > > > > >> significant. You'd need to invalidate the keys whenever > someone's > > > access > > > > >> was reduced or removed. As the number of accounts in the > system > > > > increases, > > > > >> that might not wind up being as infrequent as one might hope. > It's > > > easy > > > > to > > > > >> implement, though. > > > > >> > > > > >> On Thu, May 11, 2017 at 10:12 AM Jeremy Mitchell < > > > mitchell...@gmail.com > > > > > > > > > >> wrote: > > > > >> > > > > >> > Regarding the TTL on the JWT token. a 5 minute TTL seems > silly. > > > What's > > > > >> the > > > > >> > point? Unless we get into refresh tokens but that sounds > like > > > > >> oauth...blah. > > > > >> > > > > > >
Re: API GW route configuration
Can we please keep the discussion on the dev@ list? Apache rules and all. “If it didn’t happen on the email list, it didn’t happen” On 5/12/17, 9:50 AM, "Amir Yeshurun" wrote: Moving discussion to the wiki page. Commented on Jeremy's notes On Fri, May 12, 2017 at 7:41 AM Shmulik Asafi wrote: > Regarding sharing signing key with other services raised by Eric - notice > jwt support asymmetric keys. I.e. only the auth server has the private key > and other services have a public key. > > Also, there's another solution for "global invalidation" besides switching > keys, and that is setting a threshold for token issue date. Whenever > there's an attack or whatever and we want to invalidate all tokens we just > need to set the threshold for 'now' thus forcing all users to issue a new > token. > I think this is more reasonable and scalable than switching keys. > > On 12 May 2017 05:15, "Jeremy Mitchell" wrote: > > > Here was the image I was trying to attach: > > > > https://cwiki.apache.org/confluence/display/TC/API+Gateway > > > > Jeremy > > > > On Thu, May 11, 2017 at 2:14 PM, Amir Yeshurun wrote: > > > > > Hi Jeremy, > > > Note that attachments seems to be stripped off on this list and the > image > > > is unavailable. > > > > > > Your assumptions are correct. We need to figure out the easiest > topology > > > for UI routes to bypass the GW. Please reattach the picture so we can > get > > > more specific. > > > > > > Thanks > > > /amiry > > > > > > > > > > > > On Thu, May 11, 2017, 20:06 Jeremy Mitchell > > wrote: > > > > > > > What is of utmost importance to me is the ability to ease into this. > We > > > > have a TO UI right now that needs to be unaffected by the API gateway > > in > > > my > > > > opinion. Granted the old UI might go away at some point but until > that > > > time > > > > it needs to function as-is. > > > > > > > > To me, the simplest approach is to key off request URL. anything that > > > > starts with /api gets api gateway treatment, the rest passes on > > > > thru...Here's a fancy picture to communicate what I envision... > > > > > > > > [image: Inline image 1] > > > > > > > > I'm assuming all requests (endpoints) go thru the api gateway but > maybe > > > > i'm wrong in that assumption. Anyhow, i guess my point is the UI > should > > > > continue to work with the mojo cookie and "api" calls should use the > > jwt > > > > token...however, the UI also uses api endpoints so not sure how that > > > would > > > > work... > > > > > > > > If it's too difficult for the api gateway to support UI and API > routes, > > > we > > > > could always wait until the new UI (which leverages the API) is > > > complete... > > > > > > > > Jeremy > > > > > > > > On Thu, May 11, 2017 at 10:23 AM, Chris Lemmons > > > > wrote: > > > > > > > >> > invalidate ALL tokens by changing the token signing key > > > >> > > > >> Interesting idea. That does mean that the signing key has to be > > > retrieved > > > >> every time from the authentication authority, or it'd be subject to > > the > > > >> exact same set of attacks. But a nearly-constant rarely changing key > > > could > > > >> be communicated very efficiently, I suspect. And if the > authentication > > > >> system is a web API, it can even use Modified-Since to 304 99% of > the > > > time > > > >> for maximum efficiency. > > > >> > > > >> It does have the downside that key-invalidation events are fairly > > > >> significant. You'd need to invalidate the keys whenever someone's > > access > > > >> was reduced or removed. As the number of accounts in the system > > > increases, > > > >> that might not wind up being as infrequent as one might hope. It's > > easy > > > to > > > >> implement, though. > > > >> > > > >> On Thu, May 11, 2017 at 10:12 AM Jeremy Mitchell < > > mitchell...@gmail.com > > > > > > > >> wrote: > > > >> > > > >> > Regarding the TTL on the JWT token. a 5 minute TTL seems silly. > > What's > > > >> the > > > >> > point? Unless we get into refresh tokens but that sounds like > > > >> oauth...blah. > > > >> > > > > >> > What about this and maybe i'm oversimplifying. the TTL on the jwt > > > token > > > >> is > > > >> > 24 hours. If we become aware that a token has been compromised, > > > >> invalidate > > > >> > ALL tokens by changing the token signing key. maybe this is a good > > > idea > > > >> or > > > >> > maybe this is a terrible idea. I have no idea. just a thought.. > > > >> > > > > >> > jeremy > > > >> > > > > >> >
Re: API GW route configuration
Moving discussion to the wiki page. Commented on Jeremy's notes On Fri, May 12, 2017 at 7:41 AM Shmulik Asafi wrote: > Regarding sharing signing key with other services raised by Eric - notice > jwt support asymmetric keys. I.e. only the auth server has the private key > and other services have a public key. > > Also, there's another solution for "global invalidation" besides switching > keys, and that is setting a threshold for token issue date. Whenever > there's an attack or whatever and we want to invalidate all tokens we just > need to set the threshold for 'now' thus forcing all users to issue a new > token. > I think this is more reasonable and scalable than switching keys. > > On 12 May 2017 05:15, "Jeremy Mitchell" wrote: > > > Here was the image I was trying to attach: > > > > https://cwiki.apache.org/confluence/display/TC/API+Gateway > > > > Jeremy > > > > On Thu, May 11, 2017 at 2:14 PM, Amir Yeshurun wrote: > > > > > Hi Jeremy, > > > Note that attachments seems to be stripped off on this list and the > image > > > is unavailable. > > > > > > Your assumptions are correct. We need to figure out the easiest > topology > > > for UI routes to bypass the GW. Please reattach the picture so we can > get > > > more specific. > > > > > > Thanks > > > /amiry > > > > > > > > > > > > On Thu, May 11, 2017, 20:06 Jeremy Mitchell > > wrote: > > > > > > > What is of utmost importance to me is the ability to ease into this. > We > > > > have a TO UI right now that needs to be unaffected by the API gateway > > in > > > my > > > > opinion. Granted the old UI might go away at some point but until > that > > > time > > > > it needs to function as-is. > > > > > > > > To me, the simplest approach is to key off request URL. anything that > > > > starts with /api gets api gateway treatment, the rest passes on > > > > thru...Here's a fancy picture to communicate what I envision... > > > > > > > > [image: Inline image 1] > > > > > > > > I'm assuming all requests (endpoints) go thru the api gateway but > maybe > > > > i'm wrong in that assumption. Anyhow, i guess my point is the UI > should > > > > continue to work with the mojo cookie and "api" calls should use the > > jwt > > > > token...however, the UI also uses api endpoints so not sure how that > > > would > > > > work... > > > > > > > > If it's too difficult for the api gateway to support UI and API > routes, > > > we > > > > could always wait until the new UI (which leverages the API) is > > > complete... > > > > > > > > Jeremy > > > > > > > > On Thu, May 11, 2017 at 10:23 AM, Chris Lemmons > > > > wrote: > > > > > > > >> > invalidate ALL tokens by changing the token signing key > > > >> > > > >> Interesting idea. That does mean that the signing key has to be > > > retrieved > > > >> every time from the authentication authority, or it'd be subject to > > the > > > >> exact same set of attacks. But a nearly-constant rarely changing key > > > could > > > >> be communicated very efficiently, I suspect. And if the > authentication > > > >> system is a web API, it can even use Modified-Since to 304 99% of > the > > > time > > > >> for maximum efficiency. > > > >> > > > >> It does have the downside that key-invalidation events are fairly > > > >> significant. You'd need to invalidate the keys whenever someone's > > access > > > >> was reduced or removed. As the number of accounts in the system > > > increases, > > > >> that might not wind up being as infrequent as one might hope. It's > > easy > > > to > > > >> implement, though. > > > >> > > > >> On Thu, May 11, 2017 at 10:12 AM Jeremy Mitchell < > > mitchell...@gmail.com > > > > > > > >> wrote: > > > >> > > > >> > Regarding the TTL on the JWT token. a 5 minute TTL seems silly. > > What's > > > >> the > > > >> > point? Unless we get into refresh tokens but that sounds like > > > >> oauth...blah. > > > >> > > > > >> > What about this and maybe i'm oversimplifying. the TTL on the jwt > > > token > > > >> is > > > >> > 24 hours. If we become aware that a token has been compromised, > > > >> invalidate > > > >> > ALL tokens by changing the token signing key. maybe this is a good > > > idea > > > >> or > > > >> > maybe this is a terrible idea. I have no idea. just a thought.. > > > >> > > > > >> > jeremy > > > >> > > > > >> > On Wed, May 10, 2017 at 12:23 PM, Chris Lemmons < > alfic...@gmail.com > > > > > > >> > wrote: > > > >> > > > > >> > > Responding to a few people: > > > >> > > > > > >> > > > Often times every auth action must be accompanied by DB writes > > for > > > >> > audit > > > >> > > logs or callback functions. > > > >> > > > > > >> > > True. But a) if logging is too expensive it should probably be > > made > > > >> > cheaper > > > >> > > and b) the answer to "audits are too expensive" probably isn't > > "lets > > > >> just > > > >> > > do less authentication". If the audit log is genuinely the > > > >> bottle-neck, > > > >> > it > > > >> > > would still be better to re-auth without the audit log. > > > >
