Bug 12046 stated that CAS authentication is too complex to be displayed in a modal window, therefore authentication is displayed in a separate page when CAS authentication is enabled.
However, Shibboleth auth is quite the same as CAS auth in terms of complexity, and yet the modal is still used when Shibboleth authentication is enabled.
This doesn't seem like a consistant behavior to me.
Shouldn't the modal also be disabled when Shibboleth authentication is enabled?
I'm not so sure myself.. in the modal driven option, we simply display a login URL which contains the redirect location so all authentication really happens at the identity provider end. It is slightly inconsistent with CAS, but is consistent with other auth methods.
I should play with CAS a bit.. see what makes it too complex for the modal.. I'm envisioning that there's more functionality in CAS surrounding selecting the authentication source perhaps?
Well, the most common use-case is to authenticate against a single CAS server. In this case, it's exactly the same as shibboleth: a link to the authentication server.
But people can use C4/Auth_cas_servers.yaml to authenticate against multiple CAS servers. In this case, there are as many links as defined servers in the yaml file.
However, I don't think this feature is widely used.
That makes sense.. you could quickly fill up a modal if you had lots of authentication endpoints.. Actually, that is one thing that I don't like about shibboleth being in there.. if you do have local, shibboleth, openid and ldap you also fill up the modal and it looks strange.
For shibboleth the case of having multiple Identity providers is again handled outside of Koha which is nice.. the initial redirect takes you to a IdP list page at the NativeServiceProvider end... nicely side stepping the issue you have with CAS.. I wonder if we could do similar for CAS but inside Koha.. to make it a tiny bit more consistent with Shib and Local/LDAP..
Frankly.. I'm not sure it's a big enough issue to worry about though ?