[keycloak-dev] Application Initiated Actions

[Stian Thorgersen]

On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at 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.


>
>
>>
>> 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.
>>
>
> 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.


>
>
>>
>> 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
>>>>>>
>>>>>