How to manage/share jwt token between two Jhipster gateways when implementing Backends for Frontends pattern ?
Is a share db for the users of the two gateways will resolve this situation?
A simple approach is to share the JWT secret between your gateways and use different roles. I would not share the database as usually different gateways means different ways to authenticate.
Related
we are using konghq as an API gateway for one of our customers but we are very new to it and therefore don't know how to tackle this authentication issue.
We have to authenticate our services with a SAML token. Our micro services are behind kong which is running on an EC2. The authentication process should be an independent micro services which validates the token from the request and it’s contents against another system. Instead of a service it could also be some serverless function on a k8s cluster. We don't want to use a lambda to stay cloud agnostic.
We were previously using AWS API gateway and lambda authorizers to tackle the scenario. The authorizer validated the token and took care of the authentication process.
I searched all the Kong forums and google but couldn't find a SAML plugin. Most similar is the JWT plugin but it won't work for us.
Is there something similar in Kong or is there development on Kong involved? If yes, are there any existing plugin which are similar or any tutorials related.
All help is greatly appreciated.
Thanks
Oldfighter
I understand that keycloak has built-in clients and we add the users later on.
But in general, what is the difference between a client and a user in Keycloak?
According to the Keycloak documentation
User - Users are entities that are able to log into your system
Client - Clients are entities that can request Keycloak to authenticate a user. Most
often, clients are applications and services that want to use Keycloak to secure
themselves and provide a single sign-on solution. Clients can also be entities that
just want to request identity information or an access token so that they can
securely invoke other services on the network that are secured by Keycloak
In short words, not only for keycloak but for OAuth and OpenId Connect too, a client represents a resource which some users can access. The built-in clients for keycloak represent some resources for keycloak itself.
Clients and users are two completely different constructs in keycloak.
In plain English, client is an application. Example for an application could be a e.g. yelp.com or any mobile application. Client can be a simple REST API. Keycloak's built in clients are for keycloak internal use, But any user-defined application has to be registered as a client in keycloak.
Users are the one which authenticate via keycloak to gain access to these applications/clients. Users are stored in keycloak DB or any externally hosted LDAP but synced with keycloak.
What are good arguments in favor to use or not to use Keycloak behind Api gateway (Kong)?
There is a tradeoff to putting it behind the proxy: you will not be able to easily protect all of your services by applying the OIDC plugin on the global level. Instead, you will need to individually configure every service with its own OIDC plugin. This is because you will need at least one service that is not protected by the OIDC plugin so that user-agents can authenticate through that service. Unless you're planning to implement some other form of security on that service or need some other services that Kong can easily implement as requests pass through it, I don't see the point of putting Keycloak behind the proxy. That's not to say there aren't good reasons to do it, I'm just not aware of them.
I've set Keycloak up outside of the proxy, and have had good results. Here's what it looks like:
I'm writing a blog post about this set up now which I will release next week. I will try to remember to update my answer here when it is complete.
Edit
Links to blog:
Part 1,
Part 2
It is not good practice, in fact I would suggest to put it outside, in the DMZ. In this way that IDP can be leveraged by all APIs that you want to publish and authenticate using the API gateway. This is an example of applying such authentication flow with Keycloak: https://www.slideshare.net/YuichiNakamura10/implementing-security-requirements-for-banking-api-system-using-open-source-software-oss
Your concern might be then: how do I protect such a critical resource like an IDP authenticating all my services?
Reasonable concern which you can address by:
ensuring autoscaling of the IDP based on authentication request
configuring all the needed threat mitigation options on Keycloak (https://www.keycloak.org/docs/latest/server_admin/#password-guess-brute-force-attacks)
add a WAF in front of the IDP with feature such as DDOS prevention and Intelligent Threat Mitigation based on traffic patterns
IP or Domain whitelisting, if you know where all your customers are connecting from
restrict port exposure for the IDP
Kong is an API gateway that'll be in the "hot path" - in the request and response cycle of every API request. Kong is good at efficiently proxying lots of requests at very low latency.
Keycloak and other IAM offerings can integrate with Kong - but they aren't placed in the hot path. Keycloak is good at managing users and permissions and providing this information to systems like Kong, when requested.
Perhaps these links will be helpful https://github.com/ncarlier/kong-integration-samples and https://ncarlier.gitbooks.io/oss-api-management/content/howto-kong_with_keycloak.html
Is not a good practice, a good Enterprise API Gateway has the obligation to meet (or give you the access to customize) all the advanced authentication and authorization standards available in KEYCLOAK.
But in some circumstances, If you already have a API Gateway with a lot API´s configured (with transformation rules, route rules) and this Gateway can´t provide advanced features for authentication and authorization (ex. 2 factor authentication or Oauth2 authorization code/openId / SAML) and you need more security ASAP, go ahead while looking for a gateway that best meets your needs
we am trying to use open ID connect (OIDC) for authentication and authorization (AnA) for our micro-service architecture based on spring-cloud framework
As a part of requirement we want to achieve following:
Integrate (OIDC) with SSO Federation as a Identity provider which we are using federation to authenticate users (staff id)
How to customize access_token which in turn will be provided by a micro service (Authorization service)
I am looking at MITREid Connect as its based on spring framework and spring security
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server
As a resutl of that, all requests to our services have to go through (OIDC) for (AnA)
I also check on https://cloud.spring.io/spring-cloud-security/ as I understand the Zuul server will get an access_token to relay to proxied services. But our scenarios are different as we want to expose other micro-services to external parties as well so that we want to have secure our services.
Any advices is highly appreciated.
We are working on the development of micro services for our domain.
We have a requirement to secure the micro services using SAML.
I read through the SAML docs and see that there would an Identity provider to which we have register our application (SP) and also we should connect to IdP for authentication. I understand that we need to establish a circle of trust or federation between them.
I tried using the Spring Security SAML extension and SSOCircle.com as IdP for authentication using the sample application provided. I was able to successfully authenticate accordingly.
My question is, in a micro services architecture, we have multiple services. Since it is not a monolithic we cannot just add one service as a SP to the IdP.
That means every micro service I have say, employee, department,sales etc should also be added as a separate SP application in IdP.
I am not sure if that makes sense or actually possible to do so.
If anyone has worked on a similar architecture/development can you please provide your thoughts on the best way to approach the security of micro services from the point of authentication.
Thanks,
bstechie
Two ways to do this:
As you said, configure each micro-service as SP and each SP talk to IdP for SAML authentication.
This is suitable, if each micro-service has different set of users, groups and roles than others.
There could be multiple SPs, which admin need to maintain.
Consolidate and configure all micro-services to single SP at your domain (may be use Reverse Proxy Web-Server or Access Manager) and that single SP talk to IdP for SAML authentication.
This is suitable, if all micro-service has same set of users, groups and roles.
There could be only single SP that admin need to maintain.