[keycloak-dev] Application Initiated Actions

[Stian Thorgersen]

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.

On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at 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.

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 at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>