[keycloak-dev] Application Initiated Actions

Fri Mar 22 07:42:17 EDT 2019

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