5:23 p.m.
Hi,
we are currently struggling to find an elegant solution for the following
problem. We have a system consisting of a bunch of microservices. The UI
interacts with the system using an API Gateway. Authenticating the user is
done via OAuth using the password grant and probably using the implicit
grant in the future. While we initially planned to store user roles in
each microservice, we changed that approach to go for the token based
approach used by keycloak, i.e., we use the roles present in the access
token to determine the role of the user for a request. So far so good,
authentication works like a breeze and keycloak is also easy to use and
looks great.
However, besides the user facing processes (i.e. the user actually
interacting with the system via the UI), we also have offline processes.
E.g., a reporting service that needs to access data in other services in
order to generate a report once a day or a week. In these offline
service-to-service requests, we want to be able to enforce the same set of
access rules as for normal requests directly triggered by the user. In
other words, the reporting service would need an access token for the user
that contains the roles of the user. In order to obtain that access token,
however, either the user would need to be involved or we would need a
refresh token. Involving the user in a process that takes place in the
middle of the night is obviously not a viable solution, so I think we need
to authorize the user once somehow. But we are actually not sure how to
best do this. In an enterprise application it would be a bit uncommon to
pop up a "Please authorize Service X to access Service Y" window, when the
user doesn't really care about what services are involved. Furthermore,
it's also not absolutely clear how to best integrate this into a UI
anyway. So we are actually wondering, if this is right path anyway. How
are such cases are usually handled using keycloak? Is there a pattern or
any best practice? Am I completely on the wrong road and need to do
something completely different?
Are there any plans to extend keycloak with functionality that would ease
such scenarios? One idea we had was to allow for direct token generation
of backend services via some API and the means to configure what tokens
and roles are allowed by a service. In our problem above, I could imagine
that in keycloak there would be the possibility to allow the report
service to generate tokens with the GUEST role for all users for the data
service. Independently of the real role of the user, a token generated by
that means would only allow access with GUEST rights. Furthermore, the
report service would not be able to generate tokens for any other services
on its own. That would obviously be outside of OAuth and probably it
should be required to enable this feature explicitly, but I would greatly
ease such scenarios. Specifically, it would help in setting up a system
such that is secure without requiring the user to perform explicit grants
for services he shouldn't even know about.
Thanks and best regards
Carsten
--------------------------------------------------------------------------------------------------------------------------------------------
Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters |
Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff(a)kisters.de
| WWW: http://www.kisters.de
--------------------------------------------------------------------------------------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie
nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren
Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution
of the material in this e-mail is strictly forbidden.