I'm still not seeing a concrete proposal from you and as I see it trying to
have AIA solve step-up and claims gathering is a complete broken idea and
will just result in it being overly complex to implement and use.
On Thu, 21 Mar 2019 at 13:05, Pedro Igor Silva <psilva(a)redhat.com> 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.
Not needed for the use-case I mentioned. Besides if the action makes
additional information available about the user that can be mapped into the
token with mappers and would be available in the updated tokens the app
receives after the action has been completed.
* 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 ?
Using this for step-up is just completely broken idea. Step-up
authentication is simple. Application requests level=0 initially, Keycloak
authenticates user to level=1, later application requests level=1, Keycloak
authenticates to level=1. The application should not have to ask for a
specific action to be done to step the authentication up. It's up to
Keycloak and how the user is configured to take it to the level the app
wants.
AIA != Step-up authentication
* 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.
Endpoint I'm using for AIA is the auth endpoint. It's not a new endpoint,
just one query parameter added. It's asking for a specific action to be
performed (register OTP), not asking for additional claims (I need DOB).
On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger(a)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> wrote:
>
>>
>>
>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger(a)redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen
<sthorger(a)redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva
<psilva(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen
<sthorger(a)redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva
<psilva(a)redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>>>>>> sthorger(a)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> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva
<psilva(a)redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian
Thorgersen <
>>>>>>>>>>> sthorger(a)redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor
Silva <
>>>>>>>>>>>> psilva(a)redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian
Thorgersen <
>>>>>>>>>>>>> sthorger(a)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> 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>
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>
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> 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> 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>
>>>>>>>>>>>>>>>>>> > 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
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>>>>>> keycloak-dev
mailing list
>>>>>>>>>>>>>>>>>>
keycloak-dev(a)lists.jboss.org
>>>>>>>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>