securing your REST services

[Mike Hogan]

Looking for the best way to secure REST api calls between a bunch of microservices. Nearly all of these calls are done without user involvement or initiation. Its algo trading, so machines talking to machines i.e. nobody logging in through a browser. All the services are publicly available on the internet over HTTPS.

Having said that, there are times users need to login and do things with a proper audit trail of “who was this person and what did they do”.

So we have two requirements:

1) Secure our publicly available REST apis so they can be safely called by other services in our app, and only by our own services
2) Allow calling of those same REST apis by a “logged in user” sometimes

Any recommendations from concrete experience on this, or else good links to read?

Thanks very much,
Mike.

[Mike Hogan]

freewheeling on this a bit more, I guess 1) is a case of authenticating and authorising machines talking to machines, and 2) is a case of SSO across all the services for a signed in user.

[Matt Savage]

Scott's rundown of enterprise-y options here is good, and also depressing: http://www.grahamlea.com/2015/03/notes-from-yow-2014-scott-shaw-on-avoiding-speedbumps-on-the-road-to-microservices

I don't have a good answer to your question. If you hadn't mentioned SSO I would have suggested https+basic auth. Ghetto simplicity.

--
You received this message because you are subscribed to the Google Groups "utterlyidle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utterlyidle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Hogan]

Actually Matt, thats surprisingly helpful, if only in the sense of emotional relief that I’m not the only guy in the world who doesn’t get it.  Thanks :)

On 4 Mar 2015, at 10:23, Matt Savage <matthew...@gmail.com> wrote:

Scott's rundown of enterprise-y options here is good, and also depressing: http://www.grahamlea.com/2015/03/notes-from-yow-2014-scott-shaw-on-avoiding-speedbumps-on-the-road-to-microservices

I don't have a good answer to your question. If you hadn't mentioned SSO I would have suggested https+basic auth. Ghetto simplicity.

On 4 Mar 2015 07:34, "Mike Hogan" <m...@mikehogan.net> wrote:

--
You received this message because you are subscribed to the Google Groups "utterlyidle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utterlyidle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Savage]

All options I've seen seem to be annoying once you have enough services and apps that you need delegated/federated auth and SSO. And also once you're dealing with service to service and browser to service communication, where the former wants to be stateless and the latter wants to be session based. The problem is not simple.

That's why I'd prefer not to solve it by staying ghetto. At some point of course that stops being possible.

[Daniel Worthington-Bodart]

I'm currently looking at a bunch of SSO options for Springer, no real winners yet but will let you know if anything jumps out.

If I had an utterlyidle only option that actually worked and was pretty sane would that be of interest?

In fact I need to talk to you both about an idea I've had (offline)

[Mike Hogan]

We have hand-rolled our own one that is a http conversation about http conversations, and its not a winner either :)

Intrigued to see what can be done in utterlyidle but NOT in other frameworks :)  We use ring also, and maybe some others I am not aware of.

On 4 Mar 2015, at 22:07, Daniel Worthington-Bodart <d...@bodar.com> wrote:

I'm currently looking at a bunch of SSO options for Springer, no real winners yet but will let you know if anything jumps out.

If I had an utterlyidle only option that actually worked and was pretty sane would that be of interest?

In fact I need to talk to you both about an idea I've had (offline)

On 4 Mar 2015 10:42, "Matt Savage" <matthew...@gmail.com> wrote:

[Raymond Barlow]

I really like what we did previously, using cookie-based authentication. Holding the state of who you are, and what permissions you have in the client made a lot of sense, and made testing super easy.

Given, that was for a browser-based application, but I could see this being extended to services. A service requires you to have the correct header(s) to be authorised and authenticated within a timeout (all encrypted & encoded).

Obviously, this would require each service to understand this, or at the very least, some way of adapting the client auth'd stuff to what the server needs.

/Raymond

[Alex Luker]

+1 on the client side cookie. Worked really nicely with load balancing and  statelessness on the backend.

[Matt Savage]

I really liked that too.

But stateful authentication for services is a bit annoying.

[Daniel Worthington-Bodart]

I'd probably use the cookie way for users and then use s3 header for services. Obviously if it was a javascript app you could just use the s3 for everything.

[Daniel Worthington-Bodart]

Let's resurrect the dead:  

So we are currently investigation API brokers to add security etc to our internal services:

https://tyk.io/

Tyk looks good from it's feature set but we haven't deployed it yet.

I'll send an email out to [s+c] to see if anyone has any other alternatives