Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider

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.

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; 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&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > 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&gt; > > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > > 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 > > >