On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>
>
> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger(a)redhat.com>
> 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>
>>> 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.
>>
>
> 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>
>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>