To authenticate the client, why don't we just
require id_token_hint to
be included?
We would require the ID token to be issued to the client trying to
initiate the action and also be associated with the current session.
I'd say we don't need to finely control what clients can do what at
least not for now. Client should have scope on the manage_account role
and that's enough for now.
This assumes that client is authenticated before action is triggered.
Don't we want also a possibility to trigger this "Application Initiated
Actions" for cases when user is not yet authenticated? For example if I
have web application, which will be something like "Web Email client", I
want to ensure that user always has email verified before he is
redirected to my application as authenticated. So I may want to trigger
OIDC flow with "kc_action" even before user is authenticated.
Will be also nice for the "Terms and Conditions" actions as the "Terms
and Conditions" pages are often client specific, so our current approach
with generic "Terms and Conditions" action is likely not so nice and
requires that many application implements some equivalent of
app-specific "Terms and Conditions" page on their side rather than rely
on Keycloak. But with those "Application Initiated Actions" we can
improve on here.
Marek
On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
I am sorry to join this so late.
My concern is, that in the design, it was mentioned that
consent will be
always required from the user. I understand that this
simplifies the
flow as it's more secure and not need to authenticate the client.
However from the usability perspective, it doesn't look so
nice to me.
For example assume that in the application, the user just
clicked on the
button "Link my account with Facebook" . Then after login with
Facebook,
he will see another splash screen like "Application XY wants
to link
your account with Facebook", which he needs to confirm. It may be
especially bad for usability in this case with linking social
accounts,
as user may see one splash screen shown by Facebook "Application
keycloak wants to access your Facebook profile and email" and
then
immediately another splash screen shown by Keycloak
"Application Foo
wants to link your account with Facebook" .
Maybe I am wrong, but my guess is, that our users will very
quickly come
with requirement "Can I ommit to show the splash screen?" . It
is bit
similar to the "Consent Required" switch, which I guess most
people have
OFF for their clients. So IMO I would rather count with this
from the
beginning and count with the fact, that we will need to ommit
consent
screen and hence verify client.
With regards to this, It seems that we may need also to
specify if
client is:
- Allowed to initiate action
- Allowed to initate action with the consent required
- Allowed to initate action with no-consent required
Maybe the "Consent required" switch can be on instead on the
action
itself, but the will still need to restrict if client is
allowed or not
to perform the action.
I can see your point for linking to external IdP.
However, for everything else the actions are requesting a user to
enter information before something happens. I.e. registering
WebAuthn device, update password, etc.. All require the user to
first fill in the form.
With regards to the flow, I suggest that KC will require full
OIDC/OAuth2 flow. In other words, when KC redirects back to
the client,
the client will be required to send code-to-token request. And
the
action (EG. Keycloak user linked with Facebook) is done
*after* the
whole flow (including code-to-token flow) is finished. That
should be
sufficient to verify the client and at the same time, it will
allow us
to add some more things to tokens (EG. some facebook details)
. Downside
is, that it will be harder to implement though as the SPI will
likely
need another callback after code-to-token flow to "finish" the
action...
I don't think I understand, because if you are proposing what I'm
thinking it sounds awkward. Can you list the flow?
Last thing, I was thinking about using "scope" parameter to
reference
those actions instead of have proprietary "kc_action" thing.
The we
don't need any extensions of OIDC. It may simplify things like
consents
etc. Also client will be able to have something similar like
we have in
"Client Scopes" tab - the list of action, which he is allowed to
initiate. But I am not sure about this last point and maybe
it's better
to keep things separated...
I'm not convinced using scope param makes sense. It just doesn't
fit in my mental model.
Marek
On 21/03/2019 14:07, Pedro Igor Silva wrote:
> Sure, I'm not against the initial design/scope. Just tried
to make comments
> about other aspects that, to me, are related or how it can
be leveraged to
> also achieve other things.
>
> So, what Stian plans mentioned in one of his replies is fine
for me.
>
> On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert
<ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote:
>
>> Pedro,
>>
>> My only concern is getting this nailed down so we can move
forward with
>> the new account console.
>>
>> It sounds like Stian's proposal is simpler, but covers
fewer use cases.
>> Is that correct?
>>
>> Would it be practical to implement Stian's plan and then
implement your
>> proposal at a later date?
>>
>> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>>> In addition to everything you said.
>>>
>>> * It is not only about making changes to account, but
updating tokens
>> with
>>> information from required actions, which not necessarily
need to be
>>> persisted.
>>>
>>> * For back-end applications, we could also associate these
required
>> actions
>>> with scopes. If we could have a required action as
"Re-authenticate" or
>>> "Provide 2nd factor", that would also help with step-up
authentication.
>> As
>>> an alternative to OIDC acr related parameters/claims. I
don't think it
>>> makes sense to bring to the client concerns that are
really tied to the
>>> scopes of a resource server. As I said, clients should ask
for scopes and
>>> Keycloak should do whatever is necessary to grant these
(via consent, via
>>> additional steps/actions). Consider what you mentioned at
the end of your
>>> design document at "Require Re-Authentication".
Couldn't
we leverage AIA
>>> for step-up and ask the user for a more stronger credential ?
>>>
>>> * Claims gathering flow is simple. The Keycloak server
would return the
>>> endpoint to where the client should redirect the user.
After obtaining
>>> information from the user, Keycloak would issue a ticket
(instead of
>> code).
>>> The endpoint returned by Keycloak would contain the action
associated
>> with
>>> a resource. The endpoint could be the same as what you are
using for AIA.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen
<sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
>>> wrote:
>>>
>>>> Pedro,
>>>>
>>>> I really don't understand what your points are and what
you propose we
>> do
>>>> here.
>>>>
>>>> The use-case we're addressing is the following:
>>>>
>>>> As a user I would like to initiate an action associated
with my account
>>>> through a front-end application so that I can make
changes to my
>> account,
>>>> for example to register a WebAuthn security key with my
account.
>>>>
>>>> Further, we want an action to be implemented once and
re-usable in
>>>> login/registration flows as well as from applications
managing user
>>>> accounts, incuding our new account console. That means
our new account
>>>> console needs to be able to invoke an action in the login
flow,
>> otherwise
>>>> we would have to implement actions as react/rest also.
>>>>
>>>> Now the solution I have proposed is simple. It allows an
application to
>>>> request an action being invoked after the user has
authenticated. Think
>> of
>>>> it as a "required action" on-demand. It can be
implemented with a few
>> lines
>>>> of code and easily tested. It is very easy to use as it
just means
>> adding
>>>> an extra query param to the login flows, which makes it
very easy to use
>>>> both for confidential and non-confidential clients.
>>>>
>>>> It is not trying to cover claims gathering use-case from
UMA. I see no
>>>> connection to this and step-up authentication. These both
already have
>>>> clearly defined protocols. Neither can be used to address
the above
>>>> use-case.
>>>>
>>>> So please come with a concrete proposal as I have no clue
what your
>>>> objections are.
>>>>
>>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva
<psilva(a)redhat.com <mailto:psilva@redhat.com>>
>> wrote:
>>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen
<sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
>>>>> wrote:
>>>>>
>>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva
<psilva(a)redhat.com <mailto:psilva@redhat.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen
<
>> sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva
<psilva(a)redhat.com <mailto:psilva@redhat.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian
Thorgersen <
>> sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor
Silva
<psilva(a)redhat.com <mailto:psilva@redhat.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM
Stian Thorgersen <
>>>>>>>>>>> sthorger(a)redhat.com
<mailto:sthorger@redhat.com>>
wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Is it this stuff you're
thinking about:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>
https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi...
>>>>>>>>>>>> From that it does a get
including the ticket as
a query
>> parameter.
>>>>>>>>>>>> I don't like the idea of
sending tickets as query
params as
>> they could be
>>>>>>>>>>>> logged. For the application
initiated action it
would have to
>> be an ID
>>>>>>>>>>>> token sent as the ticket. Or as
I mentioned
before perhaps we
>> have a way of
>>>>>>>>>>>> creating a ticket that can only
be used to
initiate an action.
>>>>>>>>>>>>
>>>>>>>>>>> Why you need to send the id token if
the client
already got an id
>>>>>>>>>>> token and, considering browser flow,
there is a
cookie that can
>> be used by
>>>>>>>>>>> Keycloak to identify the client/user
?
>>>>>>>>>>>
>>>>>>>>>> Cookie doesn't authenticate the
client, only the user.
>>>>>>>>>>
>>>>>>>>> But the identity cookie has the user session
and
from it we can
>> check
>>>>>>>>> whether or not the client initiating the
action
(client_id) has a
>>>>>>>>> authenticated client session, no ?
>>>>>>>>>
>>>>>>>> That only proves that the client_id belongs to
a
client that has
>>>>>>>> obtained a token. It doesn't authenticate
the client
in any way.
>>>>>>>>
>>>>>>>> Q- Why is authentication of the client required?
IMO
it is not
>>>>>>>> required.
>>>>>>>>
>>>>>>> Sure, but the client obtained token and is
authenticated, thus acting
>>>>>>> on behalf of the user. If the client is already
acting
on behalf of
>> a user,
>>>>>>> we don't need to authenticate it.
>>>>>>>
>>>>>> That's not correct. All we know is that a client
with
the same
>> client_id
>>>>>> has obtained a token. Anyone can use the same client_id
to initiate an
>>>>>> action.
>>>>>>
>>>>>>
>>>>>>>>>>>> Perhaps what we could do is:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. By default any application
can initiate an action
>>>>>>>>>>>> 1.1. To initiate an action
there's no need for a
ticket of any
>>>>>>>>>>>> sort, just a regular oauth flow
>>>>>>>>>>>> 2. Later add support if demand
to limit what
applications can
>>>>>>>>>>>> initiate actions
>>>>>>>>>>>> 2.1 Same as before if the action
being initiated
is open for
>>>>>>>>>>>> everyone then no need for a
ticket
>>>>>>>>>>>> 2.2 If the action being
initiated is only
permitted by some
>>>>>>>>>>>> applications we would need some
form of
authentication.
>>>>>>>>>>>>
>>>>>>>>>>>> For 2.2 I have 3 suggestions in
mind:
>>>>>>>>>>>>
>>>>>>>>>>>> a. Just include id_token as a
ticket query param
like UMA claim
>>>>>>>>>>>> redirect does
>>>>>>>>>>>> b. Add support to obtain an
initiate action
ticket from a
>> endpoint
>>>>>>>>>>>> using an id token as bearer
token
>>>>>>>>>>>> c. Add a note into client
session with a initiate
action ticket
>>>>>>>>>>>> for clients that can initiate
actions and map
this into the id
>> token.
>>>>>>>>>>> Not sure ...
>>>>>>>>>>>
>>>>>>>>>>> If you think about it, the part
interested in
obtaining the
>> claims
>>>>>>>>>>> after an action is completed is not
the client but
the audience
>> of the
>>>>>>>>>>> token, the resource server. In this
case, the UMA
approach seems
>> more
>>>>>>>>>>> appropriate because the resource
server is in
control about what
>> actions
>>>>>>>>>>> the client should initiate in order
to fulfill the
constraints
>> imposed by
>>>>>>>>>>> the resource server to access its
protected
resources. Where
>> these
>>>>>>>>>>> constraints could be a DOB in the
token or a
higher security
>> level.
>>>>>>>>>>> The app initiating actions in the
server is not
the goal, but the
>>>>>>>>>>> tool to obtain additional claims
from the server ...
>>>>>>>>>>>
>>>>>>>>>>> However, for some applications
acting as both
client and resource
>>>>>>>>>>> server (e.g.: a monolithic jee) can
avoid all the
ticket dance
>> and just
>>>>>>>>>>> redirect the user to the server as
you pointed out
in 1.
>>>>>>>>>>>
>>>>>>>>>> Perhaps there's a case for that, but
that would be
claims
>> gathering,
>>>>>>>>>> not application initiated actions.
>>>>>>>>>>
>>>>>>>>>> Application initiated actions are more a
tool for
folks to add
>>>>>>>>>> actions for the user account into their
own GUIs,
and as such
>> should be a
>>>>>>>>>> simple protocol. OAuth incremental
scopes for
example doesn't
>> have any
>>>>>>>>>> flows between app and service, but
rather just
allows the app to
>> get the
>>>>>>>>>> scopes it out of bounds knows it needs
for specific
actions.
>>>>>>>>>>
>>>>>>>>> I think claims gathering and AIA are pretty
much the
same thing.
>> Both
>>>>>>>>> are querying the user for additional
information.
Despite if you
>> are
>>>>>>>>> initiating an action to request user's
DOB or update
a password,
>> they are
>>>>>>>>> steps that the user must perform in order to
enrich
its security
>> context
>>>>>>>>> and be able to continue using both client
and
resource server.
>>>>>>>>>
>>>>>>>>> The point I'm trying to make is that AIA
can solve
other problems
>>>>>>>>> too. You would still solve the original
problem from
your design
>> document
>>>>>>>>> as defined in the motivation section. While
you
would also help
>> with
>>>>>>>>> step-up authentication and UMA claims
gathering.
Another point is
>> related
>>>>>>>>> to the party interested in the action. Is it
the
client or the
>> resource
>>>>>>>>> server (the API)?
>>>>>>>>>
>>>>>>>>> If the client (which honestly I don't
see much use
as most apps
>> seem
>>>>>>>>> to be a combination of front-end + back-end,
where the
>> functionality is
>>>>>>>>> provided by the back-end and protected by a
bearer
token) then you
>> may just
>>>>>>>>> consider passing the "kc_action"
parameter and have
the action
>> initiated.
>>>>>>>>> If the resource server, you could associate
the
required actions
>> with
>>>>>>>>> the scopes. So when a client requests a
specific
scope, Keycloak
>> will start
>>>>>>>>> the action(s) and query the user for some
information prior to
>> issuing the
>>>>>>>>> access token.
>>>>>>>>>
>>>>>>>>> Still, if the resource server, the resource
server
could respond to
>>>>>>>>> the client (e.g: UMA flow) indicating that
it needs
more info,
>> then the
>>>>>>>>> client will just redirect the user to the
location
provided in the
>> response
>>>>>>>>> to initiate the actions.
>>>>>>>>>
>>>>>>>> I don't understand what your point is or
what you are
proposing
>> here.
>>>>>>> And I do understand your point of view. I just
think
that it can do
>>>>>>> much more than address new account management
console
requirements.
>>>>>>>
>>>>>>> Based on your design document, I understand what
you
described in the
>>>>>>> Motivation section. But again, instead of
considering
the "two
>> things" that
>>>>>>> originated the idea behind AIA, I think we can take
the opportunity
>> and do
>>>>>>> much more. As they seem related to me. Especially
after your DOB
>> example.
>>>>>> I don't see the additional use-cases you are
mentioning
as related at
>>>>>> all.
>>>>>>
>>>>> How it is not related ? The audience of the information
gathered during
>>>>> the AIA does impact where the token with the information
will be used.
>> If I
>>>>> need a DOB to access some page in my front-end, this is
one thing. If I
>>>>> need DOB to access some resource protected by a resource
server it is
>>>>> another thing. Both require tokens with different
audiences, the former
>>>>> will probably be an ID Token where the latter the access
token.
>>>>>
>>>>> In OAuth2 the scopes represent the permissions to access
protected
>>>>> resources. Thus, it does make sense to have required
actions that can
>>>>> challenge a user when requesting scopes. Considering
your DOB example,
>> if
>>>>> my client wants to access resource /api/age/check why
you want the
>> client
>>>>> to request kc_action=dob if the scope "dob" is
what he
needs to access
>> the
>>>>> API ? Otherwise, you are making the client aware of
things that are
>> really
>>>>> related to the resource server. It is OK the client ask
for scope
>> "age", it
>>>>> is how OAuth2 authorization model works.
>>>>>
>>>>> UMA leverages OAuth2 in a way that the permission ticket
makes the
>> client
>>>>> really dumb about what it needs to access protected
resources. With
>> UMA,
>>>>> the client will just receive a ticket and with that
ticket it can
>> perform
>>>>> the necessary actions to make a successful authorization
request to the
>>>>> server.
>>>>>
>>>>>
>>>>>> * Step-up authentication has already clear parameters
in OIDC/OAuth to
>>>>>> request high level of authentication. On the
implementation side it's
>> about
>>>>>> invoking additional parts of the authentication flow,
not to initiate
>> an
>>>>>> required action that has nothing to do with the
authentication flow.
>>>>>>
>>>>> Can we consider a required action as a prompt for 2nd
factor, for
>>>>> instance ?
>>>>>
>>>>>
>>>>>> * Claims gathering in UMA is about asking the user for
additional
>>>>>> claims. AIA can be used as a poor-mans workaround to
lack of claims
>>>>>> gathering, but end of the day it's completely
different. AIA will
>> allow an
>>>>>> app to invoke the action update_DOB, while claims
gaterhing will
>> allow the
>>>>>> application to request the claim DOB.
>>>>>>
>>>>> Not sure, if the difference is due to updating a piece
of info, both
>>>>> flows request the user for the info. Is just a matter of
updating or
>> not
>>>>> updating the info.
>>>>>
>>>>>
>>>>>> I don't see what additional things we need to
consider
for something
>>>>>> that is in the end very simple and can be implemented
in a couple
>> hours
>>>>>> including tests if we don't try to make it more
complicated.
>>>>>>
>>>>>>
>>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19,
Stian Thorgersen <
>> sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39,
Pedro Igor Silva <
>> psilva(a)redhat.com <mailto:psilva@redhat.com>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at
3:45 PM Stian Thorgersen <
>>>>>>>>>>>>>> sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, 6 Mar 2019
at 17:39, Pedro Igor Silva <
>>>>>>>>>>>>>>> psilva(a)redhat.com
<mailto:psilva@redhat.com>>
wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Mar 6,
2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>
sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why do you
think
authentication/authorization is required?
>>>>>>>>>>>>>>>>> The user
will be prompted before making an
action and it's
>> an action they
>>>>>>>>>>>>>>>>> do against
RH-SSO and not automatically
visible/exposed to
>> the client.
>>>>>>>>>>>>>>>> The client is
making the request and even
though the user is
>>>>>>>>>>>>>>>> at the Keycloak
server to perform the action,
admins may
>> want to restrict
>>>>>>>>>>>>>>>> which clients
are allowed to perform such
actions. That is
>> what I mean by
>>>>>>>>>>>>>>>> some level of
authorization.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You could even
consider not authenticating
the client at
>> all,
>>>>>>>>>>>>>>>> but still allow
admins to enforce which
clients should be
>> allowed to
>>>>>>>>>>>>>>>> initiate actions
on the server.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can't see how
enforcing which clients is
allowed to
>> initiate
>>>>>>>>>>>>>>> actions will work
without authenticating the
client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe the word
authenticate seems too much to
what we are
>>>>>>>>>>>>>> discussing. This is more
a validation of the
client making
>> the request.
>>>>>>>>>>>>>> Considering that,
I'm saying that you could
just rely on
>> client_id and
>>>>>>>>>>>>>> redirect uris (the
client is already
authenticated and if
>> doing browser
>>>>>>>>>>>>>> authentication the
cookie is already present)
and possibly
>> add some level
>>>>>>>>>>>>>> of authorization to
enforce which clients can
perform actions
>> (instead of
>>>>>>>>>>>>>> just relying on the
authenticated session).
Redirect uris are
>> really
>>>>>>>>>>>>>> important because you
want to make sure the
redirect uri is
>> valid before
>>>>>>>>>>>>>> redirecting the user.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> The plan is to use the auth
endpoint, so
client_id and
>>>>>>>>>>>>> redirect_uris are already
being checked. It's
just a standard
>> OAuth flow.
>>>>>>>>>>>>> IMO that's fine as long
as there's no need to
limit what
>> clients
>>>>>>>>>>>>> can initiate actions. If
that's needed then we
need something
>> more
>>>>>>>>>>>>> complicated that properly
authenticates the
client, as anyone
>> could just
>>>>>>>>>>>>> use the client_id and
redirect_uri from a different
>> application to get the
>>>>>>>>>>>>> action initiated (although
wouldn't then have
the user
>> redirected back to
>>>>>>>>>>>>> the app of course).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, 6
Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>>>>>>>
psilva(a)redhat.com
<mailto:psilva@redhat.com>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> One way
is to follow authorization code
constraints like
>>>>>>>>>>>>>>>>>> checking
the client_id and redirect_uri
(assuming the
>> user will be
>>>>>>>>>>>>>>>>>>
redirected back after the action
completes). But still,
>> we could also add
>>>>>>>>>>>>>>>>>> some
level authorization.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
authorization code constraints doesn't work
as anyone can
>>>>>>>>>>>>>>>>> just use the
client_id and redirect_uri from
a different
>> client.
>>>>>>>>>>>>>>>> I may be missing
the whole flow. I would ask
then what
>> happens
>>>>>>>>>>>>>>>> after the user
performs an action. Is he/her
redirected
>> back to the client
>>>>>>>>>>>>>>>> ? If so,
client_id + redirect_uri do work to
make sure that
>> the client is
>>>>>>>>>>>>>>>> known and that
the user will be redirected
back to a valid
>> URI.
>>>>>>>>>>>>>>> It's just a
standard OAuth flow, so app would
get new tokens.
>>>>>>>>>>>>>>> Say the user
hasn't entered a DOB in the
profile and the
>> client wants that,
>>>>>>>>>>>>>>> then they can
request the user to enter a DOB,
which would
>> then result in
>>>>>>>>>>>>>>> the DOB being
available in the token.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This flow seems very
closely related with the
Claims Gathering
>>>>>>>>>>>>>> Flow from UMA specs. We
could probably review
what is there
>> and see if it
>>>>>>>>>>>>>> can help to solve this
problem of app initiated
actions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Go for it ;)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Only viable
option I can think of is to add
an endpoint
>> where
>>>>>>>>>>>>>>>>> the
application can request a token to
initate an action.
>> So flow would be:
>>>>>>>>>>>>>>>>> 1. App sends
POST { action: <action-id> }
with ID Token as
>>>>>>>>>>>>>>>>> bearer token
in header to a new endpoint.
This would
>> return a single use
>>>>>>>>>>>>>>>>> token.
>>>>>>>>>>>>>>>>> 2. App can
now do the redirect protocol as
before, but
>>>>>>>>>>>>>>>>> instead of
"?action=<action>" they would do
>> "?action-token=<action token>"
>>>>>>>>>>>>>>>>> In the JS
adapter we can add a
action(actionId) function
>> that
>>>>>>>>>>>>>>>>> would get
the action token before
redirecting the user.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Not sure
what you mean about level
authorization.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed,
Mar 6, 2019 at 10:25 AM Stian
Thorgersen <
>>>>>>>>>>>>>>>>>>
sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The
issue is more around how to
authenticate clients and
>>>>>>>>>>>>>>>>>>> also
the fact that clients wanting to
initiate actions
>> may be public
>>>>>>>>>>>>>>>>>>>
clients. We also don't want to invent a
new protocol for
>> this, but rather
>>>>>>>>>>>>>>>>>>> just
rely on the OIDC flows.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So
with those constraints how would you
authenticate the
>>>>>>>>>>>>>>>>>>>
client?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On
Wed, 6 Mar 2019 at 14:23, Pedro Igor
Silva <
>>>>>>>>>>>>>>>>>>>
psilva(a)redhat.com
<mailto:psilva@redhat.com>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
IMO, we should have some level of
authorization for
>>>>>>>>>>>>>>>>>>>>
clients initiating an action. This could
be as simple
>> as leveraging authz
>>>>>>>>>>>>>>>>>>>>
in order to define white/black lists of
clients.
>> Similar to what a KC
>>>>>>>>>>>>>>>>>>>>
extension does in regards to authentication.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
On Tue, Mar 5, 2019 at 3:15 PM Stian
Thorgersen <
>>>>>>>>>>>>>>>>>>>>
sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Was
hoping for some more feedback from
the list on this
>>>>>>>>>>>>>>>>>>>>> one.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
Especially around not having any
authentication of the
>>>>>>>>>>>>>>>>>>>>>
clients wanting to
>>>>>>>>>>>>>>>>>>>>>
initiate an action. I feel reasonable
comfortable about
>>>>>>>>>>>>>>>>>>>>> not
securing it and
>>>>>>>>>>>>>>>>>>>>>
requiring actions to prompt the user
before doing
>>>>>>>>>>>>>>>>>>>>>
anything, but welcome
>>>>>>>>>>>>>>>>>>>>>
others opinion on it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On
Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>>>>>>>>
pskopek(a)redhat.com
<mailto:pskopek@redhat.com>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
Since there is no "silent" application
initiated
>> action
>>>>>>>>>>>>>>>>>>>>>
(always
>>>>>>>>>>>>>>>>>>>>>>
prompts user) possible and actions are
predefined at
>>>>>>>>>>>>>>>>>>>>>
keycloak I see no
>>>>>>>>>>>>>>>>>>>>>>
need for the client/application
restriction mechanism.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
On Wed, Feb 27, 2019 at 4:23 PM Stian
Thorgersen <
>>>>>>>>>>>>>>>>>>>>>
sthorger(a)redhat.com
<mailto:sthorger@redhat.com>>
>>>>>>>>>>>>>>>>>>>>>>
wrote:
>>>>>>>>>>>>>>>>>>>>>>>
Keycloak currently has required
actions that are used
>>>>>>>>>>>>>>>>>>>>> to
prompt the user
>>>>>>>>>>>>>>>>>>>>>>
to
>>>>>>>>>>>>>>>>>>>>>>>
perform an action associated with
their account after
>>>>>>>>>>>>>>>>>>>>>
authenticating, but
>>>>>>>>>>>>>>>>>>>>>>>
prior to being redirected to the
application.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
Examples include: configure OTP,
update profile,
>>>>>>>>>>>>>>>>>>>>>
validate email, etc.
>>>>>>>>>>>>>>>>>>>>>>>
One issue here is these actions have
to be manually
>>>>>>>>>>>>>>>>>>>>>
registered with the
>>>>>>>>>>>>>>>>>>>>>>>
users account, but can not be initiated by
>>>>>>>>>>>>>>>>>>>>>
applications themselves. As an
>>>>>>>>>>>>>>>>>>>>>>>
example it may not be required by all
users to verify
>>>>>>>>>>>>>>>>>>>>> their
email, but
>>>>>>>>>>>>>>>>>>>>>>
only
>>>>>>>>>>>>>>>>>>>>>>>
when they use specific applications.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
Keycloak also needs to initiate
actions from the
>>>>>>>>>>>>>>>>>>>>>
account management
>>>>>>>>>>>>>>>>>>>>>>>
console. Examples: updating email
address should
>>>>>>>>>>>>>>>>>>>>>
require verifying the
>>>>>>>>>>>>>>>>>>>>>>>
email, configuring OTP, etc.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
With that in mind we are proposing to
introduce
>>>>>>>>>>>>>>>>>>>>>
Application Initiated
>>>>>>>>>>>>>>>>>>>>>>>
Actions. An Application Initiated
Action behind the
>>>>>>>>>>>>>>>>>>>>>
scenes is just a
>>>>>>>>>>>>>>>>>>>>>>>
Required Action, but it is initiated by an
>>>>>>>>>>>>>>>>>>>>>
application and depending on
>>>>>>>>>>>>>>>>>>>>>>
the
>>>>>>>>>>>>>>>>>>>>>>>
action may be optional for the user to
complete
>>>>>>>>>>>>>>>>>>>>>
(where the user can
>>>>>>>>>>>>>>>>>>>>>>
select
>>>>>>>>>>>>>>>>>>>>>>>
cancel which would return the user
back to the
>>>>>>>>>>>>>>>>>>>>>
application).
>>>>>>>>>>>>>>>>>>>>>>>
No Application Initiated Actions
should perform any
>>>>>>>>>>>>>>>>>>>>>
updates to the users
>>>>>>>>>>>>>>>>>>>>>>>
account without prompting the user
first. For example
>>>>>>>>>>>>>>>>>>>>> an
application
>>>>>>>>>>>>>>>>>>>>>>>
initiated action that is used to link
an existing
>>>>>>>>>>>>>>>>>>>>>
account to a social
>>>>>>>>>>>>>>>>>>>>>>>
provider should ask the user first if
they want to
>>>>>>>>>>>>>>>>>>>>> link
to the provider.
>>>>>>>>>>>>>>>>>>>>>>>
To make it easy for applications to
integrate these I
>>>>>>>>>>>>>>>>>>>>> would
like to
>>>>>>>>>>>>>>>>>>>>>>>
leverage the standard OAuth flows that
applications
>>>>>>>>>>>>>>>>>>>>> use
to authenticate
>>>>>>>>>>>>>>>>>>>>>>>
users. So to initiate verify-email
action the
>>>>>>>>>>>>>>>>>>>>>
application would redirect
>>>>>>>>>>>>>>>>>>>>>>
to
>>>>>>>>>>>>>>>>>>>>>>>
the authentication endpoint and add
kc_action=<action
>>>>>>>>>>>>>>>>>>>>>
alias> query
>>>>>>>>>>>>>>>>>>>>>>>
parameter.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
One open question I have right now is.
Assuming all
>>>>>>>>>>>>>>>>>>>>>
Application Initiated
>>>>>>>>>>>>>>>>>>>>>>>
Actions always prompt the user first
do we need to
>>>>>>>>>>>>>>>>>>>>> add
some mechanism in
>>>>>>>>>>>>>>>>>>>>>>>
place to restrict what
clients/applications are
>>>>>>>>>>>>>>>>>>>>>
permitted to initiate an
>>>>>>>>>>>>>>>>>>>>>>>
action? Requiring that would make it
harder to use
>>>>>>>>>>>>>>>>>>>>> for
applications.
>>>>>>>>>>>>>>>>>>>>>>>
One thing I would also like to add is
the ability for
>>>>>>>>>>>>>>>>>>>>> an
Application
>>>>>>>>>>>>>>>>>>>>>>>
Initiated Action to require the user to
>>>>>>>>>>>>>>>>>>>>>
re-authenticate prior to
>>>>>>>>>>>>>>>>>>>>>>
performing
>>>>>>>>>>>>>>>>>>>>>>>
the action. For example update
password should
>>>>>>>>>>>>>>>>>>>>>
require the user to enter
>>>>>>>>>>>>>>>>>>>>>>>
the current password, while verify
email should not
>>>>>>>>>>>>>>>>>>>>> (as
it simply sends
>>>>>>>>>>>>>>>>>>>>>>
an
>>>>>>>>>>>>>>>>>>>>>>>
email with a link to continue).
>>>>>>>>>>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>
keycloak-dev mailing list
>>>>>>>>>>>>>>>>>>>>>>>
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>>>>>>>>>>>>>>>>>>>>>
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>>>>>>>>>
keycloak-dev mailing list
>>>>>>>>>>>>>>>>>>>>>
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>>>>>>>>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev