[keycloak-dev] Application Initiated Actions

[Pedro Igor Silva]

On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Is it this stuff you're thinking about:
>
> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>
> 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 ?


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


>
> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> 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 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.
>>>>
>>>
>>> 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 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
>>>>>>>>>>
>>>>>>>>>