7:11 a.m.
Following up e-mail sent earlier today by Marek, I'm sending info on action tokens.
Action token is a concept intended as a time-boxed ticket for a bearer to perform a single
operation like reset password. They will be used for one-time actions that can be
potentially delayed or executed outside of current authentication flow.
The idea is to implement them as signed JWT tokens where the allowed operation will be
specified in token type field. Action tokens will support expiration definable per action
(different expiration for e.g. verify e-mail and reset password, or customizable
expiration when sent from admin interface). JWT allows both signing and supports custom
fields that can be used by the operation to supply additional arguments and to implement
prevention of reusing the token once the operation would be performed already.
Initially it seemed that a distributed cache would be needed to prevent reusing the token
for the second time. After thinking it over however it turned out that currently all
required cases can be prevented by introducing a field like "last timestamp of the
password change" into a reset password token that is checked and operation is only
allowed if the token value is equal to the one from database.
So far the initial implementation covers token in reset-password e-mail. Cache-independent
version of action tokens is available here [1].
--Hynek
[1]
https://github.com/hmlnarik/keycloak/tree/mposolda--cross-dc2-replaced-hm...
9:38 a.m.
* what if the password isn't stored in Keycloak? What if the password
is stored in an external User Storage Provider?
* Each action token type is going to have to maintain this timestamp thing
* What about verify email or update profile?
* reset-password isn't actually reseting the password. It runs an
authentication flow. This flow could ask for additional information
(i.e. "mother's name, birthday, etc.") It could also reset multiple
credential types beyond password.
* aren't you just replacing dependency on one type of replication (user
session) with another (database)?
* Aren't action tokens supposed to be independent of User sessions anyways?
* How can somebody continue with the login flow with an action token?
Aren't you still going to have to obtain the user session?
I like the idea of action tokens mainly because they can be independent
of a User Session. I just don't think it solves/helps with anything
cross-DC related.
On 3/27/17 8:11 AM, Hynek Mlnarik wrote:
Following up e-mail sent earlier today by Marek, I'm sending info
on action tokens.
Action token is a concept intended as a time-boxed ticket for a bearer to perform a
single operation like reset password. They will be used for one-time actions that can be
potentially delayed or executed outside of current authentication flow.
The idea is to implement them as signed JWT tokens where the allowed operation will be
specified in token type field. Action tokens will support expiration definable per action
(different expiration for e.g. verify e-mail and reset password, or customizable
expiration when sent from admin interface). JWT allows both signing and supports custom
fields that can be used by the operation to supply additional arguments and to implement
prevention of reusing the token once the operation would be performed already.
Initially it seemed that a distributed cache would be needed to prevent reusing the token
for the second time. After thinking it over however it turned out that currently all
required cases can be prevented by introducing a field like "last timestamp of the
password change" into a reset password token that is checked and operation is only
allowed if the token value is equal to the one from database.
So far the initial implementation covers token in reset-password e-mail.
Cache-independent version of action tokens is available here [1].
--Hynek
[1]
https://github.com/hmlnarik/keycloak/tree/mposolda--cross-dc2-replaced-hm...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:29 a.m.
The main idea was to not require action tokens to be one-time, but rather
invalidate when the users state has changed. That way it doesn't matter if
user clicks on the link once or twice all links will still work until the
user changes something. Also, there would be no need to replicate anything
as it's just leveraging data that is already there. Maybe it's not possible
with user storage SPI and custom reset password flows though.
On 27 March 2017 at 16:38, Bill Burke <bburke(a)redhat.com> wrote:
* what if the password isn't stored in Keycloak? What if the
password
is stored in an external User Storage Provider?
Can't you get the last update time for the credentials in an external user
storage provider?
* Each action token type is going to have to maintain this timestamp thing
* What about verify email or update profile?
Verify email can allow verifying the email as long as the token hasn't
expired and the email address hasn't changed. It doesn't have to be a
one-time action.
Update profile would have benefited on having a last updated attribute on
the user model. Would that screw up user storage provider SPI? If we had
that the token would be permitted as long as the user hasn't been updated
since the token was created.
* reset-password isn't actually reseting the password. It runs an
authentication flow. This flow could ask for additional information
(i.e. "mother's name, birthday, etc.") It could also reset multiple
credential types beyond password.
* aren't you just replacing dependency on one type of replication (user
session) with another (database)?
* Aren't action tokens supposed to be independent of User sessions anyways?
* How can somebody continue with the login flow with an action token?
Aren't you still going to have to obtain the user session?
In that case they will open the link in the same browser and the
authentication session will be there.
I like the idea of action tokens mainly because they can be independent
of a User Session. I just don't think it solves/helps with anything
cross-DC related.
It would at least for some things, for example verify email is simple to do
without any need to replicate anything.
On 3/27/17 8:11 AM, Hynek Mlnarik wrote:
> Following up e-mail sent earlier today by Marek, I'm sending info on
action tokens.
>
> Action token is a concept intended as a time-boxed ticket for a bearer
to perform a single operation like reset password. They will be used for
one-time actions that can be potentially delayed or executed outside of
current authentication flow.
>
> The idea is to implement them as signed JWT tokens where the allowed
operation will be specified in token type field. Action tokens will support
expiration definable per action (different expiration for e.g. verify
e-mail and reset password, or customizable expiration when sent from admin
interface). JWT allows both signing and supports custom fields that can be
used by the operation to supply additional arguments and to implement
prevention of reusing the token once the operation would be performed
already.
>
> Initially it seemed that a distributed cache would be needed to prevent
reusing the token for the second time. After thinking it over however it
turned out that currently all required cases can be prevented by
introducing a field like "last timestamp of the password change" into a
reset password token that is checked and operation is only allowed if the
token value is equal to the one from database.
>
> So far the initial implementation covers token in reset-password e-mail.
Cache-independent version of action tokens is available here [1].
>
> --Hynek
>
> [1] https://github.com/hmlnarik/keycloak/tree/mposolda--cross-
dc2-replaced-hmlnariks-commits
> _______________________________________________
> 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
4:56 a.m.
On 03/28/2017 09:29 AM, Stian Thorgersen wrote:
The main idea was to not require action tokens to be one-time, but
rather
invalidate when the users state has changed. That way it doesn't matter if
user clicks on the link once or twice all links will still work until the
user changes something. Also, there would be no need to replicate anything
as it's just leveraging data that is already there. Maybe it's not possible
with user storage SPI and custom reset password flows though.
I have apparently expressed the one-time support of action tokens in the original e-mail
too strongly. What was meant is that action tokens provide means to achieve one-timeness.
However the action tokens just by themselves do not guarantee one-time use. If required,
it is necessary to implement a single-use check in the operation as outlined in the first
thread in this e-mail. E.g. for e-mail verification, this check is not needed, while for
password reset it is.
On 27 March 2017 at 16:38, Bill Burke <bburke(a)redhat.com>
wrote:
> * what if the password isn't stored in Keycloak? What if the password
> is stored in an external User Storage Provider?
>
Can't you get the last update time for the credentials in an external user
storage provider?
>
> * Each action token type is going to have to maintain this timestamp thing
Only those action tokens that are dedicated for single use - and those anyway need to
contain something (be it timestamp, random bytes, ...) that the single-use check has to
verify to prevent reuse of the token.
> * What about verify email or update profile?
Verify email can allow verifying the email as long as the token hasn't
expired and the email address hasn't changed. It doesn't have to be a
one-time action.
Update profile would have benefited on having a last updated attribute on
the user model. Would that screw up user storage provider SPI? If we had
that the token would be permitted as long as the user hasn't been updated
since the token was created.
>
> * reset-password isn't actually reseting the password. It runs an
> authentication flow. This flow could ask for additional information
> (i.e. "mother's name, birthday, etc.") It could also reset multiple
> credential types beyond password.
Absolutely, that's a good point. A reset password action token is actually a
permission to start a reset-password flow for the given user. If user storage provider SPI
supported last updated attribute on user model (does it?), staring the flow would be
allowed only if this attribute on the user (e.g. last updated timestamp) matches the one
from the token. If that were not possible, I believe the same behaviour can be achieved by
introducing a generic attribute on user model that would change once action token is used
and flow finishes. Hence replication would only take place on data change.
> * aren't you just replacing dependency on one type of
replication (user
> session) with another (database)?
Not replacing, rather removing the need to replicate more data than necessary. Database
replication will have to happen on any user change regardless of mechanism allowing that
change, and here it is this mechanism that is being improved.
> * Aren't action tokens supposed to be independent of User
sessions anyways?
> * How can somebody continue with the login flow with an action token?
> Aren't you still going to have to obtain the user session?
Not have to, and yes, I can make use of it to continue in the session in progress.
In that case they will open the link in the same browser and the
authentication session will be there.
>
> I like the idea of action tokens mainly because they can be independent
> of a User Session. I just don't think it solves/helps with anything
> cross-DC related.
>
It would at least for some things, for example verify email is simple to do
without any need to replicate anything.
>
>
> On 3/27/17 8:11 AM, Hynek Mlnarik wrote:
>> Following up e-mail sent earlier today by Marek, I'm sending info on
> action tokens.
>>
>> Action token is a concept intended as a time-boxed ticket for a bearer
> to perform a single operation like reset password. They will be used for
> one-time actions that can be potentially delayed or executed outside of
> current authentication flow.
>>
>> The idea is to implement them as signed JWT tokens where the allowed
> operation will be specified in token type field. Action tokens will support
> expiration definable per action (different expiration for e.g. verify
> e-mail and reset password, or customizable expiration when sent from admin
> interface). JWT allows both signing and supports custom fields that can be
> used by the operation to supply additional arguments and to implement
> prevention of reusing the token once the operation would be performed
> already.
>>
>> Initially it seemed that a distributed cache would be needed to prevent
> reusing the token for the second time. After thinking it over however it
> turned out that currently all required cases can be prevented by
> introducing a field like "last timestamp of the password change" into a
> reset password token that is checked and operation is only allowed if the
> token value is equal to the one from database.
>>
>> So far the initial implementation covers token in reset-password e-mail.
> Cache-independent version of action tokens is available here [1].
>>
>> --Hynek
>>
>> [1] https://github.com/hmlnarik/keycloak/tree/mposolda--cross-
> dc2-replaced-hmlnariks-commits
>> _______________________________________________
>> 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
8:25 a.m.
IMO, action tokens should be implemented correctly, as a feature, not as
an optimization to support cross-DC. This means support for one time
use policies, etc.
On 3/28/17 5:56 AM, Hynek Mlnarik wrote:
>> * Aren't action tokens supposed to be independent of User sessions
>> anyways?
>> * How can somebody continue with the login flow with an action token?
>> Aren't you still going to have to obtain the user session?
Not have to, and yes, I can make use of it to continue in the session
in progress.
I'm saying do you have to/should you verify that the action token
originated from a specific session in order to continue the session? I
don't know, just asking. These are all things you have to take into
account and figure out how to easily hide or provide through the
Authentication/Required Action SPI too.
Bill
8:46 a.m.
On Tue, Mar 28, 2017 at 3:25 PM, Bill Burke <bburke(a)redhat.com> wrote:
IMO, action tokens should be implemented correctly, as a feature, not
as an
optimization to support cross-DC. This means support for one time use
policies, etc.
Okay, it seems that support for single use should be implemented as a
service and then used by action tokens.
So this can be implemented as a cache that would be shared across the
cluster / DCs with as little information as possible. Preliminary
implementation exists in [1], I'll plug that into current code.
[1] https://github.com/keycloak/keycloak/pull/3918
On 3/28/17 5:56 AM, Hynek Mlnarik wrote:
>
>
>>> * Aren't action tokens supposed to be independent of User sessions
>>> anyways?
>>> * How can somebody continue with the login flow with an action token?
>>> Aren't you still going to have to obtain the user session?
>
>
> Not have to, and yes, I can make use of it to continue in the session in
> progress.
I'm saying do you have to/should you verify that the action token originated
from a specific session in order to continue the session? I don't know,
just asking. These are all things you have to take into account and figure
out how to easily hide or provide through the Authentication/Required Action
SPI too.
I don't think I have to (for instance expiration of the action token
to reset password can be e.g. 2 days - much longer than that of a
session). But I think that we should support case when the user is in
the middle of the flow and is asked to verify their e-mail - here we
should continue with the next step in the flow.
--Hynek
2:17 a.m.
I was thinking if we can have the variant of the interactive email
verification flows ("interactive" means those not triggered by admin,
but by user himself during authentication process) like this:
- User triggers the flow (For example by click "Forget password" on
login screen in case of reset-password. Other actions like
identity-broker linking verification are triggered automatically during
authentication flow etc)
- Browser displays "We just sent you an email with the generated code.
Please type this code here: ". The input field will be displayed too.
- Email doesn't contain any link. Just the generated code. User needs to
copy/paste it to the field in the browser and after submit, the flow
continues.
Advantages:
- No need to care about spam filters. As no link in the email
- No need to care if it's same or different browser. Flow will always
continue in same browser
- Cross-dc solved. It would be always same browser, so we just need to
keep the code in authentication session. No action-tokens or any
cross-dc replication needed
Does it sucks from the usability perspective? For me personally not, as
when I need to deal with some web-page, which sends me those
verification emails, I usually just copy/paste the link into the browser
instead of directly clicking on it (yes, because I don't know in which
browser it will be opened and I usually want to continue in the same
browser).
We will still need action-tokens for the admin actions though. For the
interactive actions, admin will have possibility to choose if he wants
action-tokens (with link in the email etc) or this optimized flow. I can
see this can help with spam, cross-dc performance, so IMO makes sense
for some deployments.
Marek
On 28/03/17 15:46, Hynek Mlnarik wrote:
On Tue, Mar 28, 2017 at 3:25 PM, Bill Burke <bburke(a)redhat.com>
wrote:
> IMO, action tokens should be implemented correctly, as a feature, not as an
> optimization to support cross-DC. This means support for one time use
> policies, etc.
Okay, it seems that support for single use should be implemented as a
service and then used by action tokens.
So this can be implemented as a cache that would be shared across the
cluster / DCs with as little information as possible. Preliminary
implementation exists in [1], I'll plug that into current code.
[1] https://github.com/keycloak/keycloak/pull/3918
> On 3/28/17 5:56 AM, Hynek Mlnarik wrote:
>>
>>>> * Aren't action tokens supposed to be independent of User sessions
>>>> anyways?
>>>> * How can somebody continue with the login flow with an action token?
>>>> Aren't you still going to have to obtain the user session?
>>
>> Not have to, and yes, I can make use of it to continue in the session in
>> progress.
>
> I'm saying do you have to/should you verify that the action token originated
> from a specific session in order to continue the session? I don't know,
> just asking. These are all things you have to take into account and figure
> out how to easily hide or provide through the Authentication/Required Action
> SPI too.
I don't think I have to (for instance expiration of the action token
to reset password can be e.g. 2 days - much longer than that of a
session). But I think that we should support case when the user is in
the middle of the flow and is asked to verify their e-mail - here we
should continue with the next step in the flow.
--Hynek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:04 a.m.
I can see the benefits in cross-dc, but I'm not convinced due to the
following disadvantages:
* It would change the current behaviour
* It would need different implementation if the action was triggered by a
user or an admin
* Users would see different behaviour depending on who triggered the action
Personally I don't like the copy/pasting approaches and much prefer simply
clicking on a link.
On 31 March 2017 at 09:17, Marek Posolda <mposolda(a)redhat.com> wrote:
I was thinking if we can have the variant of the interactive email
verification flows ("interactive" means those not triggered by admin,
but by user himself during authentication process) like this:
- User triggers the flow (For example by click "Forget password" on
login screen in case of reset-password. Other actions like
identity-broker linking verification are triggered automatically during
authentication flow etc)
- Browser displays "We just sent you an email with the generated code.
Please type this code here: ". The input field will be displayed too.
- Email doesn't contain any link. Just the generated code. User needs to
copy/paste it to the field in the browser and after submit, the flow
continues.
Advantages:
- No need to care about spam filters. As no link in the email
- No need to care if it's same or different browser. Flow will always
continue in same browser
- Cross-dc solved. It would be always same browser, so we just need to
keep the code in authentication session. No action-tokens or any
cross-dc replication needed
Does it sucks from the usability perspective? For me personally not, as
when I need to deal with some web-page, which sends me those
verification emails, I usually just copy/paste the link into the browser
instead of directly clicking on it (yes, because I don't know in which
browser it will be opened and I usually want to continue in the same
browser).
We will still need action-tokens for the admin actions though. For the
interactive actions, admin will have possibility to choose if he wants
action-tokens (with link in the email etc) or this optimized flow. I can
see this can help with spam, cross-dc performance, so IMO makes sense
for some deployments.
Marek
On 28/03/17 15:46, Hynek Mlnarik wrote:
> On Tue, Mar 28, 2017 at 3:25 PM, Bill Burke <bburke(a)redhat.com> wrote:
>> IMO, action tokens should be implemented correctly, as a feature, not
as an
>> optimization to support cross-DC. This means support for one time use
>> policies, etc.
> Okay, it seems that support for single use should be implemented as a
> service and then used by action tokens.
>
> So this can be implemented as a cache that would be shared across the
> cluster / DCs with as little information as possible. Preliminary
> implementation exists in [1], I'll plug that into current code.
>
> [1] https://github.com/keycloak/keycloak/pull/3918
>
>> On 3/28/17 5:56 AM, Hynek Mlnarik wrote:
>>>
>>>>> * Aren't action tokens supposed to be independent of User
sessions
>>>>> anyways?
>>>>> * How can somebody continue with the login flow with an action
token?
>>>>> Aren't you still going to have to obtain the user session?
>>>
>>> Not have to, and yes, I can make use of it to continue in the session
in
>>> progress.
>>
>> I'm saying do you have to/should you verify that the action token
originated
>> from a specific session in order to continue the session? I don't know,
>> just asking. These are all things you have to take into account and
figure
>> out how to easily hide or provide through the Authentication/Required
Action
>> SPI too.
> I don't think I have to (for instance expiration of the action token
> to reset password can be e.g. 2 days - much longer than that of a
> session). But I think that we should support case when the user is in
> the middle of the flow and is asked to verify their e-mail - here we
> should continue with the next step in the flow.
>
> --Hynek
> _______________________________________________
> 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
8:11 a.m.
I implemented it this way initially with the Auth SPI rewrite and was
vetoed.
Personally I dont like the link because it opens up a new browser tab or
window. Plus with the code approach there's no way an attacker can
spoof the url and send people rogue emails. But, the link approach is
better if I'm on a mobile device.
On 3/31/17 3:17 AM, Marek Posolda wrote:
I was thinking if we can have the variant of the interactive email
verification flows ("interactive" means those not triggered by admin,
but by user himself during authentication process) like this:
- User triggers the flow (For example by click "Forget password" on
login screen in case of reset-password. Other actions like
identity-broker linking verification are triggered automatically
during authentication flow etc)
- Browser displays "We just sent you an email with the generated code.
Please type this code here: ". The input field will be displayed too.
- Email doesn't contain any link. Just the generated code. User needs
to copy/paste it to the field in the browser and after submit, the
flow continues.
Advantages:
- No need to care about spam filters. As no link in the email
- No need to care if it's same or different browser. Flow will always
continue in same browser
- Cross-dc solved. It would be always same browser, so we just need to
keep the code in authentication session. No action-tokens or any
cross-dc replication needed
Does it sucks from the usability perspective? For me personally not,
as when I need to deal with some web-page, which sends me those
verification emails, I usually just copy/paste the link into the
browser instead of directly clicking on it (yes, because I don't know
in which browser it will be opened and I usually want to continue in
the same browser).
We will still need action-tokens for the admin actions though. For the
interactive actions, admin will have possibility to choose if he wants
action-tokens (with link in the email etc) or this optimized flow. I
can see this can help with spam, cross-dc performance, so IMO makes
sense for some deployments.
Marek
On 28/03/17 15:46, Hynek Mlnarik wrote:
> On Tue, Mar 28, 2017 at 3:25 PM, Bill Burke <bburke(a)redhat.com> wrote:
>> IMO, action tokens should be implemented correctly, as a feature,
>> not as an
>> optimization to support cross-DC. This means support for one time use
>> policies, etc.
> Okay, it seems that support for single use should be implemented as a
> service and then used by action tokens.
>
> So this can be implemented as a cache that would be shared across the
> cluster / DCs with as little information as possible. Preliminary
> implementation exists in [1], I'll plug that into current code.
>
> [1] https://github.com/keycloak/keycloak/pull/3918
>
>> On 3/28/17 5:56 AM, Hynek Mlnarik wrote:
>>>
>>>>> * Aren't action tokens supposed to be independent of User
sessions
>>>>> anyways?
>>>>> * How can somebody continue with the login flow with an action
>>>>> token?
>>>>> Aren't you still going to have to obtain the user session?
>>>
>>> Not have to, and yes, I can make use of it to continue in the
>>> session in
>>> progress.
>>
>> I'm saying do you have to/should you verify that the action token
>> originated
>> from a specific session in order to continue the session? I don't
>> know,
>> just asking. These are all things you have to take into account and
>> figure
>> out how to easily hide or provide through the
>> Authentication/Required Action
>> SPI too.
> I don't think I have to (for instance expiration of the action token
> to reset password can be e.g. 2 days - much longer than that of a
> session). But I think that we should support case when the user is in
> the middle of the flow and is asked to verify their e-mail - here we
> should continue with the next step in the flow.
>
> --Hynek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:46 a.m.
Ah, yes. Copy-paste would suck on mobile.
It seems that we need to support action-tokens anyway, but I was
thinking about the "copy-paste" approach as an option, which would admin
enable if he wants to optimize cross-dc performance and avoid issues
with spam filters. Hopefully it would be possible to have an
abstraction, which would allow authenticators to easily use either the
first or second approach.
But not sure it makes sense as usability on mobiles looks like a blocker...
Marek
On 31/03/17 15:11, Bill Burke wrote:
I implemented it this way initially with the Auth SPI rewrite and was
vetoed.
Personally I dont like the link because it opens up a new browser tab
or window. Plus with the code approach there's no way an attacker
can spoof the url and send people rogue emails. But, the link
approach is better if I'm on a mobile device.
On 3/31/17 3:17 AM, Marek Posolda wrote:
> I was thinking if we can have the variant of the interactive email
> verification flows ("interactive" means those not triggered by admin,
> but by user himself during authentication process) like this:
>
> - User triggers the flow (For example by click "Forget password" on
> login screen in case of reset-password. Other actions like
> identity-broker linking verification are triggered automatically
> during authentication flow etc)
> - Browser displays "We just sent you an email with the generated
> code. Please type this code here: ". The input field will be
> displayed too.
> - Email doesn't contain any link. Just the generated code. User needs
> to copy/paste it to the field in the browser and after submit, the
> flow continues.
>
> Advantages:
> - No need to care about spam filters. As no link in the email
> - No need to care if it's same or different browser. Flow will always
> continue in same browser
> - Cross-dc solved. It would be always same browser, so we just need
> to keep the code in authentication session. No action-tokens or any
> cross-dc replication needed
>
> Does it sucks from the usability perspective? For me personally not,
> as when I need to deal with some web-page, which sends me those
> verification emails, I usually just copy/paste the link into the
> browser instead of directly clicking on it (yes, because I don't know
> in which browser it will be opened and I usually want to continue in
> the same browser).
>
> We will still need action-tokens for the admin actions though. For
> the interactive actions, admin will have possibility to choose if he
> wants action-tokens (with link in the email etc) or this optimized
> flow. I can see this can help with spam, cross-dc performance, so IMO
> makes sense for some deployments.
>
> Marek
>
>
> On 28/03/17 15:46, Hynek Mlnarik wrote:
>> On Tue, Mar 28, 2017 at 3:25 PM, Bill Burke <bburke(a)redhat.com> wrote:
>>> IMO, action tokens should be implemented correctly, as a feature,
>>> not as an
>>> optimization to support cross-DC. This means support for one time use
>>> policies, etc.
>> Okay, it seems that support for single use should be implemented as a
>> service and then used by action tokens.
>>
>> So this can be implemented as a cache that would be shared across the
>> cluster / DCs with as little information as possible. Preliminary
>> implementation exists in [1], I'll plug that into current code.
>>
>> [1] https://github.com/keycloak/keycloak/pull/3918
>>
>>> On 3/28/17 5:56 AM, Hynek Mlnarik wrote:
>>>>
>>>>>> * Aren't action tokens supposed to be independent of User
sessions
>>>>>> anyways?
>>>>>> * How can somebody continue with the login flow with an action
>>>>>> token?
>>>>>> Aren't you still going to have to obtain the user session?
>>>>
>>>> Not have to, and yes, I can make use of it to continue in the
>>>> session in
>>>> progress.
>>>
>>> I'm saying do you have to/should you verify that the action token
>>> originated
>>> from a specific session in order to continue the session? I don't
>>> know,
>>> just asking. These are all things you have to take into account
>>> and figure
>>> out how to easily hide or provide through the
>>> Authentication/Required Action
>>> SPI too.
>> I don't think I have to (for instance expiration of the action token
>> to reset password can be e.g. 2 days - much longer than that of a
>> session). But I think that we should support case when the user is in
>> the middle of the flow and is asked to verify their e-mail - here we
>> should continue with the next step in the flow.
>>
>> --Hynek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
8:13 a.m.
On 3/28/17 3:29 AM, Stian Thorgersen wrote:
The main idea was to not require action tokens to be one-time, but
rather invalidate when the users state has changed. That way it
doesn't matter if user clicks on the link once or twice all links will
still work until the user changes something. Also, there would be no
need to replicate anything as it's just leveraging data that is
already there. Maybe it's not possible with user storage SPI and
custom reset password flows though.
On 27 March 2017 at 16:38, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
* what if the password isn't stored in Keycloak? What if the password
is stored in an external User Storage Provider?
Can't you get the last update time for the credentials in an external
user storage provider?
Maybe. Maybe not. Who knows? We won't.
* Each action token type is going to have to maintain this
timestamp thing
* What about verify email or update profile?
Verify email can allow verifying the email as long as the token hasn't
expired and the email address hasn't changed. It doesn't have to be a
one-time action.
Update profile would have benefited on having a last updated attribute
on the user model. Would that screw up user storage provider SPI? If
we had that the token would be permitted as long as the user hasn't
been updated since the token was created.
Some storage providers are either
read-only or can only write a specific
set of attributes.
FYI: We already store user consent and account links no matter which
provider is providing user info.
* reset-password isn't actually reseting the password. It runs an
authentication flow. This flow could ask for additional information
(i.e. "mother's name, birthday, etc.") It could also reset multiple
credential types beyond password.
* aren't you just replacing dependency on one type of replication
(user
session) with another (database)?
* Aren't action tokens supposed to be independent of User sessions
anyways?
* How can somebody continue with the login flow with an action token?
Aren't you still going to have to obtain the user session?
In that case they will open the link in the same browser and the
authentication session will be there.
You still need some sort of session for reset-credential flow.
I like the idea of action tokens mainly because they can be
independent
of a User Session. I just don't think it solves/helps with anything
cross-DC related.
It would at least for some things, for example verify email is simple
to do without any need to replicate anything.
We have custom required actions. The
SPI will now have to provide
metadata on whether the action requires the update timestamp or not.
Bill
2593
days inactive
2597
days old
10 comments
4 participants
participants (4)
-
Bill Burke -
Hynek Mlnarik -
Marek Posolda -
Stian Thorgersen