Hi, Rachel. Could you perhaps share sign-in url you use to initiate the flow, so we could see it for ourselves? Otherwise, please use Firefox's **SAMLTracer** plugin (or similar plugin for other browser) to capture your failing flow, then share the export of the capture with us. This - "Web Login Service - Unsupported Request" - seems like wrong endpoint or/and request type may be used.

Aliaksandr, Thank you for your response. You can observe the flow at http://beta-1.babel.hathitrust.org. Select Log In and choose "National Federation of the Blind". Here is the SAML trace from when I just walked through the process: <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://beta-1.babel.hathitrust.org/Shibboleth.sso/SAML2/POST" Destination="https://gluu.nfb.org/idp/profile/SAML2/Redirect/SSO" ID="_daef1663b89e2721191592e616872ada" IssueInstant="2017-11-27T20:12:40Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" > <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://www.hathitrust.org/shibboleth-sp</saml:Issuer> <samlp:NameIDPolicy AllowCreate="1" /> </samlp:AuthnRequest>

Are you sure you checked the little box in oxTrust SAML Trust Relationship UI to use the SSO profile (it's sort of hidden).

Michael, I...think so. Here's a screenshot of the Configure Relying Party screen.

I think these are issues with the SP setup.

I'm not able to access `beta-1.babel.hathitrust.org` for some reason. The `hathitrust.org` works, though. I think Michael is right, it's very likely the SP itself does something wrong. Please allow us to see the full dump of captured failing flow, as suggested above (capture and export it with a browser's plugin of your liking; just make sure it captures not just headers, but at very least the SAML messages as well)

I forgot that their beta page is IP protected. Okay, here is everything I can think of to log. This SAMLTrace is the only one showing up with the SAML icon next to it. If you need me to capture another request, please advise. SAMLTracer: ``` GET https://gluu.nfb.org/idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJdT8IwFIb%2FytL7resIXw0jmXAhCQph6IU3pt0OrElpZ08n%2Bu8dDBW94Lrvx3mfdILioGueNb4yG3hrAH3wcdAG%2BfkhJY0z3ApUyI04AHJf8Dx7WPIkinntrLeF1STIEMF5Zc3MGmwO4HJw76qAp80yJZX3NXJKJXgRskgKCTqqhK%2BUdw36yLo9zSslpdXgqwjR0lNFQterfEuCeXuTMuKU%2Fpu1100TmZ08m1VZ0%2FaWndJwcW6gVA4KT%2FN8RYLFPCWv%2FdFg2EviAfTKYcHicizleBSX8TgWyZCJUStDbGBh0AvjU5LEbBgyFiajbcI4G3DWfyHB%2BjL5TplSmf1tPrITIb%2Ffbtdht%2BYZHJ6XtAIynZwo83Oxu%2BJ%2BO1Z8wybTE46WxvF4%2FA8Uf4CGWE%2FoVU9XWvPHNngxX1utis8g09oeZw6Eh5QwQqed5e%2FPmH4B&RelayState=cookie%3A1511903775_41b9 HTTP/1.1 Host: gluu.nfb.org User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: http://beta-1.babel.hathitrust.org/cgi/mb?colltype=updated Cookie: JSESSIONID=16npflo9lh6slfza588bcnvga; __cfduid=da93e1cf23dd9566477034bf5331c99de1489581079; _ga=GA1.2.2096949273.1489581059; __utma=69809615.2096949273.1489581059.1509646763.1510267438.7; __utmz=69809615.1509646763.6.4.utmcsr=t.co|utmccn=(referral)|utmcmd=referral|utmcct=/936kTdGMDt; org.gluu.i18n.Locale=en; _gid=GA1.2.651499508.1511812554; SSESSd94a1a5ab275d280f617ebbbdd5ba7f2=aX0zm_LJLdqCr0heFdtZR5nDYvnZAlnWb4kdEh8LiwQ; session_id=50c305f0-fc35-4815-88f7-23a9002985e3; session_state=5fc735e6-4199-4cf0-b231-acbe39634ffd HTTP/?.? 400 Bad Request Date: Tue, 28 Nov 2017 21:16:28 GMT Server: Jetty(9.3.15.v20161220) X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=31536000; includeSubDomains Cache-Control: no-store Content-Type: text/html;charset=utf-8 Content-Length: 901 Connection: close GET SAMLRequest: fZJdT8IwFIb/ytL7resIXw0jmXAhCQph6IU3pt0OrElpZ08n+u8dDBW94Lrvx3mfdILioGueNb4yG3hrAH3wcdAG+fkhJY0z3ApUyI04AHJf8Dx7WPIkinntrLeF1STIEMF5Zc3MGmwO4HJw76qAp80yJZX3NXJKJXgRskgKCTqqhK+Udw36yLo9zSslpdXgqwjR0lNFQterfEuCeXuTMuKU/pu1100TmZ08m1VZ0/aWndJwcW6gVA4KT/N8RYLFPCWv/dFg2EviAfTKYcHicizleBSX8TgWyZCJUStDbGBh0AvjU5LEbBgyFiajbcI4G3DWfyHB+jL5TplSmf1tPrITIb/fbtdht+YZHJ6XtAIynZwo83Oxu+J+O1Z8wybTE46WxvF4/A8Uf4CGWE/oVU9XWvPHNngxX1utis8g09oeZw6Eh5QwQqed5e/PmH4B RelayState: cookie:1511903775_41b9 <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://beta-1.babel.hathitrust.org/Shibboleth.sso/SAML2/POST" Destination="https://gluu.nfb.org/idp/profile/SAML2/Redirect/SSO" ID="_58673206e3d7c10d9bb980d090a271a8" IssueInstant="2017-11-28T21:16:15Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" > <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://www.hathitrust.org/shibboleth-sp</saml:Issuer> <samlp:NameIDPolicy AllowCreate="1" ></samlp:NameIDPolicy> </samlp:AuthnRequest> ``` idp-process.log: ``` 2017-11-28 16:16:28,711 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler: No metadata returned for http://www.hathitrust.org/shibboleth-sp in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol 2017-11-28 16:16:28,714 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID http://www.hathitrust.org/shibboleth-sp) 2017-11-28 16:16:28,721 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: InvalidProfileConfiguration ```

I'm now wondering if the issue is properly pulling in the metadata from InCommon. (we have a TR with InCommon, and the SP is configured using their entity ID from the InCommon metadata). Looking at the TR list, the InCommon relationship shows valid and active. However, attempting to view the relationship results in seeing the generic error screen. Could you point me to which log to check to see why we're getting an error there? Is it possible there's an issue with the ingest of the metadata that would affect the SP's authorization?

Hi Rachel, Can you please share the ingredient of 'metadata-provider.xml' file? It's inside /opt/shibboleth-idp/conf/

Hi, Rachel. Do you think you still need this ticket to stay open?

I'm sorry for the delay. I was hoping the ticket I opened regarding the InCommon metadata was related and would magically solve my issues, but alas I'm still having problems with this. As requested, here is metadata-provider.xml: <?xml version="1.0" encoding="UTF-8"?> <MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata" xmlns:resource="urn:mace:shibboleth:2.0:resource" xmlns:security="urn:mace:shibboleth:2.0:security" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd urn:mace:shibboleth:2.0:resource http://shibboleth.net/schema/idp/shibboleth-resource.xsd urn:mace:shibboleth:2.0:security http://shibboleth.net/schema/idp/shibboleth-security.xsd urn:oasis:names:tc:SAML:2.0:metadata http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd"> <!-- ========================================================================================== --> <!-- Metadata Configuration --> <!-- --> <!-- Below you place the mechanisms which define how to load the metadata for the SP you will --> <!-- provide a service to. --> <!-- --> <!-- The Shibboleth Documentation at --> <!-- https://wiki.shibboleth.net/confluence/display/IDP30/MetadataConfiguration --> <!-- provides more details. --> <!-- --> <!-- NOTE. This file SHOULD NOT contain the metadata for this IdP. --> <!-- --> <!-- ========================================================================================== --> </MetadataProvider>

Thanks. Seems like no metadata is being loaded. Let's change `metadata-providers.xml.vm` template a bit like attached txt file and restart your gluu-server container.

Location of 'metadata-providers.xml.vm' is: `/opt/gluu/jetty/identity/conf/shibboleth3/idp`

No luck. :-( idp-process.log 2017-12-15 16:03:00,441 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler: essing the request: InvalidProfileConfiguration 2017-12-15 16:03:00,441 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler: No metadata returned for http://www.hathitrust.org/shibboleth-sp in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol 2017-12-15 16:03:00,447 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID http://www.hathitrust.org/shibboleth-sp) 2017-12-15 16:03:00,460 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while proc And metadata-providers.xml looks like: <?xml version="1.0" encoding="UTF-8"?> <MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata" xmlns:resource="urn:mace:shibboleth:2.0:resource" xmlns:security="urn:mace:shibboleth:2.0:security" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd urn:mace:shibboleth:2.0:resource http://shibboleth.net/schema/idp/shibboleth-resource.xsd urn:mace:shibboleth:2.0:security http://shibboleth.net/schema/idp/shibboleth-security.xsd urn:oasis:names:tc:SAML:2.0:metadata http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd"> <!-- ========================================================================================== --> <!-- Metadata Configuration --> <!-- --> <!-- Below you place the mechanisms which define how to load the metadata for the SP you will --> <!-- provide a service to. --> <!-- --> <!-- The Shibboleth Documentation at --> <!-- https://wiki.shibboleth.net/confluence/display/IDP30/MetadataConfiguration --> <!-- provides more details. --> <!-- --> <!-- NOTE. This file SHOULD NOT contain the metadata for this IdP. --> <!-- --> <!-- ========================================================================================== --> <MetadataProvider id="SiteSP2" xsi:type="FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/32304ED455063B9D00021C141B900006883CF1D3-sp-metadata.xml" > </MetadataProvider> <MetadataProvider id="SiteSP3" xsi:type="FileBackedHTTPMetadataProvider" metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFile="/opt/shibboleth-idp/metadata/32304ED455063B9D00021C141B90000682AC84D1-sp-metadata.xml" maxRefreshDelay="PT8H" > </MetadataProvider> <MetadataProvider id="SiteSP4" xsi:type="FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/32304ED455063B9D00021C141B90000634A07A2C-sp-metadata.xml" > </MetadataProvider> </MetadataProvider>

Ok... metadata are loading now. Can you please send us screenshot of your hathitrust trust relationship?

Here is a screenshot of the TR. Relying party is configured with SAML2SSO with default params.

Alright, all looks good from IDP's trust relationship site. Can you capture a SAML tracer and share with Hathitrust? As you are saying that beta pages are IP protected... may be that's why it's creating problem yet.