You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Historically smoothness attempted to make login as easy as possible for users by performing an automated SPNEGO (leverage user's OS credentials) login attempt to both of the JLab identity providers (ACE and CUE) concurrently on the click of a single login button. This is how the soon-to-be dismantled internal accweb works. This was a magic-like no password login, but since COVID many users are offsite and therefore often do not have an Intranet Kerberos ticket. Plus, many internal workstations are not configured to participate in SPNEGO (not all browsers are managed and even some that are are not configured for SPNEGO). Finally, internally, our accbrowse proxy removes user's Kerberos credentials. Given all this the likelihood of SPNEGO being available is now very low.
At the moment the concurrent login part is not used on ace.jlab.org because of it's complexity and because it may require relaxing iframe cross site scripting controls (concurrent part implemented by launching additional login attempt in an iframe). See env KEYCLOAK_HEADLESS_IDP. However, SPNEGO is still configured, but preferentially attempts ACE SPENGO and CUE SPNEGO is attempted only if ACE fails and user manually clicks CUE login button.
There are actually all kinds of problems introduced by SPNEGO. The first one is that it's possible (but rare), that someone wants to login using credentials that differ from the OS credentials. In other words, a separate switch user (SU) function ideally is available if you also want to use SPNEGO. Else, you must provide a separate "try SPENGO" button. Historically this was provided (SU is provided on accweb). This is currently not available on ace.jlab.org due to tons of extra complexity to setup. See env KEYCLOAK_SU_IDP.
Perhaps a more common problem with SPNEGO, is that users on Microsoft Windows that are outside of the server's domain will by default fall back to a NTLM dialog prompt, which is just about always not what you want as the user would have to click close on the confusing login dialog box to continue and entering credentials in the dialog is almost never supported by the server (it's not supported by Keycloak for example). This is currently fixed by a custom configuration of Keycloak that only challenges browsers for SPENGO depending on IP addresss. See: keycloak/keycloak#16981
The text was updated successfully, but these errors were encountered:
Historically smoothness attempted to make login as easy as possible for users by performing an automated SPNEGO (leverage user's OS credentials) login attempt to both of the JLab identity providers (ACE and CUE) concurrently on the click of a single login button. This is how the soon-to-be dismantled internal accweb works. This was a magic-like no password login, but since COVID many users are offsite and therefore often do not have an Intranet Kerberos ticket. Plus, many internal workstations are not configured to participate in SPNEGO (not all browsers are managed and even some that are are not configured for SPNEGO). Finally, internally, our accbrowse proxy removes user's Kerberos credentials. Given all this the likelihood of SPNEGO being available is now very low.
At the moment the concurrent login part is not used on ace.jlab.org because of it's complexity and because it may require relaxing iframe cross site scripting controls (concurrent part implemented by launching additional login attempt in an iframe). See env KEYCLOAK_HEADLESS_IDP. However, SPNEGO is still configured, but preferentially attempts ACE SPENGO and CUE SPNEGO is attempted only if ACE fails and user manually clicks CUE login button.
There are actually all kinds of problems introduced by SPNEGO. The first one is that it's possible (but rare), that someone wants to login using credentials that differ from the OS credentials. In other words, a separate switch user (SU) function ideally is available if you also want to use SPNEGO. Else, you must provide a separate "try SPENGO" button. Historically this was provided (SU is provided on accweb). This is currently not available on ace.jlab.org due to tons of extra complexity to setup. See env KEYCLOAK_SU_IDP.
Perhaps a more common problem with SPNEGO, is that users on Microsoft Windows that are outside of the server's domain will by default fall back to a NTLM dialog prompt, which is just about always not what you want as the user would have to click close on the confusing login dialog box to continue and entering credentials in the dialog is almost never supported by the server (it's not supported by Keycloak for example). This is currently fixed by a custom configuration of Keycloak that only challenges browsers for SPENGO depending on IP addresss. See: keycloak/keycloak#16981
The text was updated successfully, but these errors were encountered: