On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva(a)redhat.com> wrote:
On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> Why do you think authentication/authorization is required? The user will
> be prompted before making an action and it's an action they do against
> RH-SSO and not automatically visible/exposed to the client.
>
The client is making the request and even though the user is at the
Keycloak server to perform the action, admins may want to restrict which
clients are allowed to perform such actions. That is what I mean by some
level of authorization.
You could even consider not authenticating the client at all, but still
allow admins to enforce which clients should be allowed to initiate actions
on the server.
I can't see how enforcing which clients is allowed to initiate actions will
work without authenticating the client.
>
> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>
>> One way is to follow authorization code constraints like checking the
>> client_id and redirect_uri (assuming the user will be redirected back after
>> the action completes). But still, we could also add some level
>> authorization.
>>
>
> authorization code constraints doesn't work as anyone can just use the
> client_id and redirect_uri from a different client.
>
I may be missing the whole flow. I would ask then what happens after the
user performs an action. Is he/her redirected back to the client ? If so,
client_id + redirect_uri do work to make sure that the client is known and
that the user will be redirected back to a valid URI.
It's just a standard OAuth flow, so app would get new tokens. Say the user
hasn't entered a DOB in the profile and the client wants that, then they
can request the user to enter a DOB, which would then result in the DOB
being available in the token.
>
> Only viable option I can think of is to add an endpoint where the
> application can request a token to initate an action. So flow would be:
>
> 1. App sends POST { action: <action-id> } with ID Token as bearer token
> in header to a new endpoint. This would return a single use token.
> 2. App can now do the redirect protocol as before, but instead of
> "?action=<action>" they would do "?action-token=<action
token>"
>
> In the JS adapter we can add a action(actionId) function that would get
> the action token before redirecting the user.
>
> Not sure what you mean about level authorization.
>
>
>>
>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger(a)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>
>>> 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>
>>>> 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>
>>>>> 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>
>>>>> > 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
>>>>>
>>>>