I don't like the query param approach as it requires somehow adding the query param to specify what authenticators to skip. This would have to be added to applications themselves and with Keycloak the whole idea is that applications shouldn't have to worry about authentication semantics.

We need a generic mechanism to be able to skip any authenticators that automatically log in a user. Currently this is only Kerberos, but in the future we could add more, including an option to automatically route to external IdPs.

Ignoring implementation semantics for now, but taking Kerberos as the example authenticator I can see some options (in the example below replace 'Kerberos' with any other authentication method that can automatically login a user): * If a user that was logged in using Kerberos logs out the user should not just be automatically logged-in again for the current browser session. Instead the user should be displayed with a regular username/password field, but also with an option to login with Kerberos * A variant on the above where if a user has logged-out from Kerberos the user would be displayed with a "Is this you?" when login, if the user selects yes the Kerberos authenticator would continue, if not the regular username/password form would be displayed

* Implement account switcher - where a user can login to multiple accounts at a time and select which account to use Other ideas? Points for ideas that requires no hacks in applications ;) On 30 September 2015 at 15:39, Michael Gerber <gerbermichi(a)me.com <mailto:gerbermichi@me.com>> wrote: Hi all, I would like to use kerberos as my standard authentication mechanism, but I also want to have the possibility to log in as an admin over the login form. Therefore, I want to skip the kerberos authenticator after a successful logout. https://issues.jboss.org/browse/KEYCLOAK-1727 How would you solve this problem? I've got two solutions, one sets a logout session cookie after a logout and then skips the kerberos authentication and another which allows users to skip any kind of alternative authenticators with a query parameter. Logout Session Cookie https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1... Query Param https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da67765... Michael _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@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

On 1 October 2015 at 10:26, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 01/10/15 09:13, Stian Thorgersen wrote: > I don't like the query param approach as it requires somehow > adding the query param to specify what authenticators to skip. > This would have to be added to applications themselves and with > Keycloak the whole idea is that applications shouldn't have to > worry about authentication semantics. I thing that some applications care about how was user authenticated :-\ Maybe, but that's not the case in this use-case. In this case we simply want to use another user than the automatically logged-in user. So skip_auth_mech just becomes a work around/hack rather than a proper solution For example when application wants to reuse Kerberos credential from the SPNEGO authentication to call some other thirdparty kerberos-secured service, it needs a way to "force" keycloak to authenticate with Kerberos. Hence it can skip other authenticators and leave just Kerberos. Similar case is, when application wants to reuse Facebook access token - in this case application wants to enforce login with Facebook. For this case, we already have kc_idp_hint parameter, which also requires support on the application side . Isn't it similar to the query parameter skip_auth_mechanisms ? Those situations are much more advanced than this use-case. In those case you'd have to have some form of a additional authenticators. For example if an app needs Facebook token they would need the user to authenticate with Facebook whether or not the user is already authenticated. This becomes quite tricky, especially if the user is already logged-in and logs in with FB as another user. But, that's not what this use case is about and we haven't had a request for this, so no need to consider it now. I might be wrong, but maybe some Keycloak users don't care too much about SSO. The added value for them is provisioning of users and the fact, that they don't need to implement Facebook or Kerberos authentication, but Keycloak implements it for them. So they may want some control on the application side how is user authenticated. SSO or not, it's still the same concept of moving authentication semantics away from apps to the authentication server.

> We need a generic mechanism to be able to skip any authenticators > that automatically log in a user. Currently this is only > Kerberos, but in the future we could add more, including an > option to automatically route to external IdPs. For external IdPs, we already have "Authenticate by Default" switch on identity providers. We also have kc_idp_hint parameter as I mentioned above. > > Ignoring implementation semantics for now, but taking Kerberos as > the example authenticator I can see some options (in the example > below replace 'Kerberos' with any other authentication method > that can automatically login a user): > > * If a user that was logged in using Kerberos logs out the user > should not just be automatically logged-in again for the current > browser session. Instead the user should be displayed with a > regular username/password field, but also with an option to login > with Kerberos > * A variant on the above where if a user has logged-out from > Kerberos the user would be displayed with a "Is this you?" when > login, if the user selects yes the Kerberos authenticator would > continue, if not the regular username/password form would be > displayed +1 to support "Is this you" screen. However maybe this should be configurable as some deployments may not want to display the screen, but want to relogin automatically. Classic example is redhat.com <http://redhat.com>;. When I have kerberos ticket, I can never see the login screen on saml.redhat.com <http://saml.redhat.com> . If we enforce adding "Is this you", some employees may complain "Hey, why there is another splash screen I need to click. Why I am not logged automatically" etc. But maybe I am wrong here. Maybe good opportunity to ask IT guys on the call today as they have experience with the real world scenarios ;-) I don't see why it's a problem that the splash screen is displayed. The user has decided to log out from the Kerberos session so it makes no sense whatsoever to automatically log the user in again. That's basically disabling the log out.

Conclusion of my point of view: Add variable support for "Is this you" screen and in addition have the support for skip_auth_mechanism Michael implemented. If we add is this you screen, then skip_auth_mechanism is not required for this use case and hence we should not add it unless specifically requested Marek > * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > > Other ideas? Points for ideas that requires no hacks in > applications ;) > > On 30 September 2015 at 15:39, Michael Gerber <gerbermichi(a)me.com > <mailto:gerbermichi@me.com>> wrote: > > Hi all, > > I would like to use kerberos as my standard authentication > mechanism, but I also want to have the possibility to log in > as an admin over the login form. > Therefore, I want to skip the kerberos authenticator after a > successful logout. > https://issues.jboss.org/browse/KEYCLOAK-1727 > > How would you solve this problem? > > I've got two solutions, one sets a logout session cookie > after a logout and then skips the kerberos authentication and > another which allows users to skip any kind of alternative > authenticators with a query parameter. > > Logout Session Cookie > https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1... > > Query Param > https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da67765... > > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 1 October 2015 at 11:42, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 01/10/15 10:59, Stian Thorgersen wrote: > > > On 1 October 2015 at 10:26, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > On 01/10/15 09:13, Stian Thorgersen wrote: >> I don't like the query param approach as it requires somehow >> adding the query param to specify what authenticators to >> skip. This would have to be added to applications themselves >> and with Keycloak the whole idea is that applications >> shouldn't have to worry about authentication semantics. > I thing that some applications care about how was user > authenticated :-\ > > > Maybe, but that's not the case in this use-case. In this case we > simply want to use another user than the automatically logged-in > user. So skip_auth_mech just becomes a work around/hack rather > than a proper solution > > > > For example when application wants to reuse Kerberos > credential from the SPNEGO authentication to call some other > thirdparty kerberos-secured service, it needs a way to > "force" keycloak to authenticate with Kerberos. Hence it can > skip other authenticators and leave just Kerberos. > > Similar case is, when application wants to reuse Facebook > access token - in this case application wants to enforce > login with Facebook. For this case, we already have > kc_idp_hint parameter, which also requires support on the > application side . Isn't it similar to the query parameter > skip_auth_mechanisms ? > > > Those situations are much more advanced than this use-case. In > those case you'd have to have some form of a additional > authenticators. For example if an app needs Facebook token they > would need the user to authenticate with Facebook whether or not > the user is already authenticated. This becomes quite tricky, > especially if the user is already logged-in and logs in with FB > as another user. But, that's not what this use case is about and > we haven't had a request for this, so no need to consider it now. > > > I might be wrong, but maybe some Keycloak users don't care > too much about SSO. The added value for them is provisioning > of users and the fact, that they don't need to implement > Facebook or Kerberos authentication, but Keycloak implements > it for them. So they may want some control on the application > side how is user authenticated. > > > SSO or not, it's still the same concept of moving authentication > semantics away from apps to the authentication server. TBH I am still not seeing why kc_idp_hint parameter support is ok, but skip_auth_mech is not. In both cases, it's the application which wants to control the behaviour somehow. Skip_auth_mech can be used to skip some mechanism, but also to enforce login with some mechanism (skip all other mechanisms besides the one required). I'm not a big fan of kc_idp_hint either ;) "skip_auth_mech" would be a horrible way to enforce a specific auth mechanism. What if you add another mechanism? What if user is already logged-in? It's just not something that should be added without thinking about the corner cases. Then there are also similar things baked into OIDC to consider (acr, amr, id_token_hint, etc..). As we have loads of things to do and skip_auth_mech is not something that anyone has requested, except for in this use-case. Where I'm arguing that it's a bad way to do it. We shouldn't add it now as it's a work around/hackish solution that we haven't fully considered. > >> We need a generic mechanism to be able to skip any >> authenticators that automatically log in a user. Currently >> this is only Kerberos, but in the future we could add more, >> including an option to automatically route to external IdPs. > For external IdPs, we already have "Authenticate by Default" > switch on identity providers. We also have kc_idp_hint > parameter as I mentioned above. >> >> Ignoring implementation semantics for now, but taking >> Kerberos as the example authenticator I can see some options >> (in the example below replace 'Kerberos' with any other >> authentication method that can automatically login a user): >> >> * If a user that was logged in using Kerberos logs out the >> user should not just be automatically logged-in again for >> the current browser session. Instead the user should be >> displayed with a regular username/password field, but also >> with an option to login with Kerberos >> * A variant on the above where if a user has logged-out from >> Kerberos the user would be displayed with a "Is this you?" >> when login, if the user selects yes the Kerberos >> authenticator would continue, if not the regular >> username/password form would be displayed > +1 to support "Is this you" screen. However maybe this should > be configurable as some deployments may not want to display > the screen, but want to relogin automatically. > > Classic example is redhat.com <http://redhat.com>;. When I > have kerberos ticket, I can never see the login screen on > saml.redhat.com <http://saml.redhat.com> . If we enforce > adding "Is this you", some employees may complain "Hey, why > there is another splash screen I need to click. Why I am not > logged automatically" etc. But maybe I am wrong here. Maybe > good opportunity to ask IT guys on the call today as they > have experience with the real world scenarios ;-) > > > I don't see why it's a problem that the splash screen is > displayed. The user has decided to log out from the Kerberos > session so it makes no sense whatsoever to automatically log the > user in again. That's basically disabling the log out. I imagine I have 10 tabs opened in my browser. I want to close the tab with mojo.redhat.com <http://mojo.redhat.com> and before that, I automatically click on "logout" . After few minutes, I want again to do something different for example in calendar. redhat.com <http://redhat.com> and now I will see the splash screen when I want to relogin. For me, splash screen is not an issue. Not sure about all other employees... Maybe we can add splash screen automatically and add support for a flag to not display splash screen just when someone requests it. Again, I can be wrong, but I bet this request will come earlier or later :-) Really? I just don't see that as a problem. 99.999% of the time the user won't see any splash screen as they will just login and that's that. For the times when someone logs out I just can't see it being a huge problem that they get a "is this you" prompt. If someone is really that bothered about the splash screen let them tell us and we can add an option, but there's no point in filling the admin console up with all sorts of unused toggles.

Marek > > > Conclusion of my point of view: Add variable support for "Is > this you" screen and in addition have the support for > skip_auth_mechanism Michael implemented. > > > If we add is this you screen, then skip_auth_mechanism is not > required for this use case and hence we should not add it unless > specifically requested > > > > Marek > >> * Implement account switcher - where a user can login to >> multiple accounts at a time and select which account to use >> >> Other ideas? Points for ideas that requires no hacks in >> applications ;) >> >> On 30 September 2015 at 15:39, Michael Gerber >> <gerbermichi(a)me.com <mailto:gerbermichi@me.com>> wrote: >> >> Hi all, >> >> I would like to use kerberos as my standard >> authentication mechanism, but I also want to have the >> possibility to log in as an admin over the login form. >> Therefore, I want to skip the kerberos authenticator >> after a successful logout. >> https://issues.jboss.org/browse/KEYCLOAK-1727 >> >> How would you solve this problem? >> >> I've got two solutions, one sets a logout session cookie >> after a logout and then skips the kerberos >> authentication and another which allows users to skip >> any kind of alternative authenticators with a query >> parameter. >> >> Logout Session Cookie >> https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1... >> >> Query Param >> https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da67765... >> >> Michael >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >

Sorry for late reply. On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > * If a user that was logged in using Kerberos logs out the user should > not just be automatically logged-in again for the current browser > session. Instead the user should be displayed with a regular > username/password field, but also with an option to login with Kerberos Don't like this idea. #1 Users that want to bypass kerberos have to know to logout first so they can login as a non-kerberos user. #2 username/password screen would have to have knowledge that kerberos is turned on and that the user was logged in via kerberos. I'm don't think this is possible with the current SPI. > * A variant on the above where if a user has logged-out from Kerberos > the user would be displayed with a "Is this you?" when login, if the > user selects yes the Kerberos authenticator would continue, if not the > regular username/password form would be displayed This one might be easy to do with current SPI although not sure if kerberos plugin sets some session variables that need to be cleared.

> * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > Not sure how this is different than "Is this you?". > Other ideas? Points for ideas that requires no hacks in applications ;) > idp_hint is a much different animal, isn't it? idp_hint is provided by the application. skip_auth_mechanism would be something the user has to know about to type in the URL right?

Maybe we can introduce both, a logout cookie and a query parameter to skip alternativ authenticators. The logout cookie will be set after a logout through keycloak (Logout URL) and the SpnegoAuthenticator offers a new configuration where you can configure if the logout cookie should be ignored or not. So you don’t have to do something “special” in your application but you also have the possibility to create a URL for admins where they don’t have to logout first. How would you determine the user for the “is this you?” Would you use the cookie for that or would you do a kerberos login? *Michael Gerber* Software Engineer Hammerweg 2 8304 Wallisellen Tel. 079 440 23 02 Mail gerbermichi(a)me.com On 02.10.2015, at 08:37, Marek Posolda <mposolda(a)redhat.com&gt; wrote: On 01/10/15 20:49, Bill Burke wrote: Sorry for late reply. On 10/1/2015 3:13 AM, Stian Thorgersen wrote: * If a user that was logged in using Kerberos logs out the user should not just be automatically logged-in again for the current browser session. Instead the user should be displayed with a regular username/password field, but also with an option to login with Kerberos Don't like this idea. #1 Users that want to bypass kerberos have to know to logout first so they can login as a non-kerberos user. #2 username/password screen would have to have knowledge that kerberos is turned on and that the user was logged in via kerberos. I'm don't think this is possible with the current SPI. * A variant on the above where if a user has logged-out from Kerberos the user would be displayed with a "Is this you?" when login, if the user selects yes the Kerberos authenticator would continue, if not the regular username/password form would be displayed This one might be easy to do with current SPI although not sure if kerberos plugin sets some session variables that need to be cleared. Yes, it can add the gss_delegation_credential note when Kerberos credential delegation is enabled. Looks that we may also need the non-persistent cookie added during logout, so the "Is this you" screen is not displayed for the first time login? * Implement account switcher - where a user can login to multiple accounts at a time and select which account to use Not sure how this is different than "Is this you?". Other ideas? Points for ideas that requires no hacks in applications ;) idp_hint is a much different animal, isn't it? idp_hint is provided by the application. skip_auth_mechanism would be something the user has to know about to type in the URL right? It's quite the same. Both allow application to send something to auth-server . Application can use secured URL with the param ( http://localhost/customer-portal/secured?kc_idp_hint=facebook or http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). Adapter then takes care of resend the parameter to auth-server in initial AuthorizationEndpoint request. In both cases, application can either provide the link or user can add the parameters manually. Marek _______________________________________________ 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

On 02.10.2015, at 11:18, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: For the "Is this you?" mechanism I'd add a cookie at logout that contains user details and the authenticator that was used. We’d probably need to add an parameter to authenticators that can flag them as automatic login or not. So basically you have to add the identity token of the user? Otherwise you can not trust the content of this cookie, right? Why do you want to include the authenticator? And which authenticator should that be? You don’t have to add a flag to the authenticator, you can simply create a helper which handles the whole “is this you?” stuff and invoke this helper method from each authenticator (there is currently just one)

Not sure why we would add both. If "Is this you" satisfies your requirements, there's no one requesting the other one. My concern with adding skip is that it’s a custom query param we're introducing that may conflict with same functionality in OIDC, which we would then have to deprecate once we add a similar mechanism from OIDC. Yeah I see. On 2 October 2015 at 10:58, Michael Gerber <gerbermichi(a)me.com&gt; wrote: > Maybe we can introduce both, a logout cookie and a query parameter to > skip alternativ authenticators. > The logout cookie will be set after a logout through keycloak (Logout > URL) and the SpnegoAuthenticator offers a new configuration where you can > configure if the logout cookie should be ignored or not. > > So you don’t have to do something “special” in your application but you > also have the possibility to create a URL for admins where they don’t have > to logout first. > > How would you determine the user for the “is this you?” Would you use the > cookie for that or would you do a kerberos login? > > *Michael Gerber* > Software Engineer > > Hammerweg 2 > 8304 Wallisellen > > Tel. 079 440 23 02 > Mail gerbermichi(a)me.com > > > > > On 02.10.2015, at 08:37, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > > On 01/10/15 20:49, Bill Burke wrote: > > Sorry for late reply. > > On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > > * If a user that was logged in using Kerberos logs out the user should > not just be automatically logged-in again for the current browser > session. Instead the user should be displayed with a regular > username/password field, but also with an option to login with Kerberos > > Don't like this idea. > > #1 Users that want to bypass kerberos have to know to logout first so > they can login as a non-kerberos user. > > #2 username/password screen would have to have knowledge that kerberos > is turned on and that the user was logged in via kerberos. I'm don't > think this is possible with the current SPI. > > * A variant on the above where if a user has logged-out from Kerberos > the user would be displayed with a "Is this you?" when login, if the > user selects yes the Kerberos authenticator would continue, if not the > regular username/password form would be displayed > > This one might be easy to do with current SPI although not sure if > kerberos plugin sets some session variables that need to be cleared. > > Yes, it can add the gss_delegation_credential note when Kerberos > credential delegation is enabled. > > Looks that we may also need the non-persistent cookie added during > logout, so the "Is this you" screen is not displayed for the first time > login? > > > > * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > > Not sure how this is different than "Is this you?". > > Other ideas? Points for ideas that requires no hacks in applications ;) > > idp_hint is a much different animal, isn't it? idp_hint is provided by > the application. skip_auth_mechanism would be something the user has to > know about to type in the URL right? > > > > It's quite the same. Both allow application to send something to > auth-server . Application can use secured URL with the param ( > http://localhost/customer-portal/secured?kc_idp_hint=facebook or > http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). > Adapter then takes care of resend the parameter to auth-server in > initial AuthorizationEndpoint request. In both cases, application can > either provide the link or user can add the parameters manually. > > Marek > _______________________________________________ > 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 >

Let’s summarize it up: 1. Add a logout cookie after successful logout with the identity token of the user 2. Skip all authenticators with the automaticLogin flag if a logout cookie exists and show instead the “is this you” page 3 If the user press, “yes this is me” than the login is succeeded, otherwise the next authenticator will be displayed. If everyone agrees with this workflow, than I’m going to create a PR for that, if thats ok? On 02.10.2015, at 11:58, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: On 2 October 2015 at 11:37, Michael Gerber <gerbermichi(a)me.com&gt; wrote: > > > On 02.10.2015, at 11:18, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > For the "Is this you?" mechanism I'd add a cookie at logout that contains > user details and the authenticator that was used. We’d probably need to add > an parameter to authenticators that can flag them as automatic login or not. > > So basically you have to add the identity token of the user? Otherwise > you can not trust the content of this cookie, right? > Why do you want to include the authenticator? And which authenticator > should that be? > > You don’t have to add a flag to the authenticator, you can simply create > a helper which handles the whole “is this you?” stuff and invoke this > helper method from each authenticator (there is currently just one) > It shouldn't be baked into the authenticator itself. It should be a separate thing, something that can control the flow. Ok. > Not sure why we would add both. If "Is this you" satisfies your > requirements, there's no one requesting the other one. My concern with > adding skip is that it’s a custom query param we're introducing that may > conflict with same functionality in OIDC, which we would then have to > deprecate once we add a similar mechanism from OIDC. > > Yeah I see. > > > On 2 October 2015 at 10:58, Michael Gerber <gerbermichi(a)me.com&gt; wrote: > >> Maybe we can introduce both, a logout cookie and a query parameter to >> skip alternativ authenticators. >> The logout cookie will be set after a logout through keycloak (Logout >> URL) and the SpnegoAuthenticator offers a new configuration where you can >> configure if the logout cookie should be ignored or not. >> >> So you don’t have to do something “special” in your application but you >> also have the possibility to create a URL for admins where they don’t have >> to logout first. >> >> How would you determine the user for the “is this you?” Would you use >> the cookie for that or would you do a kerberos login? >> >> *Michael Gerber* >> Software Engineer >> >> Hammerweg 2 >> 8304 Wallisellen >> >> Tel. 079 440 23 02 >> Mail gerbermichi(a)me.com >> >> >> >> >> On 02.10.2015, at 08:37, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >> >> On 01/10/15 20:49, Bill Burke wrote: >> >> Sorry for late reply. >> >> On 10/1/2015 3:13 AM, Stian Thorgersen wrote: >> >> * If a user that was logged in using Kerberos logs out the user should >> not just be automatically logged-in again for the current browser >> session. Instead the user should be displayed with a regular >> username/password field, but also with an option to login with Kerberos >> >> Don't like this idea. >> >> #1 Users that want to bypass kerberos have to know to logout first so >> they can login as a non-kerberos user. >> >> #2 username/password screen would have to have knowledge that kerberos >> is turned on and that the user was logged in via kerberos. I'm don't >> think this is possible with the current SPI. >> >> * A variant on the above where if a user has logged-out from Kerberos >> the user would be displayed with a "Is this you?" when login, if the >> user selects yes the Kerberos authenticator would continue, if not the >> regular username/password form would be displayed >> >> This one might be easy to do with current SPI although not sure if >> kerberos plugin sets some session variables that need to be cleared. >> >> Yes, it can add the gss_delegation_credential note when Kerberos >> credential delegation is enabled. >> >> Looks that we may also need the non-persistent cookie added during >> logout, so the "Is this you" screen is not displayed for the first time >> login? >> >> >> >> * Implement account switcher - where a user can login to multiple >> accounts at a time and select which account to use >> >> Not sure how this is different than "Is this you?". >> >> Other ideas? Points for ideas that requires no hacks in applications ;) >> >> idp_hint is a much different animal, isn't it? idp_hint is provided by >> the application. skip_auth_mechanism would be something the user has to >> know about to type in the URL right? >> >> >> >> It's quite the same. Both allow application to send something to >> auth-server . Application can use secured URL with the param ( >> http://localhost/customer-portal/secured?kc_idp_hint=facebook or >> http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). >> >> Adapter then takes care of resend the parameter to auth-server in >> initial AuthorizationEndpoint request. In both cases, application can >> either provide the link or user can add the parameters manually. >> >> Marek >> _______________________________________________ >> 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 >> > > >

Sorry for late reply. On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > * If a user that was logged in using Kerberos logs out the user should > not just be automatically logged-in again for the current browser > session. Instead the user should be displayed with a regular > username/password field, but also with an option to login with Kerberos Don't like this idea. #1 Users that want to bypass kerberos have to know to logout first so they can login as a non-kerberos user. #2 username/password screen would have to have knowledge that kerberos is turned on and that the user was logged in via kerberos. I'm don't think this is possible with the current SPI.

> * A variant on the above where if a user has logged-out from Kerberos > the user would be displayed with a "Is this you?" when login, if the > user selects yes the Kerberos authenticator would continue, if not the > regular username/password form would be displayed This one might be easy to do with current SPI although not sure if kerberos plugin sets some session variables that need to be cleared.

> * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > Not sure how this is different than "Is this you?".

> Other ideas? Points for ideas that requires no hacks in applications ;) > idp_hint is a much different animal, isn't it? idp_hint is provided by the application. skip_auth_mechanism would be something the user has to know about to type in the URL right?

-- 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