<font size=2 face="sans-serif">Hi,</font>
<br>
<br><tt><font size=2>Stian Thorgersen <stian@redhat.com> wrote on
24/06/2015 15:00:18:<br>
<br>
> We'll be adding service accounts in the near future, that'll provide<br>
> a way for clients to obtain a token on behalf of themselves. There
<br>
> will be a special linked user to the client. Clients can obtain this<br>
> through the client credential grant (see oauth2 for more details)
<br>
> and use a secret or pub/priv keypair to authenticate.<br>
</font></tt>
<br><tt><font size=2>that sounds great.</font></tt>
<br><tt><font size=2> <br>
> For a client to get a token on behalf of a user the user will have
<br>
> to either enter username/pass in a cli and you'd use resource owner
<br>
> credential grant (again see oauth2 for more details) or you'd use
<br>
> the normal redirect based flow.<br>
> <br>
> For the above once we add offline tokens this will only be required
<br>
> as an initial setup as the "refresh token" will not expire
until the<br>
> user goes in and revokes access to the appliction. <br>
</font></tt>
<br><tt><font size=2>That's actually the initial setup that I would like
to avoid. If we talk about social websites this flow makes absolute sense,
as I as the user want to control what data can be accessed by external
services. However, in an enterprise application the user shouldn't be bothered
with single microservices IMO. Therefore, when I ask the user to authorise
some arbitrary backend service to access some data, the user will probably
be surprised or, even worse, confused.</font></tt>
<br>
<br><tt><font size=2>Currently I only see three possible solutions:</font></tt>
<br><tt><font size=2>1. Do it as you propose and implement the OAuth flow.</font></tt>
<br><tt><font size=2>2. Add some additional API and options to allow clients
to request access tokens on behalf of users (maybe with reduced privileges
only).</font></tt>
<br><tt><font size=2>3. Somehow let the service figure out the access rights
of the user, e.g. by using the admin API (haven't really checked whether
that would work at all).</font></tt>
<br>
<br><tt><font size=2>I don't like 3 because a) I don't want to provide
admin privileges to my services and b) I don't like the fact that authorisation
would work differently in that case. I definitely prefer 2 over 1, because
I think it will provide the best user experience. My hope was that there
is some other option to handle that use case that I wasn't aware of.</font></tt>
<br>
<br><tt><font size=2>As a general question, would such a feature fit into
keycloak, or is out of consideration because it is not standardized?</font></tt>
<br>
<br><tt><font size=2>best</font></tt>
<br>
<br><tt><font size=2>Carsten</font></tt>
<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>