[keycloak-user] How do you handle authorization and authentication in Microservices?

[Pedro Igor Silva]

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 at 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 at lists.jboss.org [
> keycloak-user-bounces at lists.jboss.org] on behalf of Pål Fossmo [
> pal at sentinel.no]
> Sent: Thursday, March 21, 2019 5:12 AM
> To: keycloak-user at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>