I am working with our university system office to setup our Gluu IdP behind their Gluu IdP proxy (Asimba) and, using the stock setup on my end, login requests from the proxy get sent to `https://my-gluu-server/idp/Authn/UserPassword`. After looking at [this support page entry](https://support.gluu.org/integrations/idp-invalid-attribute-description-2613/#at9617) it seems this should never happen as that page is not used by Gluu. After finding [this other support entry](https://support.gluu.org/integrations/saml2-asimba-idp-proxy-scenario-strange-final-saml2-response-3250/#at14948) I tried commenting out the block below in `/opt/tomcat/conf/shibboleth2/idp/handler.xml.vm`: ```xml <!-- Username/password login handler --> <ph:LoginHandler xsi:type="ph:UsernamePassword" jaasConfigurationLocation="file:///opt/idp/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod> </ph:LoginHandler> ``` I bounced the entire container and now login works exactly as expected. Per [this entry by Mohib Zico](https://support.gluu.org/integrations/idp-invalid-attribute-description-2613/#at9652) I should not have had to do this but per [this GitHub issue](https://github.com/GluuFederation/oxIdp/issues/6) you all do not support `urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport` being sent by the SP. So here are my quandaries: 1. Your instance of Asimba seems to be sending `urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport` 2. I can't always keep an SP from sending that setting as is the case here. 3. Your GitHub says that setting is not supported 4. Your support site says I should not have to modify the stock setup to make things work. Based on all this, how should I be dealing with this issue? Should I be modifying `/opt/tomcat/conf/shibboleth2/idp/handler.xml.vm` or is this something that you all can patch in the next releases?