11:02 p.m.
Clients should be able to obtain tokens with reduced scope and longer or
shorter expiration, then later request new tokens with increased scope and
different expiration. They should also be able to require different levels
of authentication and also require re-authentication.
An application may for example:
* At first only need users email - this would allow showing the name +
email. In this situation a long expiration access token in combination with
implicit flow would do. It's also not necessary to re-authenticate the user
and a user that has been logged-in for months or even a year is fine.
* When a user clicks on orders it would require the password and extend
scope to be able to view orders. Now you'll want to switch to short
expiration access tokens and authorization code grant. You'll also want to
make sure the user logged-in fairly recently, max 30 days could be sensible.
* When a user tries to purchase something the user now has to provide the
OTP to be able to purchase with saved credit card details. You'll also want
to make sure the user logged-in very recently, max a day could be required.
There may also be cases where you always want the user to re-authenticate,
for example when trying to purchase something over a certain price level.
9:19 a.m.
Sounds great. I hope we don't have to implement this for SAML too ;)
On 4/29/2016 12:02 AM, Stian Thorgersen wrote:
Clients should be able to obtain tokens with reduced scope and longer
or shorter expiration, then later request new tokens with increased
scope and different expiration. They should also be able to require
different levels of authentication and also require re-authentication.
An application may for example:
* At first only need users email - this would allow showing the name +
email. In this situation a long expiration access token in combination
with implicit flow would do. It's also not necessary to
re-authenticate the user and a user that has been logged-in for months
or even a year is fine.
* When a user clicks on orders it would require the password and
extend scope to be able to view orders. Now you'll want to switch to
short expiration access tokens and authorization code grant. You'll
also want to make sure the user logged-in fairly recently, max 30 days
could be sensible.
* When a user tries to purchase something the user now has to provide
the OTP to be able to purchase with saved credit card details. You'll
also want to make sure the user logged-in very recently, max a day
could be required. There may also be cases where you always want the
user to re-authenticate, for example when trying to purchase something
over a certain price level.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:56 a.m.
Wouldn't saml support it fairly easily? It's just another auth request with
SE different params?
On 29 Apr 2016 16:19, "Bill Burke" <bburke(a)redhat.com> wrote:
Sounds great. I hope we don't have to implement this for SAML
too ;)
On 4/29/2016 12:02 AM, Stian Thorgersen wrote:
Clients should be able to obtain tokens with reduced scope and longer or
shorter expiration, then later request new tokens with increased scope and
different expiration. They should also be able to require different levels
of authentication and also require re-authentication.
An application may for example:
* At first only need users email - this would allow showing the name +
email. In this situation a long expiration access token in combination with
implicit flow would do. It's also not necessary to re-authenticate the user
and a user that has been logged-in for months or even a year is fine.
* When a user clicks on orders it would require the password and extend
scope to be able to view orders. Now you'll want to switch to short
expiration access tokens and authorization code grant. You'll also want to
make sure the user logged-in fairly recently, max 30 days could be sensible.
* When a user tries to purchase something the user now has to provide the
OTP to be able to purchase with saved credit card details. You'll also want
to make sure the user logged-in very recently, max a day could be required.
There may also be cases where you always want the user to re-authenticate,
for example when trying to purchase something over a certain price level.
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:54 a.m.
I have no idea. What you are describing is different. Its scope, SAML
probably has it, but I don't know what it is. You also describe a token
exchange service
On 5/2/2016 4:56 AM, Stian Thorgersen wrote:
Wouldn't saml support it fairly easily? It's just another auth request
with SE different params?
On 29 Apr 2016 16:19, "Bill Burke" <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Sounds great. I hope we don't have to implement this for SAML too ;)
On 4/29/2016 12:02 AM, Stian Thorgersen wrote:
> Clients should be able to obtain tokens with reduced scope and
> longer or shorter expiration, then later request new tokens with
> increased scope and different expiration. They should also be
> able to require different levels of authentication and also
> require re-authentication.
>
> An application may for example:
>
> * At first only need users email - this would allow showing the
> name + email. In this situation a long expiration access token in
> combination with implicit flow would do. It's also not necessary
> to re-authenticate the user and a user that has been logged-in
> for months or even a year is fine.
>
> * When a user clicks on orders it would require the password and
> extend scope to be able to view orders. Now you'll want to switch
> to short expiration access tokens and authorization code grant.
> You'll also want to make sure the user logged-in fairly recently,
> max 30 days could be sensible.
>
> * When a user tries to purchase something the user now has to
> provide the OTP to be able to purchase with saved credit card
> details. You'll also want to make sure the user logged-in very
> recently, max a day could be required. There may also be cases
> where you always want the user to re-authenticate, for example
> when trying to purchase something over a certain price level.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:10 a.m.
I wasn't thinking a token exchange, I was thinking it would just do a new
authentication request with different scope, etc..
On 2 May 2016 at 14:54, Bill Burke <bburke(a)redhat.com> wrote:
I have no idea. What you are describing is different. Its scope,
SAML
probably has it, but I don't know what it is. You also describe a token
exchange service
On 5/2/2016 4:56 AM, Stian Thorgersen wrote:
Wouldn't saml support it fairly easily? It's just another auth request
with SE different params?
On 29 Apr 2016 16:19, "Bill Burke" <
<bburke@redhat.com>bburke(a)redhat.com>
wrote:
> Sounds great. I hope we don't have to implement this for SAML too ;)
>
> On 4/29/2016 12:02 AM, Stian Thorgersen wrote:
>
> Clients should be able to obtain tokens with reduced scope and longer or
> shorter expiration, then later request new tokens with increased scope and
> different expiration. They should also be able to require different levels
> of authentication and also require re-authentication.
>
> An application may for example:
>
> * At first only need users email - this would allow showing the name +
> email. In this situation a long expiration access token in combination with
> implicit flow would do. It's also not necessary to re-authenticate the user
> and a user that has been logged-in for months or even a year is fine.
>
> * When a user clicks on orders it would require the password and extend
> scope to be able to view orders. Now you'll want to switch to short
> expiration access tokens and authorization code grant. You'll also want to
> make sure the user logged-in fairly recently, max 30 days could be sensible.
>
> * When a user tries to purchase something the user now has to provide the
> OTP to be able to purchase with saved credit card details. You'll also want
> to make sure the user logged-in very recently, max a day could be required.
> There may also be cases where you always want the user to re-authenticate,
> for example when trying to purchase something over a certain price level.
>
>
> _______________________________________________
> keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
8:05 a.m.
New subject: Thinking about step-up authentication and token timeouts
----- Original Message -----
From: "Stian Thorgersen" <sthorger(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: "keycloak-dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, May 2, 2016 10:10:57 AM
Subject: Re: [keycloak-dev] Thinking about step-up authentication and token timeouts
I wasn't thinking a token exchange, I was thinking it would just do a new
authentication request with different scope, etc..
AFAIK ...
In SAML, AuthnRequest may have a ForceAuthn attribute set to true to indicate that IdP
must authenticate the presenter directly rather than
rely on a previous security context.
There is also a RequestedAuthnContext that can be used to specify an "authentication
class" pretty much like the "acr_values" in a OIDC Authentication Request.
On 2 May 2016 at 14:54, Bill Burke < bburke(a)redhat.com > wrote:
I have no idea. What you are describing is different. Its scope, SAML
probably has it, but I don't know what it is. You also describe a token
exchange service
On 5/2/2016 4:56 AM, Stian Thorgersen wrote:
Wouldn't saml support it fairly easily? It's just another auth request with
SE different params?
On 29 Apr 2016 16:19, "Bill Burke" < bburke(a)redhat.com > wrote:
Sounds great. I hope we don't have to implement this for SAML too ;)
On 4/29/2016 12:02 AM, Stian Thorgersen wrote:
Clients should be able to obtain tokens with reduced scope and longer or
shorter expiration, then later request new tokens with increased scope and
different expiration. They should also be able to require different levels
of authentication and also require re-authentication.
An application may for example:
* At first only need users email - this would allow showing the name + email.
In this situation a long expiration access token in combination with
implicit flow would do. It's also not necessary to re-authenticate the user
and a user that has been logged-in for months or even a year is fine.
* When a user clicks on orders it would require the password and extend scope
to be able to view orders. Now you'll want to switch to short expiration
access tokens and authorization code grant. You'll also want to make sure
the user logged-in fairly recently, max 30 days could be sensible.
* When a user tries to purchase something the user now has to provide the OTP
to be able to purchase with saved credit card details. You'll also want to
make sure the user logged-in very recently, max a day could be required.
There may also be cases where you always want the user to re-authenticate,
for example when trying to purchase something over a certain price level.
_______________________________________________
keycloak-dev mailing list keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3159
days inactive
3163
days old
5 comments
3 participants
participants (3)
-
Bill Burke -
Pedro Igor Silva -
Stian Thorgersen