5:01 a.m.
Hi,
I am working on a system where we would like to enforce that for some particular
resources
the resource owner has to authorise each access to such a resource. In other words, we
want
the user to re-type in his username and password each time he executes a particular
operation.
In this context, does Keycloak provide something like 'one-time' access tokens?
Or does it maybe support such a use case in yet another way?
Best regards,
Marcin
The information in this email and any attachments is confidential and intended solely for
the use of the individual(s) to whom it is addressed or otherwise directed.
Please note that any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of the Company.
Finally, the recipient should check this email and any attachments for the presence of
viruses.
The Company accepts no liability for any damage caused by any virus transmitted by this
email.
1:49 a.m.
We are planning to add the ability for an application to require a user to
re-authenticate. There's basically two parts to that. First the token needs
to contain the time the user authenticated, secondly the application needs
to be able to require user login screen to be displayed even if the user is
already authenticated.
Not sure if this is sufficient for your requirements though. I'd probably
rewrite my requirements a bit if I was you and rather than having a
one-time access token require a user to have re-authenticated within a
short time (a few minutes maybe) for sensitive operations.
On 8 September 2016 at 12:01, Wieloch, Marcin <Marcin.Wieloch(a)sicpa.com>
wrote:
Hi,
I am working on a system where we would like to enforce that for some
particular resources
the resource owner has to authorise each access to such a resource. In
other words, we want
the user to re-type in his username and password each time he executes a
particular operation.
In this context, does Keycloak provide something like 'one-time' access
tokens?
Or does it maybe support such a use case in yet another way?
Best regards,
Marcin
------------------------------
The information in this email and any attachments is confidential and
intended solely for the use of the individual(s) to whom it is addressed or
otherwise directed. Please note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of the Company. Finally, the recipient should check this email and
any attachments for the presence of viruses. The Company accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:33 a.m.
Hello,
I think an application should also inspect the "acr" (Authentication
Context Class Reference)
and "amr" (Authentication Methods References) fields of the JWT Payload.
This tell an application how a user authenticated at what "ISO/IEC 29115
Entity Authentication Assurance" level and
which methods were used: (social login, username/password, certificate,
OTP, etc.).
acr
OPTIONAL. Authentication Context Class Reference. String specifying an
Authentication Context Class Reference value that identifies the
Authentication Context Class that the authentication performed satisfied.
The value "0" indicates the End-User authentication did not meet the
requirements of ISO/IEC 29115 [ISO29115] level 1. Authentication using a
long-lived browser cookie, for instance, is one example where the use of
"level 0" is appropriate. Authentications with level 0 SHOULD NOT be used
to authorize access to any resource of any monetary value. (This
corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] nist_auth_level 0.) An
absolute URI or an RFC 6711 [RFC6711] registered name SHOULD be used as the
acr value; registered names MUST NOT be used with a different meaning than
that which is registered. Parties using this claim will need to agree upon
the meanings of the values used, which may be context-specific. The acr
value is a case sensitive string.
amr
OPTIONAL. Authentication Methods References. JSON array of strings that are
identifiers for authentication methods used in the authentication. For
instance, values might indicate that both password and OTP authentication
methods were used. The definition of particular values to be used in the
amr Claim is beyond the scope of this specification. Parties using this
claim will need to agree upon the meanings of the values used, which may be
context-specific. The amr value is an array of case sensitive strings.
See:
http://openid.net/specs/openid-connect-core-1_0.html
Cheers,
Thomas
2016-09-09 8:49 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
We are planning to add the ability for an application to require a
user to
re-authenticate. There's basically two parts to that. First the token needs
to contain the time the user authenticated, secondly the application needs
to be able to require user login screen to be displayed even if the user is
already authenticated.
Not sure if this is sufficient for your requirements though. I'd probably
rewrite my requirements a bit if I was you and rather than having a
one-time access token require a user to have re-authenticated within a
short time (a few minutes maybe) for sensitive operations.
On 8 September 2016 at 12:01, Wieloch, Marcin <Marcin.Wieloch(a)sicpa.com>
wrote:
> Hi,
>
> I am working on a system where we would like to enforce that for some
> particular resources
> the resource owner has to authorise each access to such a resource. In
> other words, we want
> the user to re-type in his username and password each time he executes a
> particular operation.
>
> In this context, does Keycloak provide something like 'one-time' access
> tokens?
> Or does it maybe support such a use case in yet another way?
>
> Best regards,
> Marcin
>
> ------------------------------
> The information in this email and any attachments is confidential and
> intended solely for the use of the individual(s) to whom it is addressed or
> otherwise directed. Please note that any views or opinions presented in
> this email are solely those of the author and do not necessarily represent
> those of the Company. Finally, the recipient should check this email and
> any attachments for the presence of viruses. The Company accepts no
> liability for any damage caused by any virus transmitted by this email.
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3043
days inactive
3044
days old
2 comments
3 participants
participants (3)
-
Stian Thorgersen -
Thomas Darimont -
Wieloch, Marcin