1:23 p.m.
Hi,
KEYCLOAK-996 is about allowing clients to select an existing identity provider when
sending an authentication request to the server. Initially, this is all about passing the
IdP id and automatically redirect the user to its login page. Without even show KC's
login page.
IMO instead of using an "idp_hint", like proposed in that JIRA, we may start
using the "acr_values" parameter as defined by OIDC specs. I think this
parameter better fits the purpose and will allow us to support LoAs in the future as
well.
The acr value in this case would be something like "idp-X", where X is the
id of the identity provider.
What do you think ?
Regards.
Pedro Igor
1:18 a.m.
Can you elaborate a bit more on the idea? At first glance to me it seems like we'd use
one field for two quite different purposes. Level of assurance is abstract (level 0, 1,
2), while authentication mechanism is more concrete (idp-a, password, totp). I think an
application might want to request level-1, but not care about mechanism used, while
another application would want to select idp-a, but not care about the level of
assurance.
----- Original Message -----
From: "Pedro Igor Silva" <psilva(a)redhat.com>
To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Friday, January 23, 2015 8:23:19 PM
Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
Hi,
KEYCLOAK-996 is about allowing clients to select an existing identity
provider when sending an authentication request to the server.
Initially, this is all about passing the IdP id and automatically
redirect the user to its login page. Without even show KC's login page.
IMO instead of using an "idp_hint", like proposed in that JIRA, we may
start using the "acr_values" parameter as defined by OIDC specs. I think
this parameter better fits the purpose and will allow us to support LoAs
in the future as well.
The acr value in this case would be something like "idp-X", where X is
the id of the identity provider.
What do you think ?
Regards.
Pedro Igor
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:54 a.m.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, January 26, 2015 5:18:14 AM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
Can you elaborate a bit more on the idea? At first glance to me it seems like
we'd use one field for two quite different purposes. Level of assurance is
abstract (level 0, 1, 2), while authentication mechanism is more concrete
(idp-a, password, totp). I think an application might want to request
level-1, but not care about mechanism used, while another application would
want to select idp-a, but not care about the level of assurance.
I understand your point. You are basically talking about "acr" and
"amr" fields of id_token.
After reading a little bit more about the meaning of both fields, I realized that acr
provides more meaning than amr. The reason is that you would prefer a "context"
than rely on specific authentication mechanisms in order to do access decisions. For
instance, SAML provides something similar to amr and for some people that is one of the
SAML specs mistakes. And there are discussions on OIDC mailing lists about the real value
of "amr".
IMO, makes much more sense to rely on the context used to authenticate the user than on an
individual (or multiple) authentication mechanism. You can use the context for that in a
more meaningful (and abstract) way. In the case we are discussing, users can specify that
an "authentication context" is related with trusting identities from an external
IdP.
In the future, we may even let users create their own "authentication context"
by chaining authentication mechanisms. For instance, password + otp. IMO, is much better
to use a single value like acme-loa-1, which means password + otp, than check for
individual mechanisms.
Regarding the value, I think we can use anything we want as along as all parties agree on
the values being used.
----- Original Message -----
> From: "Pedro Igor Silva" <psilva(a)redhat.com>
> To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> Sent: Friday, January 23, 2015 8:23:19 PM
> Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> provider
>
> Hi,
>
> KEYCLOAK-996 is about allowing clients to select an existing identity
> provider when sending an authentication request to the server.
> Initially, this is all about passing the IdP id and automatically
> redirect the user to its login page. Without even show KC's login page.
>
> IMO instead of using an "idp_hint", like proposed in that JIRA, we
may
> start using the "acr_values" parameter as defined by OIDC specs. I
> think
> this parameter better fits the purpose and will allow us to support
> LoAs
> in the future as well.
>
> The acr value in this case would be something like "idp-X", where X
is
> the id of the identity provider.
>
> What do you think ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
7:35 a.m.
Reading the spec, although they don't exactly give much detail on this, but my
understanding is:
* acr - abstract level of assurance, exactly how the levels are defined I don't know,
but I would imagine they'd have values 1-10 or somthing. You could then define
what's required for each value. For example 0 is just authenticated somehow, 1 is
either password+totp or my-corp-idp
* amr - is a concrete list of mechanisms used, so examples would be 'totp
password' or 'my-corp-id'
From your previous email I'm a bit unsure if you're still
proposing to use acr_values or not, but to me it doesn't make sense have
?acr_values=my-corp-idp. If there was an amr_values param that would make more sense.
----- Original Message -----
From: "Pedro Igor Silva" <psilva(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, January 26, 2015 12:54:38 PM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>
> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> Sent: Monday, January 26, 2015 5:18:14 AM
> Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> provider
>
> Can you elaborate a bit more on the idea? At first glance to me it seems
> like
> we'd use one field for two quite different purposes. Level of assurance is
> abstract (level 0, 1, 2), while authentication mechanism is more concrete
> (idp-a, password, totp). I think an application might want to request
> level-1, but not care about mechanism used, while another application would
> want to select idp-a, but not care about the level of assurance.
I understand your point. You are basically talking about "acr" and
"amr"
fields of id_token.
After reading a little bit more about the meaning of both fields, I realized
that acr provides more meaning than amr. The reason is that you would prefer
a "context" than rely on specific authentication mechanisms in order to do
access decisions. For instance, SAML provides something similar to amr and
for some people that is one of the SAML specs mistakes. And there are
discussions on OIDC mailing lists about the real value of "amr".
IMO, makes much more sense to rely on the context used to authenticate the
user than on an individual (or multiple) authentication mechanism. You can
use the context for that in a more meaningful (and abstract) way. In the
case we are discussing, users can specify that an "authentication context"
is related with trusting identities from an external IdP.
In the future, we may even let users create their own "authentication
context" by chaining authentication mechanisms. For instance, password +
otp. IMO, is much better to use a single value like acme-loa-1, which means
password + otp, than check for individual mechanisms.
Regarding the value, I think we can use anything we want as along as all
parties agree on the values being used.
>
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva(a)redhat.com>
> > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> > Sent: Friday, January 23, 2015 8:23:19 PM
> > Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > provider
> >
> > Hi,
> >
> > KEYCLOAK-996 is about allowing clients to select an existing identity
> > provider when sending an authentication request to the server.
> > Initially, this is all about passing the IdP id and automatically
> > redirect the user to its login page. Without even show KC's login
> > page.
> >
> > IMO instead of using an "idp_hint", like proposed in that JIRA,
we
> > may
> > start using the "acr_values" parameter as defined by OIDC specs.
I
> > think
> > this parameter better fits the purpose and will allow us to support
> > LoAs
> > in the future as well.
> >
> > The acr value in this case would be something like "idp-X", where
X
> > is
> > the id of the identity provider.
> >
> > What do you think ?
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
8:33 a.m.
I'm still proposing acr_values, which is related with the acr claim within the
id_token.
Regarding the value, my understanding is that you are not tied with numeric values, but
you can have anything (specs says URIs) as long as both parties agree on the values in
use.
For me, authentication context is all about how the user was authenticated. And use that
info to make access decision. For instance, when authenticating against a trusted IdP I
don't care how the user is authenticated. What I care is that the IdP really
authenticated the user and I trust it. Based on that, my app may protect (or not) specific
resources based on the context the user was authenticated.
I don't think amr_values makes sense to request specific mechanisms. As I said, acr is
enough to specify one or multiple mechanisms in a more meaningful (and abstract) way
without rely on a specific mech. Something like an alias.
Suppose my company defines that acme-authc-1 is password-based authc. But new policies
were defined and require that acme-authc-1 should be passord + otp. Apps don't have to
change if they rely on this context. Now, if you use rely on specific mechanisms, your
apps should check each of them. And in this case, they would need to change in order to
also consider the otp mech.
Beside that, that opens a window to provide useful features in KeyCloak (in the future :))
regarding all that.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, January 26, 2015 11:35:01 AM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
Reading the spec, although they don't exactly give much detail on this, but my
understanding is:
* acr - abstract level of assurance, exactly how the levels are defined I don't know,
but I would imagine they'd have values 1-10 or somthing. You could then define
what's required for each value. For example 0 is just authenticated somehow, 1 is
either password+totp or my-corp-idp
* amr - is a concrete list of mechanisms used, so examples would be 'totp
password' or 'my-corp-id'
From your previous email I'm a bit unsure if you're still
proposing to use acr_values or not, but to me it doesn't make sense have
?acr_values=my-corp-idp. If there was an amr_values param that would make more sense.
----- Original Message -----
From: "Pedro Igor Silva" <psilva(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, January 26, 2015 12:54:38 PM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>
> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> Sent: Monday, January 26, 2015 5:18:14 AM
> Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> provider
>
> Can you elaborate a bit more on the idea? At first glance to me it seems
> like
> we'd use one field for two quite different purposes. Level of assurance is
> abstract (level 0, 1, 2), while authentication mechanism is more concrete
> (idp-a, password, totp). I think an application might want to request
> level-1, but not care about mechanism used, while another application would
> want to select idp-a, but not care about the level of assurance.
I understand your point. You are basically talking about "acr" and
"amr"
fields of id_token.
After reading a little bit more about the meaning of both fields, I realized
that acr provides more meaning than amr. The reason is that you would prefer
a "context" than rely on specific authentication mechanisms in order to do
access decisions. For instance, SAML provides something similar to amr and
for some people that is one of the SAML specs mistakes. And there are
discussions on OIDC mailing lists about the real value of "amr".
IMO, makes much more sense to rely on the context used to authenticate the
user than on an individual (or multiple) authentication mechanism. You can
use the context for that in a more meaningful (and abstract) way. In the
case we are discussing, users can specify that an "authentication context"
is related with trusting identities from an external IdP.
In the future, we may even let users create their own "authentication
context" by chaining authentication mechanisms. For instance, password +
otp. IMO, is much better to use a single value like acme-loa-1, which means
password + otp, than check for individual mechanisms.
Regarding the value, I think we can use anything we want as along as all
parties agree on the values being used.
>
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva(a)redhat.com>
> > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> > Sent: Friday, January 23, 2015 8:23:19 PM
> > Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > provider
> >
> > Hi,
> >
> > KEYCLOAK-996 is about allowing clients to select an existing identity
> > provider when sending an authentication request to the server.
> > Initially, this is all about passing the IdP id and automatically
> > redirect the user to its login page. Without even show KC's login
> > page.
> >
> > IMO instead of using an "idp_hint", like proposed in that JIRA,
we
> > may
> > start using the "acr_values" parameter as defined by OIDC specs.
I
> > think
> > this parameter better fits the purpose and will allow us to support
> > LoAs
> > in the future as well.
> >
> > The acr value in this case would be something like "idp-X", where
X
> > is
> > the id of the identity provider.
> >
> > What do you think ?
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
8:56 a.m.
Btw, acr can tell more than just authc mechs. It may mean specific characteristic of the
session itself. For instance, token lifetime, etc.
----- Original Message -----
From: "Pedro Igor Silva" <psilva(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, January 26, 2015 12:33:48 PM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
I'm still proposing acr_values, which is related with the acr claim within the
id_token.
Regarding the value, my understanding is that you are not tied with numeric values, but
you can have anything (specs says URIs) as long as both parties agree on the values in
use.
For me, authentication context is all about how the user was authenticated. And use that
info to make access decision. For instance, when authenticating against a trusted IdP I
don't care how the user is authenticated. What I care is that the IdP really
authenticated the user and I trust it. Based on that, my app may protect (or not) specific
resources based on the context the user was authenticated.
I don't think amr_values makes sense to request specific mechanisms. As I said, acr is
enough to specify one or multiple mechanisms in a more meaningful (and abstract) way
without rely on a specific mech. Something like an alias.
Suppose my company defines that acme-authc-1 is password-based authc. But new policies
were defined and require that acme-authc-1 should be passord + otp. Apps don't have to
change if they rely on this context. Now, if you use rely on specific mechanisms, your
apps should check each of them. And in this case, they would need to change in order to
also consider the otp mech.
Beside that, that opens a window to provide useful features in KeyCloak (in the future :))
regarding all that.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, January 26, 2015 11:35:01 AM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
Reading the spec, although they don't exactly give much detail on this, but my
understanding is:
* acr - abstract level of assurance, exactly how the levels are defined I don't know,
but I would imagine they'd have values 1-10 or somthing. You could then define
what's required for each value. For example 0 is just authenticated somehow, 1 is
either password+totp or my-corp-idp
* amr - is a concrete list of mechanisms used, so examples would be 'totp
password' or 'my-corp-id'
From your previous email I'm a bit unsure if you're still
proposing to use acr_values or not, but to me it doesn't make sense have
?acr_values=my-corp-idp. If there was an amr_values param that would make more sense.
----- Original Message -----
From: "Pedro Igor Silva" <psilva(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, January 26, 2015 12:54:38 PM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>
> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> Sent: Monday, January 26, 2015 5:18:14 AM
> Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> provider
>
> Can you elaborate a bit more on the idea? At first glance to me it seems
> like
> we'd use one field for two quite different purposes. Level of assurance is
> abstract (level 0, 1, 2), while authentication mechanism is more concrete
> (idp-a, password, totp). I think an application might want to request
> level-1, but not care about mechanism used, while another application would
> want to select idp-a, but not care about the level of assurance.
I understand your point. You are basically talking about "acr" and
"amr"
fields of id_token.
After reading a little bit more about the meaning of both fields, I realized
that acr provides more meaning than amr. The reason is that you would prefer
a "context" than rely on specific authentication mechanisms in order to do
access decisions. For instance, SAML provides something similar to amr and
for some people that is one of the SAML specs mistakes. And there are
discussions on OIDC mailing lists about the real value of "amr".
IMO, makes much more sense to rely on the context used to authenticate the
user than on an individual (or multiple) authentication mechanism. You can
use the context for that in a more meaningful (and abstract) way. In the
case we are discussing, users can specify that an "authentication context"
is related with trusting identities from an external IdP.
In the future, we may even let users create their own "authentication
context" by chaining authentication mechanisms. For instance, password +
otp. IMO, is much better to use a single value like acme-loa-1, which means
password + otp, than check for individual mechanisms.
Regarding the value, I think we can use anything we want as along as all
parties agree on the values being used.
>
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva(a)redhat.com>
> > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> > Sent: Friday, January 23, 2015 8:23:19 PM
> > Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > provider
> >
> > Hi,
> >
> > KEYCLOAK-996 is about allowing clients to select an existing identity
> > provider when sending an authentication request to the server.
> > Initially, this is all about passing the IdP id and automatically
> > redirect the user to its login page. Without even show KC's login
> > page.
> >
> > IMO instead of using an "idp_hint", like proposed in that JIRA,
we
> > may
> > start using the "acr_values" parameter as defined by OIDC specs.
I
> > think
> > this parameter better fits the purpose and will allow us to support
> > LoAs
> > in the future as well.
> >
> > The acr value in this case would be something like "idp-X", where
X
> > is
> > the id of the identity provider.
> >
> > What do you think ?
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > 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
4098
days inactive
4101
days old
5 comments
2 participants
participants (2)
-
Pedro Igor Silva -
Stian Thorgersen