[keycloak-dev] Application Initiated Actions

[Pedro Igor Silva]

On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> 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 ?
>>>>
>>>
>>> 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.


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


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