On 26/03/2019 08:53, Stian Thorgersen wrote:
I'm going to remind everyone again what is the aim and scope of AIA:
* It is for an application to initiate an action, period.
* It is aimed at allowing external account console (and similar
applications) to make it possible for users to make changes to their
account where we want to delegate the logic to actions after the "login
flow" rather than having to duplicate the work in rest endpoints as well as
"login flows"
That is it. The design of this feature keeps getting more and more complex
and we're not getting anywhere in the discussion because people are
suggesting nice-to-haves or hypothetical other use-cases for the feature.
So please keep the original use-case in mind when you are commenting on
this and let's not make this into a complex unusable jack of all trades,
but rather keep it as something simple with a small narrow use-case.
I don't think that what I proposed is very complex. If I understand
correctly, it is very similar to what you proposed with the only
difference, that it requires client to do the whole OIDC flow including
code-to-token request and the model is updated in the code-to-token request
rather than before redirecting to client. It has advantages:
- Client is properly authenticated based on the known OIDC flow. Hence no
need to mandatory display consent screen "Application XY wants you to do Z"
- Tokens will be available at the end of the flow with the updated state
(EG. facebook claims or the "email_verified" claim)
Disadvantage is the more complex flow, which means that SPI will need to
maintain state and have the additional method, which will be triggered at
the code-to-token request. That's the only real disadvantage I see, but I
agree that added complexity of the SPI has some price...
I don't want to block the work and hence I am not strongly enforce to
follow my proposal :) Just wanted to propose that and it's up to you guys
if you like it or not.
My point is that you are complicating the flow as well as significantly
complicating the action implementations when there is no need for it to
address the use-case we are considering. id_token_hint as I suggested would
be a much simpler solution that doesn't need a "two phase" action
implementation like what you are suggesting.
On Fri, 22 Mar 2019 at 15:20, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 22/03/2019 12:49, Stian Thorgersen wrote:
>
> To authenticate the client, why don't we just require id_token_hint to be
> included?
>
> We would require the ID token to be issued to the client trying to
> initiate the action and also be associated with the current session.
>
> I'd say we don't need to finely control what clients can do what at least
> not for now. Client should have scope on the manage_account role and that's
> enough for now.
>
> This assumes that client is authenticated before action is triggered.
> Don't we want also a possibility to trigger this "Application Initiated
> Actions" for cases when user is not yet authenticated? For example if I
> have web application, which will be something like "Web Email client", I
> want to ensure that user always has email verified before he is redirected
> to my application as authenticated. So I may want to trigger OIDC flow with
> "kc_action" even before user is authenticated.
>
A few points here:
* AIA are there to specifically run an action, not to request some sort of
condition on the user account. kc_action=verify_email would run the verify
email regardless if email is verified or not.
* AIA are there for an application to allow a user to initiate an action
from within an external app. It's not really there for the app to request
things out of bounds.
Well, that is the question? In current Account management, we show the
link "Link Facebook" just in case that user is not yet linked with
Facebook. Similarly if user is already linked, we display the link "Unlink
Facebook" . It seems to me that people will often do those actions based on
the state of the account (EG. I want to display link "Verify Email" in my
application, just in case that user doesn't yet have verified email).
Application has both the account REST API and the token available to
discover information about the user account. Through account rest it would
discover that Facebook is already linked or not. Hence, you do actually
need to be already logged-in regardless.
Maybe I am wrong and this is not so important, we may see in the
future...
Marek
> Will be also nice for the "Terms and Conditions" actions as the
"Terms
> and Conditions" pages are often client specific, so our current approach
> with generic "Terms and Conditions" action is likely not so nice and
> requires that many application implements some equivalent of app-specific
> "Terms and Conditions" page on their side rather than rely on Keycloak.
But
> with those "Application Initiated Actions" we can improve on here.
>
As far as I know we have never had a request for client specific terms and
conditions. Not sure that is something Keycloak should ever consider,
besides if we did that doesn't need kc_action, but rather just some way to
configure different terms based on the client.
> Marek
>
>
> On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>>
>>
>> On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda(a)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(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
>>>
>>
>