Upgrade: We are upgrading the software of our weblogin IdPz from IdP version 3 to IdP version 4 (IdPv4). This is a necessary part of our security maintenance, and is also needed to support new features of the login service.
Background: Our weblogin IdPz is the primary Single Sign-on (SSO) service for the University. Many web sites use weblogin IdPz to authenticate users: e.g. ACORN, Quercus, Microsoft 365, Employee Self-Service (ESS). Some services require multi-factor authentication (MFA) with a SafeNet eToken. The new Duo MFA (UTORMFA) service is not affected by our IdPv4 upgrade.
Update: eToken is not working with Safari
Under the upgraded system, we have discovered that eToken is not working with Safari. It is working with other browsers (e.g. Chrome, Edge, and Firefox), however. There is a problem with the way Safari and the web service negotiate a secure connection, the negotiation fails. We have investigated the issue and found no resolution to the problem.
Some services require eToken for login. Mac users of those services will have to use one of those other browsers.
Technical Details
Web security is implemented as an evolving set of protocols called TLS (Transport Layer Security), formerly SSL (Secure Sockets Layer). When a client connects to a server over TLS, it negotiates with server to select the most secure options supported by client and server. This is called the TLS negotiation or TLS handshaking. Over the years, the older protocols and cipher algorithms have been found vulnerable and are deprecated. Servers should no longer support these deprecated options. Sometimes the client and server do not implement a common set of protocols and ciphers and the TLS negotiation fails. This is typically because one side has failed to keep up with best practice options.
Our IdPv4 upgrade includes updates of the Shibboleth IdP software and an update to the Java Virtual Machine (JVM) that hosts the IdP software. The eToken authentication involves a connection from the client web browser to the JVM’s TLS library. When Safari connects to this new JVM, the TLS negotiation fails. The problem exists between two vendor products: (1) Apple’s Safari browser and (2) an open source OpenJDK. We believe that both client and server support sufficient protocols, but there is still something failing in the negotiation. We cannot expect the vendors to address this issue and we do not have the resources to address it ourselves, and this presumes that a server-side fix is even possible.
More Information