[keycloak-dev] Application Initiated Actions

[Pedro Igor Silva]

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
>