[keycloak-dev] Application Initiated Actions

Stian Thorgersen sthorger at redhat.com
Wed Mar 20 11:27:51 EDT 2019 

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.


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


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

More information about the keycloak-dev mailing list