[keycloak-dev] Application Initiated Actions

Tue Mar 26 03:45:51 EDT 2019

On Fri, 22 Mar 2019 at 15:12, Marek Posolda <mposolda at redhat.com> wrote:

> On 22/03/2019 12:42, Stian Thorgersen wrote:
>
>
>
> 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.
>
> I see. But if we can think about at least of one "type" of the action,
> which may not show any special page, there are probably others :)
>
> 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?
>
> It is pretty much OIDC flow. So:
>
> - The initial request with "kc_action=link-facebook" is sent to OIDC
> authentication endpoint
> - KC (re-)authenticates user and do all the UI actions required for the
> requested action
> - Before the model is updated (EG. userModel.addFederationLink("facebook")
> called), there is redirection to client with code+state etc
> - Client needs to send code-to-token request.
> - KC will need to verify code (already done), finally finish the model
> (EG. call "user.addFederationLink" or "user.setEmailVerified(true)" ).
> That's where I think the SPI callback will be needed. Finally re-generate
> tokens and verify back to the application.
> - Client receives updated tokens with all the new state (EG.
> "email_verified" is set to true, user's birthday claim retrieved from
> facebook is in the token etc.)
>
> This has some good advantages like the:
>
> - Client is verified. In case of confidential clients, there is proper
> client authentication. For public clients, there is at least redirection
> back to the client application and exchanging for tokens, which is still
> bit safer than just update model on server (EG.
> userModel.addFederationLink) and redirect to client after. However for
> public clients, people will more likely want to show the splash screen
> "Application XY wants to link your account"
>
> - Tokens are updated at the end of the flow. This is important for many
> applications though as in many cases, people will likely trigger actions
> under some conditions. For example in the application will do something
> like:
>
> if (!idToken.isEmailVerified()) {
>     redirectToVerifyEmailAction();
>
> }
>
> So without updated tokens, you will have infinite loop or the need to
> re-trigger to OIDC flow manually again to have tokens refreshed with new
> claims
>
I really hate that idea ;)

* You don't know the client until after the user has entered the values -
so invalid client would still require user to do the work, but just
silently revert it
* Requires special actions that somehow caches all updates
* May be very hard to do for some actions

I could go on

>
>
>>
>> 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.
>
> I see. I am also not convinced so much about scope param... Just some
> quick idea :)
>
> Marek
>
>
>
>>
>> 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
>>
>
>