API Gateway about groot-api-gateway HOT 15 CLOSED

@acm-uiuc/project-groot So we have somewhat of a decision to make on how we progress, we can make a custom solution or we can use tyk which has an api management CLI and Dashboard. One is easier to manage (tyk) but we don't know how it works. The other means more work but and harder to use but we have full knowledge of how it works

from groot-api-gateway.

As much as I hate adding more work to the project, I'm in favor of rolling our own - primarily because a) it gives us more control and b) we occasionally have some odd use-cases that "one-size-fits-all" technology (cough Django) doesn't work well for (cough multiple databases on one website).

Also, Tyk doesn't seem to have drop-in support for Atlassian Crowd (which, per Admin, we have to use) - not that we couldn't integrate them ourselves (since Tyk supports that), but IMHO that reduces Tyk to a fancy URL-to-API router (which is something nginx plugins and Admin can do).

There's also the fact that Tyk uses Mongo and Redis, which I also don't think Admin is willing to support (since they already support MySQL) - so we'd have to maintain our own database systems without their help.

tl;dr: Tyk is a nice idea, but given Admin's restrictions and our concerns about backwards compatibility it's probably not worth the additional cost vs doing it ourselves.

-Ace

Date: Sun, 25 Oct 2015 19:47:28 -0700
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [groot] API Gateway (#18)

@acm-uiuc/project-groot So we have somewhat of a decision to make on how we progress, we can make a custom solution or we can use tyk which has an api management CLI and Dashboard. One is easier to manage (tyk) but we don't know how it works. The other means more work but and harder to use but we have full knowledge of how it works

—
Reply to this email directly or view it on GitHub.

from groot-api-gateway.

The other option analogous to tyk is kong, which works off cassandra. can you
explain more about the issue with crowd?

from groot-api-gateway.

The issue with Crowd is that it already provides us with access tokens. Though we can tell Tyk to store them or generate a separate token with Tyk for a Crowd-authenticated user, both options would involve us writing our own code since there's no drop-in integration between the two.

from groot-api-gateway.

@ace-n what is the session/auth scheme for liquid and should it persist. Since we are writing our own auth middleware we need to decide how long sessions last for where the walls are in our system (i.e between client and gateway or between client, gateway and services) and what will be our token to move around.

from groot-api-gateway.

@sskhandek are you validating sessions on the client side or do you need the server to do it?

from groot-api-gateway.

Here is the main question, do we need to authenticate requests between services, because that reduces complexity hugely

from groot-api-gateway.

@narendasan I'm not too experienced on the difference in terms of performance if we did it on the client side vs server. Maybe @ace-n can add input.

from groot-api-gateway.

Can you use the Crowd server to create auth tokens and then just have the service validate the token with Crowd?

1. User is not logged in and tries to go to service.acm.illinois.edu. Service does not find a valid token in storage.
2. User is redirected to Crowd SSO. They login to get a new token. This is saved in session storage.
3. Use is redirected back to service.acm.illinois.edu. Service finds token. Service makes POST request to Crowd (/session/) server to validate.
4. If bad, go to 2. If good, proceed with request.

For an API, this is all the same, except the Token is passed via an HTTP Header instead of session storage. If using Node, consider writing a single Passport Strategy and dropping this into every service.

from groot-api-gateway.

@ace-n do you know if crowd can create auth tokens, If so this is oauth, which is perfectly fine, we just need to implement the integration. The second question is do we need to authenticate anything behind the gateway or assume that behind the wall everything is open?

from groot-api-gateway.

1. Crowd can create authtokens that we can then verify with it
2. I would advocate for authing behind the gateway if it doesn't make things too complex, since it might yield a slight increase in security/tolerance for bugs.

For maximum security, each service should be doing its own auth through a standard library - i.e. every service verifies the token if/when it's called.

For ease-of-development, having an initial gateway and "assuming secure" behind it is probably better - but we would have to make sure people can't directly call the ungated API externally.

More info: https://developer.atlassian.com/display/CROWDDEV/Crowd+REST+Resources#CrowdRESTResources-CrowdSSOTokenResource

from groot-api-gateway.

@ace-n can you give me more details on interfacing with acm's instance of crowd, like what the root url is. A lot of the code in liquid is abstracted by the crowd library

from groot-api-gateway.

other than that we have the first functioning link from frontend to user service now through groot

from groot-api-gateway.

I will send you the Crowd url privately. You will also need to ask Admin to set you up with an application name and password.

from groot-api-gateway.

closed with acm-uiuc/groot#45

from groot-api-gateway.