I should add that this IdP configuration was being added for the first time on this server.
We have Dev, Test and Prod environments. The Dev version of the client's IdP was working a couple of weeks ago, so I added the corresponding IdP config in the Test environment today, after adding the certificate file to the Test CAS server's /etc/ssl/certs directory and configuring the cas.properties file to point to the Test IdP's metadata URL. Exactly the same thing I had done a couple of weeks ago in Dev. Today in Test, it appears the login URL being sent back in the IdP metadata XML (the Location attribute of the md:SingleSignOnService tag) was unreachable, so CAS was unable to create the local SP metadata XML file, and all other problems then resulted from that. The list of services was not being loaded from the JSON file, and the error message shown to users was 'Application not authorised to use CAS'. The problems went away as soon as I commented out all of the offending IdP's parameters in cas.properties. That was the only way I could isolate it. Ganesh On Wednesday, 29 August 2018 01:25:50 UTC+10, Ganesh Prasad wrote: > > My application has a number of client organisations that want their users > to use their Active Directory through a SAML2 Identity Provider (IdP). > > No problem, CAS supports this by being able to define multiple sets of > properties using cas.authn.pac4j.saml[0], cas.authn.pac4j.saml[1], > cas.authn.pac4j.saml[2], etc. > > Yesterday, I got a nasty surprise when one of those external IdPs went > down. This affected my application, because other users started getting > errors when trying to log in. > > 2018-08-29 01:13:26,917 ERROR > [net.shibboleth.utilities.java.support.xml.BasicParserPool] - <XML Parsing > Error> > org.xml.sax.SAXParseException: The element type "br" must be terminated by > the matching end-tag "</br>". > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203) > > ~[?:1.8.0_171] > > I had to edit cas.properties, comment out all the config options for the > misbehaving IdP and restart CAS. That was the only way to isolate the > problem and let the functioning parts of the system continue working. > > But this shouldn't have been necessary. Shouldn't CAS be able to isolate a > misbehaving IdP and merely suppress the display of its link on the login > page? > > Ganesh > > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/357cb351-a2d6-4d64-9a18-162b65facef7%40apereo.org.
