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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)redhat.com&gt; >> > 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(a)lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >

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.

On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva(a)redhat.com&gt; 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.

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(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>> 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>> > 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(a)lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>

On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger(a)redhat.com&gt; 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.

> > On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva(a)redhat.com&gt; 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.

> > 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(a)redhat.com&gt; >> 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(a)redhat.com&gt; >>> 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(a)redhat.com&gt; >>>> 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(a)redhat.com&gt; >>>>> 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(a)redhat.com&gt; >>>>> > 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(a)lists.jboss.org >>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> > >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>

On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > >> >> >> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >> 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.

>> >> >>> >>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva(a)redhat.com&gt; >>> 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.

> > >> >> >>> >>> 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(a)redhat.com&gt; >>>> 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(a)redhat.com&gt; >>>>> 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(a)redhat.com&gt; >>>>>> 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(a)redhat.com&gt; >>>>>>> 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(a)redhat.com&gt; >>>>>>> > 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(a)lists.jboss.org >>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> > >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>>

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

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.

On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > >> >> >> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>>> 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(a)redhat.com&gt; >>>>> 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>> 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>> 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(a)redhat.com&gt; >>>>>>>>> > 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(a)lists.jboss.org >>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>> > >>>>>>>>> _______________________________________________ >>>>>>>>> keycloak-dev mailing list >>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>> >>>>>>>>

On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > > On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> Is it this stuff you're thinking about: >> >> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >> >> 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.

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

> > >> >> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>>>>> 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(a)redhat.com&gt; >>>>>>> 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>> 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>>>> 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(a)redhat.com&gt; >>>>>>>>>>> > 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(a)lists.jboss.org >>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>> >>>>>>>>>>

On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > > On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> >> >> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: >> >>> >>> >>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> Is it this stuff you're thinking about: >>>> >>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >>>> >>>> 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(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen < >>>>>>>> sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>> 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>>>>>> > 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(a)lists.jboss.org >>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>> >>>>>>>>>>>>

On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > > On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> >> >> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Is it this stuff you're thinking about: >>>>>> >>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >>>>>> >>>>>> 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. > That's not correct. All we know is that a client with the same client_id has obtained a token. Anyone can use the same client_id to initiate an action. > > >> >> >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> 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. > I don't see the additional use-cases you are mentioning as related at all.

* Step-up authentication has already clear parameters in OIDC/OAuth to request high level of authentication. On the implementation side it's about invoking additional parts of the authentication flow, not to initiate an required action that has nothing to do with the authentication flow.

* Claims gathering in UMA is about asking the user for additional claims. AIA can be used as a poor-mans workaround to lack of claims gathering, but end of the day it's completely different. AIA will allow an app to invoke the action update_DOB, while claims gaterhing will allow the application to request the claim DOB.

I don't see what additional things we need to consider for something that is in the end very simple and can be implemented in a couple hours including tests if we don't try to make it more complicated. > > >> >> >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen < >>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen < >>>>>>>>>> sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>>>>>>>> > 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(a)lists.jboss.org >>>>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>>>

Pedro, I really don't understand what your points are and what you propose we do here. The use-case we're addressing is the following: As a user I would like to initiate an action associated with my account through a front-end application so that I can make changes to my account, for example to register a WebAuthn security key with my account. Further, we want an action to be implemented once and re-usable in login/registration flows as well as from applications managing user accounts, incuding our new account console. That means our new account console needs to be able to invoke an action in the login flow, otherwise we would have to implement actions as react/rest also. Now the solution I have proposed is simple. It allows an application to request an action being invoked after the user has authenticated. Think of it as a "required action" on-demand. It can be implemented with a few lines of code and easily tested. It is very easy to use as it just means adding an extra query param to the login flows, which makes it very easy to use both for confidential and non-confidential clients. It is not trying to cover claims gathering use-case from UMA. I see no connection to this and step-up authentication. These both already have clearly defined protocols. Neither can be used to address the above use-case. So please come with a concrete proposal as I have no clue what your objections are. On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > > On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> >> >> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen < >>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> Is it this stuff you're thinking about: >>>>>>>> >>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >>>>>>>> >>>>>>>> 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. >>> >> >> That's not correct. All we know is that a client with the same client_id >> has obtained a token. Anyone can use the same client_id to initiate an >> action. >> >> >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 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. >>> >> >> I don't see the additional use-cases you are mentioning as related at >> all. >> > > How it is not related ? The audience of the information gathered during > the AIA does impact where the token with the information will be used. If I > need a DOB to access some page in my front-end, this is one thing. If I > need DOB to access some resource protected by a resource server it is > another thing. Both require tokens with different audiences, the former > will probably be an ID Token where the latter the access token. > > In OAuth2 the scopes represent the permissions to access protected > resources. Thus, it does make sense to have required actions that can > challenge a user when requesting scopes. Considering your DOB example, if > my client wants to access resource /api/age/check why you want the client > to request kc_action=dob if the scope "dob" is what he needs to access the > API ? Otherwise, you are making the client aware of things that are really > related to the resource server. It is OK the client ask for scope "age", it > is how OAuth2 authorization model works. > > UMA leverages OAuth2 in a way that the permission ticket makes the client > really dumb about what it needs to access protected resources. With UMA, > the client will just receive a ticket and with that ticket it can perform > the necessary actions to make a successful authorization request to the > server. > > >> >> * Step-up authentication has already clear parameters in OIDC/OAuth to >> request high level of authentication. On the implementation side it's about >> invoking additional parts of the authentication flow, not to initiate an >> required action that has nothing to do with the authentication flow. >> > > Can we consider a required action as a prompt for 2nd factor, for > instance ? > > >> >> * Claims gathering in UMA is about asking the user for additional >> claims. AIA can be used as a poor-mans workaround to lack of claims >> gathering, but end of the day it's completely different. AIA will allow an >> app to invoke the action update_DOB, while claims gaterhing will allow the >> application to request the claim DOB. >> > > Not sure, if the difference is due to updating a piece of info, both > flows request the user for the info. Is just a matter of updating or not > updating the info. > > >> >> I don't see what additional things we need to consider for something >> that is in the end very simple and can be implemented in a couple hours >> including tests if we don't try to make it more complicated. >> >> >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger(a)redhat.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen < >>>>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva < >>>>>>>>>>> psilva(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen < >>>>>>>>>>>> sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>>>>>>>>>> > 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(a)lists.jboss.org >>>>>>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>

Pedro, My only concern is getting this nailed down so we can move forward with the new account console. It sounds like Stian's proposal is simpler, but covers fewer use cases. Is that correct? Would it be practical to implement Stian's plan and then implement your proposal at a later date? On 3/21/2019 8:05 AM, Pedro Igor Silva wrote: > In addition to everything you said. > > * It is not only about making changes to account, but updating tokens with > information from required actions, which not necessarily need to be > persisted. > > * For back-end applications, we could also associate these required actions > with scopes. If we could have a required action as "Re-authenticate" or > "Provide 2nd factor", that would also help with step-up authentication. As > an alternative to OIDC acr related parameters/claims. I don't think it > makes sense to bring to the client concerns that are really tied to the > scopes of a resource server. As I said, clients should ask for scopes and > Keycloak should do whatever is necessary to grant these (via consent, via > additional steps/actions). Consider what you mentioned at the end of your > design document at "Require Re-Authentication". Couldn't we leverage AIA > for step-up and ask the user for a more stronger credential ? > > * Claims gathering flow is simple. The Keycloak server would return the > endpoint to where the client should redirect the user. After obtaining > information from the user, Keycloak would issue a ticket (instead of code). > The endpoint returned by Keycloak would contain the action associated with > a resource. The endpoint could be the same as what you are using for AIA. > > > > > > On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> Pedro, >> >> I really don't understand what your points are and what you propose we do >> here. >> >> The use-case we're addressing is the following: >> >> As a user I would like to initiate an action associated with my account >> through a front-end application so that I can make changes to my account, >> for example to register a WebAuthn security key with my account. >> >> Further, we want an action to be implemented once and re-usable in >> login/registration flows as well as from applications managing user >> accounts, incuding our new account console. That means our new account >> console needs to be able to invoke an action in the login flow, otherwise >> we would have to implement actions as react/rest also. >> >> Now the solution I have proposed is simple. It allows an application to >> request an action being invoked after the user has authenticated. Think of >> it as a "required action" on-demand. It can be implemented with a few lines >> of code and easily tested. It is very easy to use as it just means adding >> an extra query param to the login flows, which makes it very easy to use >> both for confidential and non-confidential clients. >> >> It is not trying to cover claims gathering use-case from UMA. I see no >> connection to this and step-up authentication. These both already have >> clearly defined protocols. Neither can be used to address the above >> use-case. >> >> So please come with a concrete proposal as I have no clue what your >> objections are. >> >> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: >> >>> >>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen < sthorger(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> >>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen < sthorger(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen < >>>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Is it this stuff you're thinking about: >>>>>>>>>> >>>>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >>>>>>>>>> >>>>>>>>>> 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. >>>>> >>>> That's not correct. All we know is that a client with the same client_id >>>> has obtained a token. Anyone can use the same client_id to initiate an >>>> action. >>>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> 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. >>>>> >>>> I don't see the additional use-cases you are mentioning as related at >>>> all. >>>> >>> How it is not related ? The audience of the information gathered during >>> the AIA does impact where the token with the information will be used. If I >>> need a DOB to access some page in my front-end, this is one thing. If I >>> need DOB to access some resource protected by a resource server it is >>> another thing. Both require tokens with different audiences, the former >>> will probably be an ID Token where the latter the access token. >>> >>> In OAuth2 the scopes represent the permissions to access protected >>> resources. Thus, it does make sense to have required actions that can >>> challenge a user when requesting scopes. Considering your DOB example, if >>> my client wants to access resource /api/age/check why you want the client >>> to request kc_action=dob if the scope "dob" is what he needs to access the >>> API ? Otherwise, you are making the client aware of things that are really >>> related to the resource server. It is OK the client ask for scope "age", it >>> is how OAuth2 authorization model works. >>> >>> UMA leverages OAuth2 in a way that the permission ticket makes the client >>> really dumb about what it needs to access protected resources. With UMA, >>> the client will just receive a ticket and with that ticket it can perform >>> the necessary actions to make a successful authorization request to the >>> server. >>> >>> >>>> * Step-up authentication has already clear parameters in OIDC/OAuth to >>>> request high level of authentication. On the implementation side it's about >>>> invoking additional parts of the authentication flow, not to initiate an >>>> required action that has nothing to do with the authentication flow. >>>> >>> Can we consider a required action as a prompt for 2nd factor, for >>> instance ? >>> >>> >>>> * Claims gathering in UMA is about asking the user for additional >>>> claims. AIA can be used as a poor-mans workaround to lack of claims >>>> gathering, but end of the day it's completely different. AIA will allow an >>>> app to invoke the action update_DOB, while claims gaterhing will allow the >>>> application to request the claim DOB. >>>> >>> Not sure, if the difference is due to updating a piece of info, both >>> flows request the user for the info. Is just a matter of updating or not >>> updating the info. >>> >>> >>>> I don't see what additional things we need to consider for something >>>> that is in the end very simple and can be implemented in a couple hours >>>> including tests if we don't try to make it more complicated. >>>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen < sthorger(a)redhat.com&gt; >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva < psilva(a)redhat.com&gt; >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen < >>>>>>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva < >>>>>>>>>>>>> psilva(a)redhat.com&gt; wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen < >>>>>>>>>>>>>> sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>>>>>>>>>>>>> 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(a)lists.jboss.org >>>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>>>> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I am sorry to join this so late. My concern is, that in the design, it was mentioned that consent will be always required from the user. I understand that this simplifies the flow as it's more secure and not need to authenticate the client. However from the usability perspective, it doesn't look so nice to me. For example assume that in the application, the user just clicked on the button "Link my account with Facebook" . Then after login with Facebook, he will see another splash screen like "Application XY wants to link your account with Facebook", which he needs to confirm. It may be especially bad for usability in this case with linking social accounts, as user may see one splash screen shown by Facebook "Application keycloak wants to access your Facebook profile and email" and then immediately another splash screen shown by Keycloak "Application Foo wants to link your account with Facebook" . Maybe I am wrong, but my guess is, that our users will very quickly come with requirement "Can I ommit to show the splash screen?" . It is bit similar to the "Consent Required" switch, which I guess most people have OFF for their clients. So IMO I would rather count with this from the beginning and count with the fact, that we will need to ommit consent screen and hence verify client. With regards to this, It seems that we may need also to specify if client is: - Allowed to initiate action - Allowed to initate action with the consent required - Allowed to initate action with no-consent required Maybe the "Consent required" switch can be on instead on the action itself, but the will still need to restrict if client is allowed or not to perform the action.

With regards to the flow, I suggest that KC will require full OIDC/OAuth2 flow. In other words, when KC redirects back to the client, the client will be required to send code-to-token request. And the action (EG. Keycloak user linked with Facebook) is done *after* the whole flow (including code-to-token flow) is finished. That should be sufficient to verify the client and at the same time, it will allow us to add some more things to tokens (EG. some facebook details) . Downside is, that it will be harder to implement though as the SPI will likely need another callback after code-to-token flow to "finish" the action...

Last thing, I was thinking about using "scope" parameter to reference those actions instead of have proprietary "kc_action" thing. The we don't need any extensions of OIDC. It may simplify things like consents etc. Also client will be able to have something similar like we have in "Client Scopes" tab - the list of action, which he is allowed to initiate. But I am not sure about this last point and maybe it's better to keep things separated...

Marek On 21/03/2019 14:07, Pedro Igor Silva wrote: > Sure, I'm not against the initial design/scope. Just tried to make comments > about other aspects that, to me, are related or how it can be leveraged to > also achieve other things. > > So, what Stian plans mentioned in one of his replies is fine for me. > > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert(a)redhat.com&gt; wrote: > >> Pedro, >> >> My only concern is getting this nailed down so we can move forward with >> the new account console. >> >> It sounds like Stian's proposal is simpler, but covers fewer use cases. >> Is that correct? >> >> Would it be practical to implement Stian's plan and then implement your >> proposal at a later date? >> >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote: >>> In addition to everything you said. >>> >>> * It is not only about making changes to account, but updating tokens >> with >>> information from required actions, which not necessarily need to be >>> persisted. >>> >>> * For back-end applications, we could also associate these required >> actions >>> with scopes. If we could have a required action as "Re-authenticate" or >>> "Provide 2nd factor", that would also help with step-up authentication. >> As >>> an alternative to OIDC acr related parameters/claims. I don't think it >>> makes sense to bring to the client concerns that are really tied to the >>> scopes of a resource server. As I said, clients should ask for scopes and >>> Keycloak should do whatever is necessary to grant these (via consent, via >>> additional steps/actions). Consider what you mentioned at the end of your >>> design document at "Require Re-Authentication". Couldn't we leverage AIA >>> for step-up and ask the user for a more stronger credential ? >>> >>> * Claims gathering flow is simple. The Keycloak server would return the >>> endpoint to where the client should redirect the user. After obtaining >>> information from the user, Keycloak would issue a ticket (instead of >> code). >>> The endpoint returned by Keycloak would contain the action associated >> with >>> a resource. The endpoint could be the same as what you are using for AIA. >>> >>> >>> >>> >>> >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> Pedro, >>>> >>>> I really don't understand what your points are and what you propose we >> do >>>> here. >>>> >>>> The use-case we're addressing is the following: >>>> >>>> As a user I would like to initiate an action associated with my account >>>> through a front-end application so that I can make changes to my >> account, >>>> for example to register a WebAuthn security key with my account. >>>> >>>> Further, we want an action to be implemented once and re-usable in >>>> login/registration flows as well as from applications managing user >>>> accounts, incuding our new account console. That means our new account >>>> console needs to be able to invoke an action in the login flow, >> otherwise >>>> we would have to implement actions as react/rest also. >>>> >>>> Now the solution I have proposed is simple. It allows an application to >>>> request an action being invoked after the user has authenticated. Think >> of >>>> it as a "required action" on-demand. It can be implemented with a few >> lines >>>> of code and easily tested. It is very easy to use as it just means >> adding >>>> an extra query param to the login flows, which makes it very easy to use >>>> both for confidential and non-confidential clients. >>>> >>>> It is not trying to cover claims gathering use-case from UMA. I see no >>>> connection to this and step-up authentication. These both already have >>>> clearly defined protocols. Neither can be used to address the above >>>> use-case. >>>> >>>> So please come with a concrete proposal as I have no clue what your >>>> objections are. >>>> >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen < sthorger(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen < >> sthorger(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva(a)redhat.com > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen < >> sthorger(a)redhat.com&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva < psilva(a)redhat.com&gt; >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen < >>>>>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Is it this stuff you're thinking about: >>>>>>>>>>>> >>>>>>>>>>>> >> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >>>>>>>>>>>> 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. >>>>>>> >>>>>> That's not correct. All we know is that a client with the same >> client_id >>>>>> has obtained a token. Anyone can use the same client_id to initiate an >>>>>> action. >>>>>> >>>>>> >>>>>>>>>>>> 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. >>>>>> I don't see the additional use-cases you are mentioning as related at >>>>>> all. >>>>>> >>>>> How it is not related ? The audience of the information gathered during >>>>> the AIA does impact where the token with the information will be used. >> If I >>>>> need a DOB to access some page in my front-end, this is one thing. If I >>>>> need DOB to access some resource protected by a resource server it is >>>>> another thing. Both require tokens with different audiences, the former >>>>> will probably be an ID Token where the latter the access token. >>>>> >>>>> In OAuth2 the scopes represent the permissions to access protected >>>>> resources. Thus, it does make sense to have required actions that can >>>>> challenge a user when requesting scopes. Considering your DOB example, >> if >>>>> my client wants to access resource /api/age/check why you want the >> client >>>>> to request kc_action=dob if the scope "dob" is what he needs to access >> the >>>>> API ? Otherwise, you are making the client aware of things that are >> really >>>>> related to the resource server. It is OK the client ask for scope >> "age", it >>>>> is how OAuth2 authorization model works. >>>>> >>>>> UMA leverages OAuth2 in a way that the permission ticket makes the >> client >>>>> really dumb about what it needs to access protected resources. With >> UMA, >>>>> the client will just receive a ticket and with that ticket it can >> perform >>>>> the necessary actions to make a successful authorization request to the >>>>> server. >>>>> >>>>> >>>>>> * Step-up authentication has already clear parameters in OIDC/OAuth to >>>>>> request high level of authentication. On the implementation side it's >> about >>>>>> invoking additional parts of the authentication flow, not to initiate >> an >>>>>> required action that has nothing to do with the authentication flow. >>>>>> >>>>> Can we consider a required action as a prompt for 2nd factor, for >>>>> instance ? >>>>> >>>>> >>>>>> * Claims gathering in UMA is about asking the user for additional >>>>>> claims. AIA can be used as a poor-mans workaround to lack of claims >>>>>> gathering, but end of the day it's completely different. AIA will >> allow an >>>>>> app to invoke the action update_DOB, while claims gaterhing will >> allow the >>>>>> application to request the claim DOB. >>>>>> >>>>> Not sure, if the difference is due to updating a piece of info, both >>>>> flows request the user for the info. Is just a matter of updating or >> not >>>>> updating the info. >>>>> >>>>> >>>>>> I don't see what additional things we need to consider for something >>>>>> that is in the end very simple and can be implemented in a couple >> hours >>>>>> including tests if we don't try to make it more complicated. >>>>>> >>>>>> >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen < >> sthorger(a)redhat.com&gt; >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva < >> psilva(a)redhat.com&gt; >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen < >>>>>>>>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva < >>>>>>>>>>>>>>> psilva(a)redhat.com&gt; wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen < >>>>>>>>>>>>>>>> sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>>>>>>>>>>>>>>> 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(a)lists.jboss.org >>>>>>>>>>>>>>>>>>>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>>>>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

To authenticate the client, why don't we just require id_token_hint to be included? We would require the ID token to be issued to the client trying to initiate the action and also be associated with the current session. I'd say we don't need to finely control what clients can do what at least not for now. Client should have scope on the manage_account role and that's enough for now.

On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: I am sorry to join this so late. My concern is, that in the design, it was mentioned that consent will be always required from the user. I understand that this simplifies the flow as it's more secure and not need to authenticate the client. However from the usability perspective, it doesn't look so nice to me. For example assume that in the application, the user just clicked on the button "Link my account with Facebook" . Then after login with Facebook, he will see another splash screen like "Application XY wants to link your account with Facebook", which he needs to confirm. It may be especially bad for usability in this case with linking social accounts, as user may see one splash screen shown by Facebook "Application keycloak wants to access your Facebook profile and email" and then immediately another splash screen shown by Keycloak "Application Foo wants to link your account with Facebook" . Maybe I am wrong, but my guess is, that our users will very quickly come with requirement "Can I ommit to show the splash screen?" . It is bit similar to the "Consent Required" switch, which I guess most people have OFF for their clients. So IMO I would rather count with this from the beginning and count with the fact, that we will need to ommit consent screen and hence verify client. With regards to this, It seems that we may need also to specify if client is: - Allowed to initiate action - Allowed to initate action with the consent required - Allowed to initate action with no-consent required Maybe the "Consent required" switch can be on instead on the action itself, but the will still need to restrict if client is allowed or not to perform the action. I can see your point for linking to external IdP. However, for everything else the actions are requesting a user to enter information before something happens. I.e. registering WebAuthn device, update password, etc.. All require the user to first fill in the form. With regards to the flow, I suggest that KC will require full OIDC/OAuth2 flow. In other words, when KC redirects back to the client, the client will be required to send code-to-token request. And the action (EG. Keycloak user linked with Facebook) is done *after* the whole flow (including code-to-token flow) is finished. That should be sufficient to verify the client and at the same time, it will allow us to add some more things to tokens (EG. some facebook details) . Downside is, that it will be harder to implement though as the SPI will likely need another callback after code-to-token flow to "finish" the action... I don't think I understand, because if you are proposing what I'm thinking it sounds awkward. Can you list the flow? Last thing, I was thinking about using "scope" parameter to reference those actions instead of have proprietary "kc_action" thing. The we don't need any extensions of OIDC. It may simplify things like consents etc. Also client will be able to have something similar like we have in "Client Scopes" tab - the list of action, which he is allowed to initiate. But I am not sure about this last point and maybe it's better to keep things separated... I'm not convinced using scope param makes sense. It just doesn't fit in my mental model. Marek On 21/03/2019 14:07, Pedro Igor Silva wrote: > Sure, I'm not against the initial design/scope. Just tried to make comments > about other aspects that, to me, are related or how it can be leveraged to > also achieve other things. > > So, what Stian plans mentioned in one of his replies is fine for me. > > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: > >> Pedro, >> >> My only concern is getting this nailed down so we can move forward with >> the new account console. >> >> It sounds like Stian's proposal is simpler, but covers fewer use cases. >> Is that correct? >> >> Would it be practical to implement Stian's plan and then implement your >> proposal at a later date? >> >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote: >>> In addition to everything you said. >>> >>> * It is not only about making changes to account, but updating tokens >> with >>> information from required actions, which not necessarily need to be >>> persisted. >>> >>> * For back-end applications, we could also associate these required >> actions >>> with scopes. If we could have a required action as "Re-authenticate" or >>> "Provide 2nd factor", that would also help with step-up authentication. >> As >>> an alternative to OIDC acr related parameters/claims. I don't think it >>> makes sense to bring to the client concerns that are really tied to the >>> scopes of a resource server. As I said, clients should ask for scopes and >>> Keycloak should do whatever is necessary to grant these (via consent, via >>> additional steps/actions). Consider what you mentioned at the end of your >>> design document at "Require Re-Authentication". Couldn't we leverage AIA >>> for step-up and ask the user for a more stronger credential ? >>> >>> * Claims gathering flow is simple. The Keycloak server would return the >>> endpoint to where the client should redirect the user. After obtaining >>> information from the user, Keycloak would issue a ticket (instead of >> code). >>> The endpoint returned by Keycloak would contain the action associated >> with >>> a resource. The endpoint could be the same as what you are using for AIA. >>> >>> >>> >>> >>> >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >>> wrote: >>> >>>> Pedro, >>>> >>>> I really don't understand what your points are and what you propose we >> do >>>> here. >>>> >>>> The use-case we're addressing is the following: >>>> >>>> As a user I would like to initiate an action associated with my account >>>> through a front-end application so that I can make changes to my >> account, >>>> for example to register a WebAuthn security key with my account. >>>> >>>> Further, we want an action to be implemented once and re-usable in >>>> login/registration flows as well as from applications managing user >>>> accounts, incuding our new account console. That means our new account >>>> console needs to be able to invoke an action in the login flow, >> otherwise >>>> we would have to implement actions as react/rest also. >>>> >>>> Now the solution I have proposed is simple. It allows an application to >>>> request an action being invoked after the user has authenticated. Think >> of >>>> it as a "required action" on-demand. It can be implemented with a few >> lines >>>> of code and easily tested. It is very easy to use as it just means >> adding >>>> an extra query param to the login flows, which makes it very easy to use >>>> both for confidential and non-confidential clients. >>>> >>>> It is not trying to cover claims gathering use-case from UMA. I see no >>>> connection to this and step-up authentication. These both already have >>>> clearly defined protocols. Neither can be used to address the above >>>> use-case. >>>> >>>> So please come with a concrete proposal as I have no clue what your >>>> objections are. >>>> >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva(a)redhat.com <mailto:psilva@redhat.com>> >> wrote: >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >>>>> wrote: >>>>> >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com <mailto:psilva@redhat.com>> >>>>>> wrote: >>>>>> >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen < >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >>>>>>> wrote: >>>>>>> >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva(a)redhat.com <mailto:psilva@redhat.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen < >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva(a)redhat.com <mailto:psilva@redhat.com>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen < >>>>>>>>>>> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Is it this stuff you're thinking about: >>>>>>>>>>>> >>>>>>>>>>>> >> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >>>>>>>>>>>>   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. >>>>>>> >>>>>> That's not correct. All we know is that a client with the same >> client_id >>>>>> has obtained a token. Anyone can use the same client_id to initiate an >>>>>> action. >>>>>> >>>>>> >>>>>>>>>>>> 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. >>>>>> I don't see the additional use-cases you are mentioning as related at >>>>>> all. >>>>>> >>>>> How it is not related ? The audience of the information gathered during >>>>> the AIA does impact where the token with the information will be used. >> If I >>>>> need a DOB to access some page in my front-end, this is one thing. If I >>>>> need DOB to access some resource protected by a resource server it is >>>>> another thing. Both require tokens with different audiences, the former >>>>> will probably be an ID Token where the latter the access token. >>>>> >>>>> In OAuth2 the scopes represent the permissions to access protected >>>>> resources. Thus, it does make sense to have required actions that can >>>>> challenge a user when requesting scopes. Considering your DOB example, >> if >>>>> my client wants to access resource /api/age/check why you want the >> client >>>>> to request kc_action=dob if the scope "dob" is what he needs to access >> the >>>>> API ? Otherwise, you are making the client aware of things that are >> really >>>>> related to the resource server. It is OK the client ask for scope >> "age", it >>>>> is how OAuth2 authorization model works. >>>>> >>>>> UMA leverages OAuth2 in a way that the permission ticket makes the >> client >>>>> really dumb about what it needs to access protected resources. With >> UMA, >>>>> the client will just receive a ticket and with that ticket it can >> perform >>>>> the necessary actions to make a successful authorization request to the >>>>> server. >>>>> >>>>> >>>>>> * Step-up authentication has already clear parameters in OIDC/OAuth to >>>>>> request high level of authentication. On the implementation side it's >> about >>>>>> invoking additional parts of the authentication flow, not to initiate >> an >>>>>> required action that has nothing to do with the authentication flow. >>>>>> >>>>> Can we consider a required action as a prompt for 2nd factor, for >>>>> instance ? >>>>> >>>>> >>>>>> * Claims gathering in UMA is about asking the user for additional >>>>>> claims. AIA can be used as a poor-mans workaround to lack of claims >>>>>> gathering, but end of the day it's completely different. AIA will >> allow an >>>>>> app to invoke the action update_DOB, while claims gaterhing will >> allow the >>>>>> application to request the claim DOB. >>>>>> >>>>> Not sure, if the difference is due to updating a piece of info, both >>>>> flows request the user for the info. Is just a matter of updating or >> not >>>>> updating the info. >>>>> >>>>> >>>>>> I don't see what additional things we need to consider for something >>>>>> that is in the end very simple and can be implemented in a couple >> hours >>>>>> including tests if we don't try to make it more complicated. >>>>>> >>>>>> >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen < >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva < >> psilva(a)redhat.com <mailto:psilva@redhat.com>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen < >>>>>>>>>>>>>> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva < >>>>>>>>>>>>>>> psilva(a)redhat.com <mailto:psilva@redhat.com>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen < >>>>>>>>>>>>>>>> sthorger(a)redhat.com <mailto:sthorger@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(a)redhat.com <mailto:psilva@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(a)redhat.com <mailto:sthorger@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(a)redhat.com <mailto:psilva@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(a)redhat.com <mailto:sthorger@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(a)redhat.com <mailto:pskopek@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(a)redhat.com <mailto:sthorger@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >>>>>>>>>>>>>>>>>>>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >>>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>>>>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev

I'm going to remind everyone again what is the aim and scope of AIA: * It is for an application to initiate an action, period. * It is aimed at allowing external account console (and similar applications) to make it possible for users to make changes to their account where we want to delegate the logic to actions after the "login flow" rather than having to duplicate the work in rest endpoints as well as "login flows" That is it. The design of this feature keeps getting more and more complex and we're not getting anywhere in the discussion because people are suggesting nice-to-haves or hypothetical other use-cases for the feature. So please keep the original use-case in mind when you are commenting on this and let's not make this into a complex unusable jack of all trades, but rather keep it as something simple with a small narrow use-case.

On Fri, 22 Mar 2019 at 15:20, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 22/03/2019 12:49, Stian Thorgersen wrote: > To authenticate the client, why don't we just > require id_token_hint to be included? > > We would require the ID token to be issued to the client trying > to initiate the action and also be associated with the current > session. > > I'd say we don't need to finely control what clients can do what > at least not for now. Client should have scope on the > manage_account role and that's enough for now. This assumes that client is authenticated before action is triggered. Don't we want also a possibility to trigger this "Application Initiated Actions" for cases when user is not yet authenticated? For example if I have web application, which will be something like "Web Email client", I want to ensure that user always has email verified before he is redirected to my application as authenticated. So I may want to trigger OIDC flow with "kc_action" even before user is authenticated. A few points here: * AIA are there to specifically run an action, not to request some sort of condition on the user account. kc_action=verify_email would run the verify email regardless if email is verified or not. * AIA are there for an application to allow a user to initiate an action from within an external app. It's not really there for the app to request things out of bounds.

Will be also nice for the "Terms and Conditions" actions as the "Terms and Conditions" pages are often client specific, so our current approach with generic "Terms and Conditions" action is likely not so nice and requires that many application implements some equivalent of app-specific "Terms and Conditions" page on their side rather than rely on Keycloak. But with those "Application Initiated Actions" we can improve on here. As far as I know we have never had a request for client specific terms and conditions. Not sure that is something Keycloak should ever consider, besides if we did that doesn't need kc_action, but rather just some way to configure different terms based on the client. Marek > > On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen > <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: > > > > On Fri, 22 Mar 2019 at 12:07, Marek Posolda > <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: > > I am sorry to join this so late. > > My concern is, that in the design, it was mentioned that > consent will be > always required from the user. I understand that this > simplifies the > flow as it's more secure and not need to authenticate the > client. > However from the usability perspective, it doesn't look > so nice to me. > > For example assume that in the application, the user just > clicked on the > button "Link my account with Facebook" . Then after login > with Facebook, > he will see another splash screen like "Application XY > wants to link > your account with Facebook", which he needs to confirm. > It may be > especially bad for usability in this case with linking > social accounts, > as user may see one splash screen shown by Facebook > "Application > keycloak wants to access your Facebook profile and email" > and then > immediately another splash screen shown by Keycloak > "Application Foo > wants to link your account with Facebook" . > > Maybe I am wrong, but my guess is, that our users will > very quickly come > with requirement "Can I ommit to show the splash screen?" > . It is bit > similar to the "Consent Required" switch, which I guess > most people have > OFF for their clients. So IMO I would rather count with > this from the > beginning and count with the fact, that we will need to > ommit consent > screen and hence verify client. > > With regards to this, It seems that we may need also to > specify if > client is: > - Allowed to initiate action > - Allowed to initate action with the consent required > - Allowed to initate action with no-consent required > Maybe the "Consent required" switch can be on instead on > the action > itself, but the will still need to restrict if client is > allowed or not > to perform the action. > > > I can see your point for linking to external IdP. > > However, for everything else the actions are requesting a > user to enter information before something happens. I.e. > registering WebAuthn device, update password, etc.. All > require the user to first fill in the form. > > > With regards to the flow, I suggest that KC will require > full > OIDC/OAuth2 flow. In other words, when KC redirects back > to the client, > the client will be required to send code-to-token > request. And the > action (EG. Keycloak user linked with Facebook) is done > *after* the > whole flow (including code-to-token flow) is finished. > That should be > sufficient to verify the client and at the same time, it > will allow us > to add some more things to tokens (EG. some facebook > details) . Downside > is, that it will be harder to implement though as the SPI > will likely > need another callback after code-to-token flow to > "finish" the action... > > > I don't think I understand, because if you are proposing what > I'm thinking it sounds awkward. Can you list the flow? > > > Last thing, I was thinking about using "scope" parameter > to reference > those actions instead of have proprietary "kc_action" > thing. The we > don't need any extensions of OIDC. It may simplify things > like consents > etc. Also client will be able to have something similar > like we have in > "Client Scopes" tab - the list of action, which he is > allowed to > initiate. But I am not sure about this last point and > maybe it's better > to keep things separated... > > > I'm not convinced using scope param makes sense. It just > doesn't fit in my mental model. > > > Marek > > > > > On 21/03/2019 14:07, Pedro Igor Silva wrote: > > Sure, I'm not against the initial design/scope. Just > tried to make comments > > about other aspects that, to me, are related or how it > can be leveraged to > > also achieve other things. > > > > So, what Stian plans mentioned in one of his replies is > fine for me. > > > > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert > <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: > > > >> Pedro, > >> > >> My only concern is getting this nailed down so we can > move forward with > >> the new account console. > >> > >> It sounds like Stian's proposal is simpler, but covers > fewer use cases. > >> Is that correct? > >> > >> Would it be practical to implement Stian's plan and > then implement your > >> proposal at a later date? > >> > >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote: > >>> In addition to everything you said. > >>> > >>> * It is not only about making changes to account, but > updating tokens > >> with > >>> information from required actions, which not > necessarily need to be > >>> persisted. > >>> > >>> * For back-end applications, we could also associate > these required > >> actions > >>> with scopes. If we could have a required action as > "Re-authenticate" or > >>> "Provide 2nd factor", that would also help with > step-up authentication. > >> As > >>> an alternative to OIDC acr related parameters/claims. > I don't think it > >>> makes sense to bring to the client concerns that are > really tied to the > >>> scopes of a resource server. As I said, clients > should ask for scopes and > >>> Keycloak should do whatever is necessary to grant > these (via consent, via > >>> additional steps/actions). Consider what you > mentioned at the end of your > >>> design document at "Require Re-Authentication". > Couldn't we leverage AIA > >>> for step-up and ask the user for a more stronger > credential ? > >>> > >>> * Claims gathering flow is simple. The Keycloak > server would return the > >>> endpoint to where the client should redirect the > user. After obtaining > >>> information from the user, Keycloak would issue a > ticket (instead of > >> code). > >>> The endpoint returned by Keycloak would contain the > action associated > >> with > >>> a resource. The endpoint could be the same as what > you are using for AIA. > >>> > >>> > >>> > >>> > >>> > >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen > <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> > >>> wrote: > >>> > >>>> Pedro, > >>>> > >>>> I really don't understand what your points are and > what you propose we > >> do > >>>> here. > >>>> > >>>> The use-case we're addressing is the following: > >>>> > >>>> As a user I would like to initiate an action > associated with my account > >>>> through a front-end application so that I can make > changes to my > >> account, > >>>> for example to register a WebAuthn security key with > my account. > >>>> > >>>> Further, we want an action to be implemented once > and re-usable in > >>>> login/registration flows as well as from > applications managing user > >>>> accounts, incuding our new account console. That > means our new account > >>>> console needs to be able to invoke an action in the > login flow, > >> otherwise > >>>> we would have to implement actions as react/rest also. > >>>> > >>>> Now the solution I have proposed is simple. It > allows an application to > >>>> request an action being invoked after the user has > authenticated. Think > >> of > >>>> it as a "required action" on-demand. It can be > implemented with a few > >> lines > >>>> of code and easily tested. It is very easy to use as > it just means > >> adding > >>>> an extra query param to the login flows, which makes > it very easy to use > >>>> both for confidential and non-confidential clients. > >>>> > >>>> It is not trying to cover claims gathering use-case > from UMA. I see no > >>>> connection to this and step-up authentication. These > both already have > >>>> clearly defined protocols. Neither can be used to > address the above > >>>> use-case. > >>>> > >>>> So please come with a concrete proposal as I have no > clue what your > >>>> objections are. > >>>> > >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva > <psilva(a)redhat.com <mailto:psilva@redhat.com>> > >> wrote: > >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen > <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> > >>>>> wrote: > >>>>> > >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva > <psilva(a)redhat.com <mailto:psilva@redhat.com>> > >>>>>> wrote: > >>>>>> > >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen < > >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva > <psilva(a)redhat.com <mailto:psilva@redhat.com>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen < > >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva > <psilva(a)redhat.com <mailto:psilva@redhat.com>> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian > Thorgersen < > >>>>>>>>>>> sthorger(a)redhat.com > <mailto:sthorger@redhat.com>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Is it this stuff you're thinking about: > >>>>>>>>>>>> > >>>>>>>>>>>> > >> > https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... > >>>>>>>>>>>>   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. > >>>>>>> > >>>>>> That's not correct. All we know is that a client > with the same > >> client_id > >>>>>> has obtained a token. Anyone can use the same > client_id to initiate an > >>>>>> action. > >>>>>> > >>>>>> > >>>>>>>>>>>> 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. > >>>>>> I don't see the additional use-cases you are > mentioning as related at > >>>>>> all. > >>>>>> > >>>>> How it is not related ? The audience of the > information gathered during > >>>>> the AIA does impact where the token with the > information will be used. > >> If I > >>>>> need a DOB to access some page in my front-end, > this is one thing. If I > >>>>> need DOB to access some resource protected by a > resource server it is > >>>>> another thing. Both require tokens with different > audiences, the former > >>>>> will probably be an ID Token where the latter the > access token. > >>>>> > >>>>> In OAuth2 the scopes represent the permissions to > access protected > >>>>> resources. Thus, it does make sense to have > required actions that can > >>>>> challenge a user when requesting scopes. > Considering your DOB example, > >> if > >>>>> my client wants to access resource /api/age/check > why you want the > >> client > >>>>> to request kc_action=dob if the scope "dob" is what > he needs to access > >> the > >>>>> API ? Otherwise, you are making the client aware of > things that are > >> really > >>>>> related to the resource server. It is OK the client > ask for scope > >> "age", it > >>>>> is how OAuth2 authorization model works. > >>>>> > >>>>> UMA leverages OAuth2 in a way that the permission > ticket makes the > >> client > >>>>> really dumb about what it needs to access protected > resources. With > >> UMA, > >>>>> the client will just receive a ticket and with that > ticket it can > >> perform > >>>>> the necessary actions to make a successful > authorization request to the > >>>>> server. > >>>>> > >>>>> > >>>>>> * Step-up authentication has already clear > parameters in OIDC/OAuth to > >>>>>> request high level of authentication. On the > implementation side it's > >> about > >>>>>> invoking additional parts of the authentication > flow, not to initiate > >> an > >>>>>> required action that has nothing to do with the > authentication flow. > >>>>>> > >>>>> Can we consider a required action as a prompt for > 2nd factor, for > >>>>> instance ? > >>>>> > >>>>> > >>>>>> * Claims gathering in UMA is about asking the user > for additional > >>>>>> claims. AIA can be used as a poor-mans workaround > to lack of claims > >>>>>> gathering, but end of the day it's completely > different. AIA will > >> allow an > >>>>>> app to invoke the action update_DOB, while claims > gaterhing will > >> allow the > >>>>>> application to request the claim DOB. > >>>>>> > >>>>> Not sure, if the difference is due to updating a > piece of info, both > >>>>> flows request the user for the info. Is just a > matter of updating or > >> not > >>>>> updating the info. > >>>>> > >>>>> > >>>>>> I don't see what additional things we need to > consider for something > >>>>>> that is in the end very simple and can be > implemented in a couple > >> hours > >>>>>> including tests if we don't try to make it more > complicated. > >>>>>> > >>>>>> > >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen < > >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva < > >> psilva(a)redhat.com <mailto:psilva@redhat.com>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian > Thorgersen < > >>>>>>>>>>>>>> sthorger(a)redhat.com > <mailto:sthorger@redhat.com>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor > Silva < > >>>>>>>>>>>>>>> psilva(a)redhat.com > <mailto:psilva@redhat.com>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian > Thorgersen < > >>>>>>>>>>>>>>>> sthorger(a)redhat.com > <mailto:sthorger@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(a)redhat.com > <mailto:psilva@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(a)redhat.com > <mailto:sthorger@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(a)redhat.com > <mailto:psilva@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(a)redhat.com > <mailto:sthorger@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(a)redhat.com > <mailto:pskopek@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(a)redhat.com > <mailto:sthorger@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(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > >>>>>>>>>>>>>>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>>>>>>>>>>>>>>>> > _______________________________________________ > >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list > >>>>>>>>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > >>>>>>>>>>>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>>>>>>>>>>>>>>>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

On Tue, 26 Mar 2019 at 09:39, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 26/03/2019 08:53, Stian Thorgersen wrote: > I'm going to remind everyone again what is the aim and scope of AIA: > > * It is for an application to initiate an action, period. > * It is aimed at allowing external account console (and similar > applications) to make it possible for users to make changes to > their account where we want to delegate the logic to actions > after the "login flow" rather than having to duplicate the work > in rest endpoints as well as "login flows" > > That is it. The design of this feature keeps getting more and > more complex and we're not getting anywhere in the discussion > because people are suggesting nice-to-haves or hypothetical other > use-cases for the feature. So please keep the original use-case > in mind when you are commenting on this and let's not make this > into a complex unusable jack of all trades, but rather keep it as > something simple with a small narrow use-case. I don't think that what I proposed is very complex. If I understand correctly, it is very similar to what you proposed with the only difference, that it requires client to do the whole OIDC flow including code-to-token request and the model is updated in the code-to-token request rather than before redirecting to client. It has advantages: - Client is properly authenticated based on the known OIDC flow. Hence no need to mandatory display consent screen "Application XY wants you to do Z" - Tokens will be available at the end of the flow with the updated state (EG. facebook claims or the "email_verified" claim) Disadvantage is the more complex flow, which means that SPI will need to maintain state and have the additional method, which will be triggered at the code-to-token request. That's the only real disadvantage I see, but I agree that added complexity of the SPI has some price... I don't want to block the work and hence I am not strongly enforce to follow my proposal :) Just wanted to propose that and it's up to you guys if you like it or not. My point is that you are complicating the flow as well as significantly complicating the action implementations when there is no need for it to address the use-case we are considering. id_token_hint as I suggested would be a much simpler solution that doesn't need a "two phase" action implementation like what you are suggesting.

> On Fri, 22 Mar 2019 at 15:20, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > On 22/03/2019 12:49, Stian Thorgersen wrote: >> To authenticate the client, why don't we just >> require id_token_hint to be included? >> >> We would require the ID token to be issued to the client >> trying to initiate the action and also be associated with >> the current session. >> >> I'd say we don't need to finely control what clients can do >> what at least not for now. Client should have scope on the >> manage_account role and that's enough for now. > > This assumes that client is authenticated before action is > triggered. Don't we want also a possibility to trigger this > "Application Initiated Actions" for cases when user is not > yet authenticated? For example if I have web application, > which will be something like "Web Email client", I want to > ensure that user always has email verified before he is > redirected to my application as authenticated. So I may want > to trigger OIDC flow with "kc_action" even before user is > authenticated. > > A few points here: > > * AIA are there to specifically run an action, not to request > some sort of condition on the user account. > kc_action=verify_email would run the verify email regardless if > email is verified or not. > * AIA are there for an application to allow a user to initiate an > action from within an external app. It's not really there for the > app to request things out of bounds. Well, that is the question? In current Account management, we show the link "Link Facebook" just in case that user is not yet linked with Facebook. Similarly if user is already linked, we display the link "Unlink Facebook" . It seems to me that people will often do those actions based on the state of the account (EG. I want to display link "Verify Email" in my application, just in case that user doesn't yet have verified email). Application has both the account REST API and the token available to discover information about the user account. Through account rest it would discover that Facebook is already linked or not. Hence, you do actually need to be already logged-in regardless. Maybe I am wrong and this is not so important, we may see in the future... Marek > Will be also nice for the "Terms and Conditions" actions as > the "Terms and Conditions" pages are often client specific, > so our current approach with generic "Terms and Conditions" > action is likely not so nice and requires that many > application implements some equivalent of app-specific "Terms > and Conditions" page on their side rather than rely on > Keycloak. But with those "Application Initiated Actions" we > can improve on here. > > As far as I know we have never had a request for client specific > terms and conditions. Not sure that is something Keycloak should > ever consider, besides if we did that doesn't need kc_action, but > rather just some way to configure different terms based on the > client. > > Marek > >> >> On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen >> <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: >> >> >> >> On Fri, 22 Mar 2019 at 12:07, Marek Posolda >> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: >> >> I am sorry to join this so late. >> >> My concern is, that in the design, it was mentioned >> that consent will be >> always required from the user. I understand that >> this simplifies the >> flow as it's more secure and not need to >> authenticate the client. >> However from the usability perspective, it doesn't >> look so nice to me. >> >> For example assume that in the application, the user >> just clicked on the >> button "Link my account with Facebook" . Then after >> login with Facebook, >> he will see another splash screen like "Application >> XY wants to link >> your account with Facebook", which he needs to >> confirm. It may be >> especially bad for usability in this case with >> linking social accounts, >> as user may see one splash screen shown by Facebook >> "Application >> keycloak wants to access your Facebook profile and >> email" and then >> immediately another splash screen shown by Keycloak >> "Application Foo >> wants to link your account with Facebook" . >> >> Maybe I am wrong, but my guess is, that our users >> will very quickly come >> with requirement "Can I ommit to show the splash >> screen?" . It is bit >> similar to the "Consent Required" switch, which I >> guess most people have >> OFF for their clients. So IMO I would rather count >> with this from the >> beginning and count with the fact, that we will need >> to ommit consent >> screen and hence verify client. >> >> With regards to this, It seems that we may need also >> to specify if >> client is: >> - Allowed to initiate action >> - Allowed to initate action with the consent required >> - Allowed to initate action with no-consent required >> Maybe the "Consent required" switch can be on >> instead on the action >> itself, but the will still need to restrict if >> client is allowed or not >> to perform the action. >> >> >> I can see your point for linking to external IdP. >> >> However, for everything else the actions are requesting >> a user to enter information before something happens. >> I.e. registering WebAuthn device, update password, etc.. >> All require the user to first fill in the form. >> >> >> With regards to the flow, I suggest that KC will >> require full >> OIDC/OAuth2 flow. In other words, when KC redirects >> back to the client, >> the client will be required to send code-to-token >> request. And the >> action (EG. Keycloak user linked with Facebook) is >> done *after* the >> whole flow (including code-to-token flow) is >> finished. That should be >> sufficient to verify the client and at the same >> time, it will allow us >> to add some more things to tokens (EG. some facebook >> details) . Downside >> is, that it will be harder to implement though as >> the SPI will likely >> need another callback after code-to-token flow to >> "finish" the action... >> >> >> I don't think I understand, because if you are proposing >> what I'm thinking it sounds awkward. Can you list the flow? >> >> >> Last thing, I was thinking about using "scope" >> parameter to reference >> those actions instead of have proprietary >> "kc_action" thing. The we >> don't need any extensions of OIDC. It may simplify >> things like consents >> etc. Also client will be able to have something >> similar like we have in >> "Client Scopes" tab - the list of action, which he >> is allowed to >> initiate. But I am not sure about this last point >> and maybe it's better >> to keep things separated... >> >> >> I'm not convinced using scope param makes sense. It just >> doesn't fit in my mental model. >> >> >> Marek >> >> >> >> >> On 21/03/2019 14:07, Pedro Igor Silva wrote: >> > Sure, I'm not against the initial design/scope. >> Just tried to make comments >> > about other aspects that, to me, are related or >> how it can be leveraged to >> > also achieve other things. >> > >> > So, what Stian plans mentioned in one of his >> replies is fine for me. >> > >> > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert >> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> >> wrote: >> > >> >> Pedro, >> >> >> >> My only concern is getting this nailed down so we >> can move forward with >> >> the new account console. >> >> >> >> It sounds like Stian's proposal is simpler, but >> covers fewer use cases. >> >> Is that correct? >> >> >> >> Would it be practical to implement Stian's plan >> and then implement your >> >> proposal at a later date? >> >> >> >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote: >> >>> In addition to everything you said. >> >>> >> >>> * It is not only about making changes to >> account, but updating tokens >> >> with >> >>> information from required actions, which not >> necessarily need to be >> >>> persisted. >> >>> >> >>> * For back-end applications, we could also >> associate these required >> >> actions >> >>> with scopes. If we could have a required action >> as "Re-authenticate" or >> >>> "Provide 2nd factor", that would also help with >> step-up authentication. >> >> As >> >>> an alternative to OIDC acr related >> parameters/claims. I don't think it >> >>> makes sense to bring to the client concerns that >> are really tied to the >> >>> scopes of a resource server. As I said, clients >> should ask for scopes and >> >>> Keycloak should do whatever is necessary to >> grant these (via consent, via >> >>> additional steps/actions). Consider what you >> mentioned at the end of your >> >>> design document at "Require Re-Authentication". >> Couldn't we leverage AIA >> >>> for step-up and ask the user for a more stronger >> credential ? >> >>> >> >>> * Claims gathering flow is simple. The Keycloak >> server would return the >> >>> endpoint to where the client should redirect the >> user. After obtaining >> >>> information from the user, Keycloak would issue >> a ticket (instead of >> >> code). >> >>> The endpoint returned by Keycloak would contain >> the action associated >> >> with >> >>> a resource. The endpoint could be the same as >> what you are using for AIA. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen >> <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >> >>> wrote: >> >>> >> >>>> Pedro, >> >>>> >> >>>> I really don't understand what your points are >> and what you propose we >> >> do >> >>>> here. >> >>>> >> >>>> The use-case we're addressing is the following: >> >>>> >> >>>> As a user I would like to initiate an action >> associated with my account >> >>>> through a front-end application so that I can >> make changes to my >> >> account, >> >>>> for example to register a WebAuthn security key >> with my account. >> >>>> >> >>>> Further, we want an action to be implemented >> once and re-usable in >> >>>> login/registration flows as well as from >> applications managing user >> >>>> accounts, incuding our new account console. >> That means our new account >> >>>> console needs to be able to invoke an action in >> the login flow, >> >> otherwise >> >>>> we would have to implement actions as >> react/rest also. >> >>>> >> >>>> Now the solution I have proposed is simple. It >> allows an application to >> >>>> request an action being invoked after the user >> has authenticated. Think >> >> of >> >>>> it as a "required action" on-demand. It can be >> implemented with a few >> >> lines >> >>>> of code and easily tested. It is very easy to >> use as it just means >> >> adding >> >>>> an extra query param to the login flows, which >> makes it very easy to use >> >>>> both for confidential and non-confidential clients. >> >>>> >> >>>> It is not trying to cover claims gathering >> use-case from UMA. I see no >> >>>> connection to this and step-up authentication. >> These both already have >> >>>> clearly defined protocols. Neither can be used >> to address the above >> >>>> use-case. >> >>>> >> >>>> So please come with a concrete proposal as I >> have no clue what your >> >>>> objections are. >> >>>> >> >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva >> <psilva(a)redhat.com <mailto:psilva@redhat.com>> >> >> wrote: >> >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian >> Thorgersen <sthorger(a)redhat.com >> <mailto:sthorger@redhat.com>> >> >>>>> wrote: >> >>>>> >> >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor >> Silva <psilva(a)redhat.com <mailto:psilva@redhat.com>> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian >> Thorgersen < >> >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor >> Silva <psilva(a)redhat.com <mailto:psilva@redhat.com>> >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian >> Thorgersen < >> >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor >> Silva <psilva(a)redhat.com <mailto:psilva@redhat.com>> >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian >> Thorgersen < >> >>>>>>>>>>> sthorger(a)redhat.com >> <mailto:sthorger@redhat.com>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> Is it this stuff you're thinking about: >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >> >> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >> >>>>>>>>>>>>   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. >> >>>>>>> >> >>>>>> That's not correct. All we know is that a >> client with the same >> >> client_id >> >>>>>> has obtained a token. Anyone can use the same >> client_id to initiate an >> >>>>>> action. >> >>>>>> >> >>>>>> >> >>>>>>>>>>>> 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. >> >>>>>> I don't see the additional use-cases you are >> mentioning as related at >> >>>>>> all. >> >>>>>> >> >>>>> How it is not related ? The audience of the >> information gathered during >> >>>>> the AIA does impact where the token with the >> information will be used. >> >> If I >> >>>>> need a DOB to access some page in my >> front-end, this is one thing. If I >> >>>>> need DOB to access some resource protected by >> a resource server it is >> >>>>> another thing. Both require tokens with >> different audiences, the former >> >>>>> will probably be an ID Token where the latter >> the access token. >> >>>>> >> >>>>> In OAuth2 the scopes represent the permissions >> to access protected >> >>>>> resources. Thus, it does make sense to have >> required actions that can >> >>>>> challenge a user when requesting scopes. >> Considering your DOB example, >> >> if >> >>>>> my client wants to access resource >> /api/age/check why you want the >> >> client >> >>>>> to request kc_action=dob if the scope "dob" is >> what he needs to access >> >> the >> >>>>> API ? Otherwise, you are making the client >> aware of things that are >> >> really >> >>>>> related to the resource server. It is OK the >> client ask for scope >> >> "age", it >> >>>>> is how OAuth2 authorization model works. >> >>>>> >> >>>>> UMA leverages OAuth2 in a way that the >> permission ticket makes the >> >> client >> >>>>> really dumb about what it needs to access >> protected resources. With >> >> UMA, >> >>>>> the client will just receive a ticket and with >> that ticket it can >> >> perform >> >>>>> the necessary actions to make a successful >> authorization request to the >> >>>>> server. >> >>>>> >> >>>>> >> >>>>>> * Step-up authentication has already clear >> parameters in OIDC/OAuth to >> >>>>>> request high level of authentication. On the >> implementation side it's >> >> about >> >>>>>> invoking additional parts of the >> authentication flow, not to initiate >> >> an >> >>>>>> required action that has nothing to do with >> the authentication flow. >> >>>>>> >> >>>>> Can we consider a required action as a prompt >> for 2nd factor, for >> >>>>> instance ? >> >>>>> >> >>>>> >> >>>>>> * Claims gathering in UMA is about asking the >> user for additional >> >>>>>> claims. AIA can be used as a poor-mans >> workaround to lack of claims >> >>>>>> gathering, but end of the day it's completely >> different. AIA will >> >> allow an >> >>>>>> app to invoke the action update_DOB, while >> claims gaterhing will >> >> allow the >> >>>>>> application to request the claim DOB. >> >>>>>> >> >>>>> Not sure, if the difference is due to updating >> a piece of info, both >> >>>>> flows request the user for the info. Is just a >> matter of updating or >> >> not >> >>>>> updating the info. >> >>>>> >> >>>>> >> >>>>>> I don't see what additional things we need to >> consider for something >> >>>>>> that is in the end very simple and can be >> implemented in a couple >> >> hours >> >>>>>> including tests if we don't try to make it >> more complicated. >> >>>>>> >> >>>>>> >> >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian >> Thorgersen < >> >> sthorger(a)redhat.com <mailto:sthorger@redhat.com>> >> >>>>>>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro >> Igor Silva < >> >> psilva(a)redhat.com <mailto:psilva@redhat.com>> >> >>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian >> Thorgersen < >> >>>>>>>>>>>>>> sthorger(a)redhat.com >> <mailto:sthorger@redhat.com>> wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro >> Igor Silva < >> >>>>>>>>>>>>>>> psilva(a)redhat.com >> <mailto:psilva@redhat.com>> wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM >> Stian Thorgersen < >> >>>>>>>>>>>>>>>> sthorger(a)redhat.com >> <mailto:sthorger@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(a)redhat.com >> <mailto:psilva@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(a)redhat.com >> <mailto:sthorger@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(a)redhat.com >> <mailto:psilva@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(a)redhat.com >> <mailto:sthorger@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(a)redhat.com >> <mailto:pskopek@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(a)redhat.com >> <mailto:sthorger@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(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> >>>>>>>>>>>>>>>>>>>>>>> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>>>>>>>>>>>>>>>>>> >> _______________________________________________ >> >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list >> >>>>>>>>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> >>>>>>>>>>>>>>>>>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>>>>>>>>>>>>>>>>>> >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >

On 22/03/2019 12:42, Stian Thorgersen wrote: On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > I am sorry to join this so late. > > My concern is, that in the design, it was mentioned that consent will be > always required from the user. I understand that this simplifies the > flow as it's more secure and not need to authenticate the client. > However from the usability perspective, it doesn't look so nice to me. > > For example assume that in the application, the user just clicked on the > button "Link my account with Facebook" . Then after login with Facebook, > he will see another splash screen like "Application XY wants to link > your account with Facebook", which he needs to confirm. It may be > especially bad for usability in this case with linking social accounts, > as user may see one splash screen shown by Facebook "Application > keycloak wants to access your Facebook profile and email" and then > immediately another splash screen shown by Keycloak "Application Foo > wants to link your account with Facebook" . > > Maybe I am wrong, but my guess is, that our users will very quickly come > with requirement "Can I ommit to show the splash screen?" . It is bit > similar to the "Consent Required" switch, which I guess most people have > OFF for their clients. So IMO I would rather count with this from the > beginning and count with the fact, that we will need to ommit consent > screen and hence verify client. > > With regards to this, It seems that we may need also to specify if > client is: > - Allowed to initiate action > - Allowed to initate action with the consent required > - Allowed to initate action with no-consent required > Maybe the "Consent required" switch can be on instead on the action > itself, but the will still need to restrict if client is allowed or not > to perform the action. > I can see your point for linking to external IdP. However, for everything else the actions are requesting a user to enter information before something happens. I.e. registering WebAuthn device, update password, etc.. All require the user to first fill in the form. I see. But if we can think about at least of one "type" of the action, which may not show any special page, there are probably others :) With regards to the flow, I suggest that KC will require full > OIDC/OAuth2 flow. In other words, when KC redirects back to the client, > the client will be required to send code-to-token request. And the > action (EG. Keycloak user linked with Facebook) is done *after* the > whole flow (including code-to-token flow) is finished. That should be > sufficient to verify the client and at the same time, it will allow us > to add some more things to tokens (EG. some facebook details) . Downside > is, that it will be harder to implement though as the SPI will likely > need another callback after code-to-token flow to "finish" the action... > I don't think I understand, because if you are proposing what I'm thinking it sounds awkward. Can you list the flow? It is pretty much OIDC flow. So: - The initial request with "kc_action=link-facebook" is sent to OIDC authentication endpoint - KC (re-)authenticates user and do all the UI actions required for the requested action - Before the model is updated (EG. userModel.addFederationLink("facebook") called), there is redirection to client with code+state etc - Client needs to send code-to-token request. - KC will need to verify code (already done), finally finish the model (EG. call "user.addFederationLink" or "user.setEmailVerified(true)" ). That's where I think the SPI callback will be needed. Finally re-generate tokens and verify back to the application. - Client receives updated tokens with all the new state (EG. "email_verified" is set to true, user's birthday claim retrieved from facebook is in the token etc.) This has some good advantages like the: - Client is verified. In case of confidential clients, there is proper client authentication. For public clients, there is at least redirection back to the client application and exchanging for tokens, which is still bit safer than just update model on server (EG. userModel.addFederationLink) and redirect to client after. However for public clients, people will more likely want to show the splash screen "Application XY wants to link your account" - Tokens are updated at the end of the flow. This is important for many applications though as in many cases, people will likely trigger actions under some conditions. For example in the application will do something like: if (!idToken.isEmailVerified()) { redirectToVerifyEmailAction(); } So without updated tokens, you will have infinite loop or the need to re-trigger to OIDC flow manually again to have tokens refreshed with new claims

> > Last thing, I was thinking about using "scope" parameter to reference > those actions instead of have proprietary "kc_action" thing. The we > don't need any extensions of OIDC. It may simplify things like consents > etc. Also client will be able to have something similar like we have in > "Client Scopes" tab - the list of action, which he is allowed to > initiate. But I am not sure about this last point and maybe it's better > to keep things separated... > I'm not convinced using scope param makes sense. It just doesn't fit in my mental model. I see. I am also not convinced so much about scope param... Just some quick idea :) Marek > > Marek > > > > > On 21/03/2019 14:07, Pedro Igor Silva wrote: > > Sure, I'm not against the initial design/scope. Just tried to make > comments > > about other aspects that, to me, are related or how it can be leveraged > to > > also achieve other things. > > > > So, what Stian plans mentioned in one of his replies is fine for me. > > > > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert(a)redhat.com&gt; > wrote: > > > >> Pedro, > >> > >> My only concern is getting this nailed down so we can move forward with > >> the new account console. > >> > >> It sounds like Stian's proposal is simpler, but covers fewer use cases. > >> Is that correct? > >> > >> Would it be practical to implement Stian's plan and then implement your > >> proposal at a later date? > >> > >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote: > >>> In addition to everything you said. > >>> > >>> * It is not only about making changes to account, but updating tokens > >> with > >>> information from required actions, which not necessarily need to be > >>> persisted. > >>> > >>> * For back-end applications, we could also associate these required > >> actions > >>> with scopes. If we could have a required action as "Re-authenticate" > or > >>> "Provide 2nd factor", that would also help with step-up > authentication. > >> As > >>> an alternative to OIDC acr related parameters/claims. I don't think it > >>> makes sense to bring to the client concerns that are really tied to > the > >>> scopes of a resource server. As I said, clients should ask for scopes > and > >>> Keycloak should do whatever is necessary to grant these (via consent, > via > >>> additional steps/actions). Consider what you mentioned at the end of > your > >>> design document at "Require Re-Authentication". Couldn't we leverage > AIA > >>> for step-up and ask the user for a more stronger credential ? > >>> > >>> * Claims gathering flow is simple. The Keycloak server would return > the > >>> endpoint to where the client should redirect the user. After obtaining > >>> information from the user, Keycloak would issue a ticket (instead of > >> code). > >>> The endpoint returned by Keycloak would contain the action associated > >> with > >>> a resource. The endpoint could be the same as what you are using for > AIA. > >>> > >>> > >>> > >>> > >>> > >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger(a)redhat.com > > > >>> wrote: > >>> > >>>> Pedro, > >>>> > >>>> I really don't understand what your points are and what you propose > we > >> do > >>>> here. > >>>> > >>>> The use-case we're addressing is the following: > >>>> > >>>> As a user I would like to initiate an action associated with my > account > >>>> through a front-end application so that I can make changes to my > >> account, > >>>> for example to register a WebAuthn security key with my account. > >>>> > >>>> Further, we want an action to be implemented once and re-usable in > >>>> login/registration flows as well as from applications managing user > >>>> accounts, incuding our new account console. That means our new > account > >>>> console needs to be able to invoke an action in the login flow, > >> otherwise > >>>> we would have to implement actions as react/rest also. > >>>> > >>>> Now the solution I have proposed is simple. It allows an application > to > >>>> request an action being invoked after the user has authenticated. > Think > >> of > >>>> it as a "required action" on-demand. It can be implemented with a few > >> lines > >>>> of code and easily tested. It is very easy to use as it just means > >> adding > >>>> an extra query param to the login flows, which makes it very easy to > use > >>>> both for confidential and non-confidential clients. > >>>> > >>>> It is not trying to cover claims gathering use-case from UMA. I see > no > >>>> connection to this and step-up authentication. These both already > have > >>>> clearly defined protocols. Neither can be used to address the above > >>>> use-case. > >>>> > >>>> So please come with a concrete proposal as I have no clue what your > >>>> objections are. > >>>> > >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva(a)redhat.com&gt; > >> wrote: > >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen < > sthorger(a)redhat.com&gt; > >>>>> wrote: > >>>>> > >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com&gt; > >>>>>> wrote: > >>>>>> > >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen < > >> sthorger(a)redhat.com&gt; > >>>>>>> wrote: > >>>>>>> > >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva < > psilva(a)redhat.com&gt; > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen < > >> sthorger(a)redhat.com&gt; > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva < > psilva(a)redhat.com&gt; > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen < > >>>>>>>>>>> sthorger(a)redhat.com&gt; wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Is it this stuff you're thinking about: > >>>>>>>>>>>> > >>>>>>>>>>>> > >> > https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... > >>>>>>>>>>>> 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. > >>>>>>> > >>>>>> That's not correct. All we know is that a client with the same > >> client_id > >>>>>> has obtained a token. Anyone can use the same client_id to > initiate an > >>>>>> action. > >>>>>> > >>>>>> > >>>>>>>>>>>> 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. > >>>>>> I don't see the additional use-cases you are mentioning as related > at > >>>>>> all. > >>>>>> > >>>>> How it is not related ? The audience of the information gathered > during > >>>>> the AIA does impact where the token with the information will be > used. > >> If I > >>>>> need a DOB to access some page in my front-end, this is one thing. > If I > >>>>> need DOB to access some resource protected by a resource server it > is > >>>>> another thing. Both require tokens with different audiences, the > former > >>>>> will probably be an ID Token where the latter the access token. > >>>>> > >>>>> In OAuth2 the scopes represent the permissions to access protected > >>>>> resources. Thus, it does make sense to have required actions that > can > >>>>> challenge a user when requesting scopes. Considering your DOB > example, > >> if > >>>>> my client wants to access resource /api/age/check why you want the > >> client > >>>>> to request kc_action=dob if the scope "dob" is what he needs to > access > >> the > >>>>> API ? Otherwise, you are making the client aware of things that are > >> really > >>>>> related to the resource server. It is OK the client ask for scope > >> "age", it > >>>>> is how OAuth2 authorization model works. > >>>>> > >>>>> UMA leverages OAuth2 in a way that the permission ticket makes the > >> client > >>>>> really dumb about what it needs to access protected resources. With > >> UMA, > >>>>> the client will just receive a ticket and with that ticket it can > >> perform > >>>>> the necessary actions to make a successful authorization request to > the > >>>>> server. > >>>>> > >>>>> > >>>>>> * Step-up authentication has already clear parameters in > OIDC/OAuth to > >>>>>> request high level of authentication. On the implementation side > it's > >> about > >>>>>> invoking additional parts of the authentication flow, not to > initiate > >> an > >>>>>> required action that has nothing to do with the authentication > flow. > >>>>>> > >>>>> Can we consider a required action as a prompt for 2nd factor, for > >>>>> instance ? > >>>>> > >>>>> > >>>>>> * Claims gathering in UMA is about asking the user for additional > >>>>>> claims. AIA can be used as a poor-mans workaround to lack of claims > >>>>>> gathering, but end of the day it's completely different. AIA will > >> allow an > >>>>>> app to invoke the action update_DOB, while claims gaterhing will > >> allow the > >>>>>> application to request the claim DOB. > >>>>>> > >>>>> Not sure, if the difference is due to updating a piece of info, both > >>>>> flows request the user for the info. Is just a matter of updating or > >> not > >>>>> updating the info. > >>>>> > >>>>> > >>>>>> I don't see what additional things we need to consider for > something > >>>>>> that is in the end very simple and can be implemented in a couple > >> hours > >>>>>> including tests if we don't try to make it more complicated. > >>>>>> > >>>>>> > >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen < > >> sthorger(a)redhat.com&gt; > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva < > >> psilva(a)redhat.com&gt; > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen < > >>>>>>>>>>>>>> sthorger(a)redhat.com&gt; wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva < > >>>>>>>>>>>>>>> psilva(a)redhat.com&gt; wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen < > >>>>>>>>>>>>>>>> sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; > >>>>>>>>>>>>>>>>>>>>>> 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(a)lists.jboss.org > >>>>>>>>>>>>>>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list > >>>>>>>>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org > >>>>>>>>>>>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>>>>>>>>>>>>>>>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

In addition to everything you said. * It is not only about making changes to account, but updating tokens with information from required actions, which not necessarily need to be persisted.

* For back-end applications, we could also associate these required actions with scopes. If we could have a required action as "Re-authenticate" or "Provide 2nd factor", that would also help with step-up authentication. As an alternative to OIDC acr related parameters/claims. I don't think it makes sense to bring to the client concerns that are really tied to the scopes of a resource server. As I said, clients should ask for scopes and Keycloak should do whatever is necessary to grant these (via consent, via additional steps/actions). Consider what you mentioned at the end of your design document at "Require Re-Authentication". Couldn't we leverage AIA for step-up and ask the user for a more stronger credential ?

* Claims gathering flow is simple. The Keycloak server would return the endpoint to where the client should redirect the user. After obtaining information from the user, Keycloak would issue a ticket (instead of code). The endpoint returned by Keycloak would contain the action associated with a resource. The endpoint could be the same as what you are using for AIA.

From briefly reading UMA claims gathering flow it's a completely new

On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > Pedro, > > I really don't understand what your points are and what you propose we do > here. > > The use-case we're addressing is the following: > > As a user I would like to initiate an action associated with my account > through a front-end application so that I can make changes to my account, > for example to register a WebAuthn security key with my account. > > Further, we want an action to be implemented once and re-usable in > login/registration flows as well as from applications managing user > accounts, incuding our new account console. That means our new account > console needs to be able to invoke an action in the login flow, otherwise > we would have to implement actions as react/rest also. > > Now the solution I have proposed is simple. It allows an application to > request an action being invoked after the user has authenticated. Think of > it as a "required action" on-demand. It can be implemented with a few lines > of code and easily tested. It is very easy to use as it just means adding > an extra query param to the login flows, which makes it very easy to use > both for confidential and non-confidential clients. > > It is not trying to cover claims gathering use-case from UMA. I see no > connection to this and step-up authentication. These both already have > clearly defined protocols. Neither can be used to address the above > use-case. > > So please come with a concrete proposal as I have no clue what your > objections are. > > On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > >> >> >> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen < >>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> Is it this stuff you're thinking about: >>>>>>>>> >>>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redi... >>>>>>>>> >>>>>>>>> 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. >>>> >>> >>> That's not correct. All we know is that a client with the same >>> client_id has obtained a token. Anyone can use the same client_id to >>> initiate an action. >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 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. >>>> >>> >>> I don't see the additional use-cases you are mentioning as related at >>> all. >>> >> >> How it is not related ? The audience of the information gathered during >> the AIA does impact where the token with the information will be used. If I >> need a DOB to access some page in my front-end, this is one thing. If I >> need DOB to access some resource protected by a resource server it is >> another thing. Both require tokens with different audiences, the former >> will probably be an ID Token where the latter the access token. >> >> In OAuth2 the scopes represent the permissions to access protected >> resources. Thus, it does make sense to have required actions that can >> challenge a user when requesting scopes. Considering your DOB example, if >> my client wants to access resource /api/age/check why you want the client >> to request kc_action=dob if the scope "dob" is what he needs to access the >> API ? Otherwise, you are making the client aware of things that are really >> related to the resource server. It is OK the client ask for scope "age", it >> is how OAuth2 authorization model works. >> >> UMA leverages OAuth2 in a way that the permission ticket makes the >> client really dumb about what it needs to access protected resources. With >> UMA, the client will just receive a ticket and with that ticket it can >> perform the necessary actions to make a successful authorization request to >> the server. >> >> >>> >>> * Step-up authentication has already clear parameters in OIDC/OAuth to >>> request high level of authentication. On the implementation side it's about >>> invoking additional parts of the authentication flow, not to initiate an >>> required action that has nothing to do with the authentication flow. >>> >> >> Can we consider a required action as a prompt for 2nd factor, for >> instance ? >> >> >>> >>> * Claims gathering in UMA is about asking the user for additional >>> claims. AIA can be used as a poor-mans workaround to lack of claims >>> gathering, but end of the day it's completely different. AIA will allow an >>> app to invoke the action update_DOB, while claims gaterhing will allow the >>> application to request the claim DOB. >>> >> >> Not sure, if the difference is due to updating a piece of info, both >> flows request the user for the info. Is just a matter of updating or not >> updating the info. >> >> >>> >>> I don't see what additional things we need to consider for something >>> that is in the end very simple and can be implemented in a couple hours >>> including tests if we don't try to make it more complicated. >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen < >>>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen < >>>>>>>>>>> sthorger(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva < >>>>>>>>>>>> psilva(a)redhat.com&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen < >>>>>>>>>>>>> sthorger(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>>>>>>>>>>> > 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(a)lists.jboss.org >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>