<font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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?</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Thanks and best regards</font>
<br>
<br><font size=2 face="sans-serif">Carsten</font>
<br>
<br>
<hr>
<font size="3" face="Calibri,sans-serif">
Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany<br>Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers<br>Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff@kisters.de | WWW: http://www.kisters.de
</span>
<hr>
<font size="2" face="Calibri,sans-serif">
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. <br>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.
</font>