I've been looking into developing a microservice architecture using SpringBoot and some netflix libraries such as Eureka, Zuul, Ribbon; however, I appear to be hung up with the security design.
My goal is to use a third party web based service such as Okta.com to manage all my users and applications. Okta uses Oauth2 which I believe would make my application stateful. My goal is to keep my application stateless for load balancing purposes.
I would be using the following service module architecture,
Gateway Service
Auth Service (Authenticate against Okta)
Microservice 1 (role_admin, role_sales)
Microservice 2 (role_admin, role_employee)
My understanding is when the gateway has requested routing to Microservice 1 or Microservice 2, a token would need to be forwarded along with the request and if no token is present, a request to the Auth Service at the gateway would need to be made in order to obtain a token from Okta using Oauth2.
My next piece of understanding is while using oauth2, when the token is present and has been forwarded along to Microservice 1 or Microservice 2, the token would need to validated against okta again. The groups would be contained within the token.
My question is could Okta be used solely for the purpose of Authenticating and Authorization, but rather than passing around the stateful oauth2 tokens generated by Okta, create a stateless JWT which would contain roles and user info and pass that back to the microservices?
I'm just wondering how to use a service like Okta in a microservice architecture, but still keep my microservices stateless and I'm not sure my thought process is correct.
Related
This is an architecture question. I want to implement an application that processes two kinds of users (admin and clients). Each role can register in the following ways:
admin: username/password registration
client: Facebook/Google/username&password registration
Based on the user's role each of them has a specific action to which he's authorized.
From a technology stack, I want to use Java 8, Spring Cloud Netflix and later on Docker and Kubernetes (in order to have auto-heal and auto-scale).
I've implemented Eureka discovery, Config server, Zuul Gateway and I have two microservices for each role (to get me started). I don't know at all how to approach the user's authentication/authorization, from what I see Spring Security 5 is no longer supporting Authorization server and I am supposed to use Keycloack? Should the gateway be the authorization server or should I create another component that is responsible for authentication? What do I use, how to implement, how to approach redirection between my authorization server and the business microservice?
I can't really find a proper documentation that uses username/password, social login and Spring Cloud Netflix, together with Spring Security 5.
Your gateway shouldn't be responsible for handling authentication.
One possibility is using the cas project. It can run as a micro service to handle the whole authentication process. It can handle multiple auth methods like database (for username / password) and social media like Google or Facebook.
It comes with a basic setup having a login page and a configured DockerFile. You can customize everything. Just add the related dependency and add the config in the application.properties. You can customize the frontend.
https://apereo.github.io/cas/6.1.x/planning/Getting-Started.html
By the way: if you use kubernetes you don't need a gateway or service discovery with eureka. Kubernetes does this for you.
For api security, after moving to #Kubernetes, you can use Envoy or similar solution
For authentication and authorisation, you need an identity management system (like #Okta or PingFederate or an open source version like #OpenIAM) and then integrate using Spring & OAUTH2.
I'm developing an authentication/authorization system in Node Js for a microservice based application.
I read some articles and documentation about the OAuth2 standard but I need some clarification for my use case.
Basically OAuth2 has some actors like:
Resource owner (user)
Client app (a web application in some OAuth2 grant flows like authorization code, implicit, password)
Authorization server
Resource server (service I want to access to)
So in my database I store a client (web application) with its client_id and client_secret.
Let's suppose that one of my microservice needs to access data from another microservice. Both of them espose a REST Api.
There is no interaction with user, all is done in the background. In this case I would use the client credential flow.
Following OAuth2 rules, both of them are resource servers but in the same time it looks like they are client apps as well.
So should I register them in the client DB table/collection with client id, secret etcetera or did I make some mistakes?
Thank you
If I understood your question correctly, the caller micro-service is your client and the one that is being called is your resource. A lot depends on what type of micro-service communication pattern have you implemented. If you are implementing an "API Gateway" pattern, then your Gateway is always client and all other micro-services can be treated as resources. But if your micro-services can call each other then like you mentioned each one of them have to be registered as client and resource at the same time.
The case: the System-K has many microservices. One of them is the OAuth microservice which provides access tokens for 3rd parties that will consume some data managed by others microservices of the System-K.
The System-K also have a frontend that is a SPA web application. This SPA also consumes the same data that 3rd parties do, but with the difference that this SPA will be able to query privileged data since is the owned Sysmte-k front-end.
The question: Which OAuth strategy to use for the SPA? or I should use another approach to handle authentication request made by the SPA and leaves the OAuth server just for 3rd parties?
Under the hood:
The web application is built with Angular 7+, this sends requests to an APIGateway which is a microservice, part of the Sysmte-k, then APIGateway routes such requests to the target microservice.
3rd parties OAuth request are sent also to APIGateway which routes to the OAuth microservice. All microservices are build in Node and written with TypeScript.
Update 1
I do not want users who authenticate in the SPA to see a screen saying "Do you allow the System-K to access your Sysmte-k profile?" since the SPA is the System-k client itself.
Question: - Which OAuth strategy to use for the SPA? or I should use
another approach to handle authentication request made by the SPA and
leaves the OAuth server just for 3rd parties?
Unless your SPA has a backend server (which means that your SPA is not really an SPA) you are limited to using implicit OAuth. Implicit OAuth runs in JavaScript in the browser.
For implicit OAuth I strongly recommend using a third party Identity Provider (Google, Auth0, Okta). Getting the security correct in your own code is very difficult.
If you can add a backend service to provide three-legged OAuth, your security will improve and you will have many more options. Again I recommend a third party Identity Provider.
I currently have the ability to host one and only one site (meaning under one domain). I will have a SPA front-end, Web Api resource, and then IdentityServer4 for security (utilizing AspNetCore Identity framework for user management).
Something feels "wrong" with this approach as a single hosted site architecture. I believe AspNet Identity creates an auth cookie once authenticated, and then IdentityServer would be serving up JWT tokens for my SPA to call my API.
Upon further reflection though, this seems misguided. The thing that seems off is that I believe my API calls will also have the auth cookie automatically attached along with the JWT token in the header because the API call will be requesting from the same domain as the auth cookie was generated. And so it seems I'm using two forms of authentication at once unnecessarily... thoughts?
In other words, when everything is running under one domain, is adding IdentityServer4 to an AspNetCore Identity-enabled application unnecessary? The one benefit to plumbing in IdentityServer4 would be to future proof the application if it were to ever be deployed separate from its Resource (Web Api), then you would have nothing but configuration to modify.
We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.
Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).
This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.
Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.
Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.
(emphasis is mine)
It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.
Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:
handle multiple types of authentication providers
provide a normalized view of the user profile to downstream resource servers
provide the access tokens that can be used by your client application to make authorized requests to your microservices