7:12 a.m.
At my company, we are building an application on top of microservices. We are struggling
with deciding how to handle authorization and authentication. We are thinking of going
down the path where we use OpenId Connect to authenticate the users, but when it comes to
authorization, we need some advice.
Let me explain how to solution works: A user can have different roles in different
departments, and the number of departments can exceed 200. In each department, the user
can have multiple roles. We understand that the recommended way of handling roles is to
put them in the token sent from the client to the server (JWT). But, we are worried that
this will make the token payload too big. As far as I know, a browser can hold headers up
to 5KB of data. In our case, this means around 50 departments with two roles
(uncompressed). The pros of doing it this way are that the user is authorized and
authenticated when he/she enters the microservice. The cons are, as I mentioned, the large
payload in the token.
We are also looking at a different option where we keep the JWT to a minimum (userid and
departmentid) and query Keycloak for the user rights on every request (maybe add some
caching mechanism with a short lifespan). This approach will generate a lot of request to
the authorization server.
What I'm looking for is some advice/experience of how others have solved this. I'm
happy to provide more information if needed.
To make it easier for you to give your advice, here are a short description of the two
choices:
1) Use JWT to handle authentication and authorization?
2) Keep JWT light and make requests to the authorization server in every microservice?
Cheers,
Paul
11:03 a.m.
New subject: How do you handle authorization and authentication in Microservices?
Another option is to do some of that policy stuff with OPA
https://www.openpolicyagent.org/
Thanks,
Kevin
________________________________________
From: keycloak-user-bounces(a)lists.jboss.org [keycloak-user-bounces(a)lists.jboss.org] on
behalf of Pål Fossmo [pal(a)sentinel.no]
Sent: Thursday, March 21, 2019 5:12 AM
To: keycloak-user(a)lists.jboss.org
Subject: [keycloak-user] How do you handle authorization and authentication in
Microservices?
At my company, we are building an application on top of microservices. We are struggling
with deciding how to handle authorization and authentication. We are thinking of going
down the path where we use OpenId Connect to authenticate the users, but when it comes to
authorization, we need some advice.
Let me explain how to solution works: A user can have different roles in different
departments, and the number of departments can exceed 200. In each department, the user
can have multiple roles. We understand that the recommended way of handling roles is to
put them in the token sent from the client to the server (JWT). But, we are worried that
this will make the token payload too big. As far as I know, a browser can hold headers up
to 5KB of data. In our case, this means around 50 departments with two roles
(uncompressed). The pros of doing it this way are that the user is authorized and
authenticated when he/she enters the microservice. The cons are, as I mentioned, the large
payload in the token.
We are also looking at a different option where we keep the JWT to a minimum (userid and
departmentid) and query Keycloak for the user rights on every request (maybe add some
caching mechanism with a short lifespan). This approach will generate a lot of request to
the authorization server.
What I'm looking for is some advice/experience of how others have solved this. I'm
happy to provide more information if needed.
To make it easier for you to give your advice, here are a short description of the two
choices:
1) Use JWT to handle authentication and authorization?
2) Keep JWT light and make requests to the authorization server in every microservice?
Cheers,
Paul
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
5:37 a.m.
OPA is a great tool. And generic enough to cover different use cases.
But I'm wondering how it may become complex when you start to duplicate
your security aspects such as roles, groups, etc, in your policies. Besides
how it behaves when you need to integrate with identity sources such as
LDAP and databases to fetch information that you may need in your policies.
Back to your question, I would suggest you to take a look at Keycloak
Authorization Services feature set. It basically provides a PAP, PDP in
addition to policy enforcers for different platforms such as JEE, Spring
Boot, NodeJS and JS. It is fully based on token based authorization where
permissions are carried by tokens to their respective audiences. It is also
based on resource-based authorization where access control is based on the
resources (and their respective scopes) you are protecting. It is a more
flexible model since you don't need to rely on specific roles or groups but
the real thing you are protecting.
Em qui, 21 de mar de 2019 17:05, Fox, Kevin M <Kevin.Fox(a)pnnl.gov> escreveu:
Another option is to do some of that policy stuff with OPA
https://www.openpolicyagent.org/
Thanks,
Kevin
________________________________________
From: keycloak-user-bounces(a)lists.jboss.org [
keycloak-user-bounces(a)lists.jboss.org] on behalf of Pål Fossmo [
pal(a)sentinel.no]
Sent: Thursday, March 21, 2019 5:12 AM
To: keycloak-user(a)lists.jboss.org
Subject: [keycloak-user] How do you handle authorization and
authentication in Microservices?
At my company, we are building an application on top of microservices. We
are struggling with deciding how to handle authorization and
authentication. We are thinking of going down the path where we use OpenId
Connect to authenticate the users, but when it comes to authorization, we
need some advice.
Let me explain how to solution works: A user can have different roles in
different departments, and the number of departments can exceed 200. In
each department, the user can have multiple roles. We understand that the
recommended way of handling roles is to put them in the token sent from the
client to the server (JWT). But, we are worried that this will make the
token payload too big. As far as I know, a browser can hold headers up to
5KB of data. In our case, this means around 50 departments with two roles
(uncompressed). The pros of doing it this way are that the user is
authorized and authenticated when he/she enters the microservice. The cons
are, as I mentioned, the large payload in the token.
We are also looking at a different option where we keep the JWT to a
minimum (userid and departmentid) and query Keycloak for the user rights on
every request (maybe add some caching mechanism with a short lifespan).
This approach will generate a lot of request to the authorization server.
What I'm looking for is some advice/experience of how others have solved
this. I'm happy to provide more information if needed.
To make it easier for you to give your advice, here are a short
description of the two choices:
1) Use JWT to handle authentication and authorization?
2) Keep JWT light and make requests to the authorization server in every
microservice?
Cheers,
Paul
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:38 a.m.
Hi,
Have you considered using a RPT ?
https://www.keycloak.org/docs/latest/authorization_services/index.html#_s...
Basically it's an access token that contains also the authz permissions and
one permission could contains all the required roles (
https://www.keycloak.org/docs/latest/authorization_services/index.html#_p...
)
Then, in your client you remove the client scope "roles" so that their are
not added to your token and you end up with a really small token. The
service receiving the RPT token will be able to check "offline" if the
token has the permission (the service will retrieve at startup all the
permissions).
On Thu, Mar 21, 2019 at 1:15 PM Pål Fossmo <pal(a)sentinel.no> wrote:
At my company, we are building an application on top of
microservices. We
are struggling with deciding how to handle authorization and
authentication. We are thinking of going down the path where we use OpenId
Connect to authenticate the users, but when it comes to authorization, we
need some advice.
Let me explain how to solution works: A user can have different roles in
different departments, and the number of departments can exceed 200. In
each department, the user can have multiple roles. We understand that the
recommended way of handling roles is to put them in the token sent from the
client to the server (JWT). But, we are worried that this will make the
token payload too big. As far as I know, a browser can hold headers up to
5KB of data. In our case, this means around 50 departments with two roles
(uncompressed). The pros of doing it this way are that the user is
authorized and authenticated when he/she enters the microservice. The cons
are, as I mentioned, the large payload in the token.
We are also looking at a different option where we keep the JWT to a
minimum (userid and departmentid) and query Keycloak for the user rights on
every request (maybe add some caching mechanism with a short lifespan).
This approach will generate a lot of request to the authorization server.
What I'm looking for is some advice/experience of how others have solved
this. I'm happy to provide more information if needed.
To make it easier for you to give your advice, here are a short
description of the two choices:
1) Use JWT to handle authentication and authorization?
2) Keep JWT light and make requests to the authorization server in every
microservice?
Cheers,
Paul
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2119
days inactive
2120
days old
3 comments
4 participants
participants (4)
-
Fox, Kevin M -
Pedro Igor Silva -
Pål Fossmo -
Sebastien Blanc