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>
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>
>> wrote:
>>>>> 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
>>>>>>>>>>>>>>>>>>>>>
>>> _______________________________________________
>>> 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