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