[keycloak-user] Authorizing Backend Services

[Carsten Saathoff]

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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150615/99fdb591/attachment.html