`http://testmd32.readthedocs.io/en/latest/integrate/test-shib2/` Where did you find that link to the docs?

I used Google. I have been having issues getting my Gluu setup to work nicely with AWS, so I wanted to test my metadata, and somewhere along the way I found that link - even if it is old or outdated, it would still work, correct?

Not necessarily.. Check the SAML doc [here](https://gluu.org/docs/ce/admin-guide/saml/).

[https://idp.magnet.com/idp/shibboleth](https://idp.magnet.com/idp/shibboleth) is not up...

Thanks for that link - however I have read and tried what is there several times now, and it is not helping. Regardless, this support ticket is about the SAML Metadata not validating correctly. It is also about not being able to use TestShib.org - as the SAML Metadata from Gluu does not validate according to them. Can you help me with these issues? I have followed the instructions from https://gluu.org/docs/ce/admin-guide/ - I only posted http://testmd32.readthedocs.io/en/latest/integrate/test-shib2/ as I used that page (and only that page) as I wanted to test with testshib.org - If there are more up-to-date instructions on how to test Gluu with TestShib.org I will gladly use those.

Hi Michael - thanks for that info, let me test that - perhaps it is available at the office, but not outside, that would explain a lot. Let me test and see what is up.

I'm working on editing the firewall rules so that URL to my Gluu server will be accessible to the outside, but in the meantime here's the XML that URL produces: ``` <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xml="http://www.w3.org/XML/1998/namespace" entityID="https://idp.magnet.com/idp/shibboleth"> <IDPSSODescriptor errorURL="https://idp.magnet.com/identity/feedback.htm" protocolSupportEnumeration="urn:mace:shibboleth:1.0 urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <Extensions> <shibmd:Scope regexp="false">idp.magnet.com</shibmd:Scope> </Extensions> <KeyDescriptor use="signing"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDmjCCAoICCQDYedQSlLcGCTANBgkqhkiG9w0BAQsFADCBjjELMAkGA1UEBhMC VVMxCzAJBgNVBAgMAkNBMRIwEAYDVQQHDAlQYWxvIEFsdG8xFzAVBgNVBAoMDk1h Z25ldCBTeXN0ZW1zMRcwFQYDVQQDDA5pZHAubWFnbmV0LmNvbTEsMCoGCSqGSIb3 DQEJARYdcmVsZWFzZWVuZ2luZWVyaW5nQG1hZ25ldC5jb20wHhcNMTcwMjIxMDE0 MDU0WhcNMTgwMjIxMDE0MDU0WjCBjjELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNB MRIwEAYDVQQHDAlQYWxvIEFsdG8xFzAVBgNVBAoMDk1hZ25ldCBTeXN0ZW1zMRcw FQYDVQQDDA5pZHAubWFnbmV0LmNvbTEsMCoGCSqGSIb3DQEJARYdcmVsZWFzZWVu Z2luZWVyaW5nQG1hZ25ldC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDBi+aF7BIXs5A8wtnEc6LmKvBVQZIKQobGEDELvAFbQr+pRT4xXQCQoGVI OSuxbwySezNLvBqgPcUQx8X4us4p2WQFyeVyGP458keiqpayrjScKd7IaQk9qBhV jscjVUIjvTGqliD/KmBcXAouwhXNxpw1r1m+rLKzSOIDCr6N/ujDiPIVoi8Azz8i PDfwMnWZMGSfvyAIVywsH3dZ7peTfywJWWNIAb/LvhqLIa0Izr1ZALJW6uKc5wA6 fUSKssSNhymkDtnGdIwngR2h06AeKrlkMVh5cDsoS89BWY4mczGrgzP8fNeL9acA KF1GpFGQTrhLKcXzMTT5rGyafS6TAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAJul jix0/o5L7r0uGQkEZkjSuca1vJNKrnJuLkPf3I7b0PzvllBzdiy+rxxoyBJtGKYL AUwv3sGN4skuWEhAIxprXrwG9lAdVIjMySSdOkGFTZ9D9X0xi8cD1MmCcAmxS785 iNciZ7fiFIrIVroLDmsXLqaXWHcxlrbYUt+p5WR9sLE/0TSp5MDMCLPirxEkIGNT XxAXm6eue9EQuGtZ8R0MFGTmPCB0rPtULXYmj+SpY+74Vf/lqI/rO6a6p9VszxEA qpDRZnJH8FAPLhCzHYwuuYDBkskWh8tT+0jJ1vJJgHhqXtRQiORRejr6l2OlRbuu SciLc4s4mAc8NZki84c= </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <KeyDescriptor use="encryption"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDmjCCAoICCQDBThzZ+VkblTANBgkqhkiG9w0BAQsFADCBjjELMAkGA1UEBhMC VVMxCzAJBgNVBAgMAkNBMRIwEAYDVQQHDAlQYWxvIEFsdG8xFzAVBgNVBAoMDk1h Z25ldCBTeXN0ZW1zMRcwFQYDVQQDDA5pZHAubWFnbmV0LmNvbTEsMCoGCSqGSIb3 DQEJARYdcmVsZWFzZWVuZ2luZWVyaW5nQG1hZ25ldC5jb20wHhcNMTcwMjIxMDE0 MDUyWhcNMTgwMjIxMDE0MDUyWjCBjjELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNB MRIwEAYDVQQHDAlQYWxvIEFsdG8xFzAVBgNVBAoMDk1hZ25ldCBTeXN0ZW1zMRcw FQYDVQQDDA5pZHAubWFnbmV0LmNvbTEsMCoGCSqGSIb3DQEJARYdcmVsZWFzZWVu Z2luZWVyaW5nQG1hZ25ldC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDEpPiIlG7lTpBj9PkwE826xe5bg0a31+j6F33ZcTo7yUaq2j3DK7w9u+tt vUuqPRz9Gdf8wEt6MKkxriyIxq2xSRl7+EYQBsQENUN+EYheRI7Zpy/m2bk/RluP jFXh6SfNvns8zd3hAJ4WgJliWSnFmVECQD66O3rUKZfwuEpMbtTPz+9ddJvZivLH ITjdv5Tns5DTjkZ71AQN4uSouRQeixIHzCFbC0khosdji7IZXkBiC7Bc/3x2U3sm qN6jtw519eDAiOd/HjTHUjsgtf/9yDezUMk3DbERqAzFh2m73zqfmQhDVJDNvcUO AsTQGooV6PigPIWB5qtjwgtcdgNBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBABWO pZfBnQ1GABZ3lO0+2YaQHHcy/2K/kdX7vLZV7b3PCl8X8816KYd+HAJxhsgVRtzS x3H3N2T2e/wnkXdV5wmgNCghGdm7/0xiEP6rF1Sv9O3hFPcAh9TM/g8zRHnqc2vx 6dinjUPcWgwdpzMMpmJnQuqnHG73jpqTHIXCuGML02SCMfDRIN/qoDzN77RQHeZb 4o8yiXMbi1fhJ3NpG9wtIlGq9JWUgvr80b7xVAYza2SPi9DZxjq/Bcjs++dMweGX F/1hYFvc59Dssvcc/NvwPxAr6tShB/CNyP7vR2zMP9iwPqmpV9bjQGDffRRRJZDk MHORBAWEj+tFsEvy+CY= </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.magnet.com:9443/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"></ArtifactResolutionService> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat> <SingleSignOnService Binding="urn:mace:shibboleth:2.0:profiles:AuthnRequest" Location="https://idp.magnet.com/idp/profile/SAML2/Unsolicited/SSO"></SingleSignOnService> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.magnet.com/idp/profile/SAML2/POST/SSO"></SingleSignOnService> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://idp.magnet.com/idp/profile/SAML2/POST-SimpleSign/SSO"></SingleSignOnService> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.magnet.com/idp/profile/SAML2/Redirect/SSO"></SingleSignOnService> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.magnet.com/idp/profile/SAML2/Redirect/SLO"></SingleLogoutService> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.magnet.com/idp/profile/SAML2/POST/SLO"></SingleLogoutService> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://idp.magnet.com/idp/profile/SAML2/POST-SimpleSign/SLO"></SingleLogoutService> <!-- <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.magnet.com:8443/idp/profile/SAML2/SOAP/SLO"></SingleLogoutService> --> </IDPSSODescriptor> <Organization> <OrganizationName xml:lang="en">Magnet Systems</OrganizationName> <OrganizationDisplayName xml:lang="en">Magnet Systems</OrganizationDisplayName> <OrganizationURL xml:lang="en">https://idp.magnet.com</OrganizationURL> </Organization> </EntityDescriptor> ```

Ok, the firewall rules have been edited, you should now be able to get to : https://idp.magnet.com/idp/shibboleth

Hi, Paul. What you are experiencing seems to be [this issue](https://github.com/GluuFederation/oxShibboleth/issues/24). For now, you need to remove all those logout bindings from metadata of your IdP. Particulairy, this fragment: ``` <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.magnet.com/idp/profile/SAML2/Redirect/SLO"></SingleLogoutService> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.magnet.com/idp/profile/SAML2/POST/SLO"></SingleLogoutService> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://idp.magnet.com/idp/profile/SAML2/POST-SimpleSign/SLO"></SingleLogoutService> <!-- <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.magnet.com:8443/idp/profile/SAML2/SOAP/SLO"></SingleLogoutService> --> ``` In case of Testshib you could just remove them from file before uploading it to their site, but for further convinience it would be better to edit metadata's template at `/opt/gluu/jetty/identity/conf/shibboleth3/idp/idp-metadata.xml.vm`, then restart `indentity` and `idp` services in the container. Another caveat in case of Shibtest is that their metadata looks like a mini-federation to Gluu, as it contains both their IdP and SP metadata in one file. For now, I would recommend to cut out their SP's metadata from it, place it in file and create a TR in Gluu's web UI using "File" method, instead of using "URI" method and providing direct link to it. You can use a ready Shibtest SP's metadata I'm attaching, if you wish. Please also note that currently you need to always add custom RP configuration to SAML TRs you create for them to work. You can check [this page](https://gluu.org/docs/ce/admin-guide/saml/#add-trust-relationship) for example (you only need steps related to "Configure specific relying party" feature from there, you can ignore everything else).

Hi, Paul. Were you able to overcome it? Do you need further help?

Hi Aliaksandr, Thank you for responding - I was away last week. Your solution to remove the "SingleLogoutService" bindings did enable me to get further. Thank you also for the note to "always add custom RP" - this is sorely needed in the current documentation. Unfortunately I was not able to get to testing my IdP with TestShib, as I am unsure how to proceed - their instructions page, which appears after I upload the corrected MetaData, says to edit this file: /opt/shibboleth-idp/conf/metadata-providers.xml and to add this there: <MetadataProvider id="HTTPMetadataTESTSHIB" xsi:type="FileBackedHTTPMetadataProvider" backingFile="%{idp.home}/metadata/testshib-providers.xml" metadataURL="http://www.testshib.org/metadata/testshib-providers.xml"/> and I have done this, and I see this get updated into Gluu by watching this log file: /opt/gluu-server-3.0.0/opt/shibboleth-idp/logs/idp-process.log because I enabled the process that checks for changes in this file. However this is obviously wrong, as it the produces this message when I test my IdP : java.lang.IllegalStateException: Counter for nested ContextualHttpServletRequest was removed before it should be! If you have any suggestions as to how to proceed that would be appreciated. Also I am not able to understand how I should edit the TestShib Metadata file to remove the SP information, as it is a somewhat complicated XML file. Do I remove the top "EntitiesDescriptor" tag, and only leave the top "EntityDescriptor"? Editing XML like this is likely to produce a lot of issues unrelated to the one I am trying to get working. Would you be able to provide the edited version of that file that i can test? Also, I noticed that the Company Image Icon does not appear in the SAML Login page, nor does any other data like company name, etc. How should I be configuring this page? Finally, I'm on 3.0.0, and I see that 3.0.1 is the latest for Gluu server. Are there instructions on how to update?

Hi, Paul. >Also I am not able to understand how I should edit the TestShib Metadata file to remove the SP information, as it is a somewhat complicated XML file. You need to remove enclosing "EntitiesDescriptor" tags, then all IdP-related elements, then you also need to copy certain namespaces from "EntitiesDescriptor" to SP's "EntitiyDescriptor" element. Why do you not want to use a ready file I attached to the post? >Unfortunately I was not able to get to testing my IdP with TestShib, as I am unsure how to proceed - their instructions page, which appears after I upload the corrected MetaData, says to edit this file: /opt/shibboleth-idp/conf/metadata-providers.xml No, you are not expected to edit any conf files on disk directly for such simple SAML setup. Unless you are absolutely sure you know what you are doing, you should rely on web UI's functionality only. I hope you can revert all changes you've done so far? Please do so, and restart `identity`, then `idp` so that correct conf files would be applied. You only need to create a TR using "File" metadata supply method, release a couple of attributes in it, and also make sure you configured custom RP settings as mentioned above. That's should be it. If something still don't work at Gluu's side, you may try to restart `identity`/`idp` again, to make sure changes are applied. >Also, I noticed that the Company Image Icon does not appear in the SAML Login page, nor does any other data like company name, etc. How should I be configuring this page? I think it may be not supported any more, users are expected to customize the login page(s) itself if they need it now. >Finally, I'm on 3.0.0, and I see that 3.0.1 is the latest for Gluu server. Are there instructions on how to update? I'll find out what update procedure is and will let you know.

Hi Aliaksandr, I have managed to break my Gluu server - when I go to https://idp.magnet.com to lgin into Gluu, I get this error message : java.lang.IllegalStateException: Counter for nested ContextualHttpServletRequest was removed before it should be! The log (/opt/gluu/jetty/oxauth/logs/oxauth.log) shows this: 2017-04-18 21:36:17,778 ERROR [qtp242131142-11] [org.xdi.oxauth.auth.AuthenticationFilter$1] (AuthenticationFilter.java:154) - org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException javax.servlet.ServletException: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:96) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.resteasy.ResteasyResourceAdapter.getResource(ResteasyResourceAdapter.java:120) ~[jboss-seam-resteasy-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamResourceServlet.service(SeamResourceServlet.java:80) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ~[servlet-api-3.1.jar:3.1.0] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772) ~[?:?] ... ETC ... In my previous comment I said I was able to get past this by removing the changes I had made to /opt/shibboleth-idp/conf/metadata-providers.xml (this was edited as per the TestShib instructions) and restarting Gluu - but now, today, that no longer fixes the issue. I am at a loss now as to how to fix this, as I have reverted my file changes, and still my Gluu is broken. Going forward, I'll follow your advice about not editing files directly - however, do you have any advice on how to fix the existing installation?

Hi, Paul. You shouldn't be able to break Gluu completely just by editing files in `/opt/shibboleth-idp`. In fact, core Gluu should stay fully operational even if this service is stopped, as Shibboleth is just an auxiliary module, it's only responsible for SAML flows. It isn't bound with the rest of the framework that tightly. Try to restart `oxauth`, then `identity` service, or may be even the whole Gluu service itself. At the very least you should have access to admin web UI. Unless you modified something not only related to Shibboleth, perhaps? May be some file system permissions were changed on files in the container by accident when you were reverting your changes? I'm not sure what to advise, that's an unusual outcome. Do you think a clean reinstall may be an option? You could use this opportunity and install the recent 3.0.1 package.

Yes a clean install may be my only option. Did you manage to find any instructions on how to update from 3.0.0 to 3.0.1 and keep my current configuration? I spent too much time getting the Cache refresh to work. Just in case any of these errors might have some bearing on my issue (oxtrust.log) (in no particular order): ERROR [qtp274064559-10] [org.gluu.oxtrust.action.UpdateTrustRelationshipAction] (UpdateTrustRelationshipAction.java:1260) - Failed to get OID for attribute name gluuPermission ERROR [Scheduler-987405879] [org.gluu.oxtrust.service.AuthenticationSessionService] (AuthenticationSessionService.java:61) - Invalid response code at oxAuth logout. User: 'admin' ERROR [qtp274064559-19] [org.gluu.oxtrust.ldap.service.Shibboleth3ConfService] (Shibboleth3ConfService.java:935) - Failed to read metadata file '/opt/shibboleth-idp/metadata' ERROR [pool-2-thread-2] [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] (StatusCheckerTimer.java:214) - Can not download ssl certificate

These errors started showing up around the time the "unable to login" problems at https://idp.magnet.com started 2017_04_18.stderrout.log.213012817:Exception in thread "Thread-1" java.lang.ExceptionInInitializerError

Hi, Paul. I'm really not sure whether it's feasible to try to fix it now, if you can't remember exactly what changes resulted in this broken state. Unless you can't provide a step by step which led to this, there are too many possibilities of what could go wrong. It appears to me it would be easier to reinstall from scratch and recreate your setup manually, unless you've invested a lot of time into it already. To prevent something like this it's important to backup your work on regular basis. Regarding the transition from 3.0.0 to 3.0.1, there won't be an update package for this one, unfortunately, so only manual upgrade is an option, what will include updating `.war` files of some modules, as well as OpenLDAP's schema updates. Again, unless a lot of work has been put into this setup, it would be easier to re-create it from scratch. There will be update packages starting version 3.0.1

Paul, if all you care about is CR's configuration, I think we can help you to dump it and import into your new 3.0.1 instance later. If structure of LDAP directory in your current instance is still in good shape, of course. Will it do?

Paul, just in case, here are steps you may use to dump CR and authentication settings. Both commands are run in the container. Before running them store your LDAP password in `/tmp/.pw` - `# /opt/opendj/bin/ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D 'cn=directory manager,o=gluu' -j /tmp/.pw -b 'o=gluu' '(objectclass=gluuappliance)' oxIDPAuthentication oxTrustCacheRefreshServerIpAddress gluuIpAddress gluuVdsCacheRefreshEnabled gluuDSstatus gluuVdsCacheRefreshPollingInterval ` - `# /opt/opendj/bin/ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D 'cn=directory manager,o=gluu' -j /tmp/.pw -b 'o=gluu' '(objectclass=oxtrustconfiguration)' oxTrustConfCacheRefresh` Please share output of both commands with us (you should remove any passwords from it, though) But anyway, before reinstall, please backup your failed instance, so you could always fetch some data from it, if something is forgotten.

Hi Aliaksandr, Fair enough. I do remember the steps, and I have reverted them, but I still have a broken state. I think it is related to being logged in, and restarting the server, as I saw a bug related to that, that produced an error message like mine, but it was never resolved. At this point it doesn't matter. Thank you for the commands to dump my CR, that is appreciated. I'll post that output when I can. I'll do the upgrade to 3.0.1 and start fresh. This is really the only choice anyway, since there is no clear upgrade path to 3.0.1 from 3.0.0 and from what you have stated, there will never be. Thanks for your help ! Paul

>I think it is related to being logged in, and restarting the server, as I saw a bug related to that, that produced an error message like mine, but it was never resolved. Could you refer me to the ticket you are talking about?

Closing out this ticket. Let us know if we can be of further assistance, Paul. Thanks, Will