From: Krzysztof B. <kb...@un...> - 2020-08-11 18:25:20
|
Sander, W dniu 11.08.2020 o 08:37, Sander Apweiler pisze: > Dear Krzysztof, > I attached the extended log. I saw some problems with "Response header > too large" but I'm not sure who send this header. Yes, that's certainly the reason. The too big header is the Location: header used in redirect which Unity tries to do to authenticate the user with remote SAML IdP. This header contains compressed SAML request, but unfortunately it is too big to fit into a header. There is perhaps 8kB limit (or 10kB maybe), without option to be reconfigured in the HTTP server. Even if there was an option to support bigger headers, it will be a lottery with proxies and browsers. In general 10kB is assumed to be safe max. So you can either: * reconfigure (or trigger reconfiguration) this SP to use SAML POST binding, or * have shorter cert chain for the signature - the 3 certs long chain embedded in the request constitutes the most of the request size. Cheers, KB > Cheers, > Sander > > I attached the On Mon, 2020-08-10 at 19:15 +0200, Krzysztof Benedyczak > wrote: >> Dear Sander, >> >> W dniu 10.08.2020 o 06:58, Sander Apweiler pisze: >>> Dear Krzysztof, >>> we encountered an issue with the SAML IdP of CLARIN. We connected >>> this >>> IdP on two instance (b2access.eudat.eu and b2access-integration.fz- >>> juelich.de), both are running unity 3.2.2. Both are configured in >>> the >>> same way: >>> >>> unity.saml.requester.metadataSource.clarin.url= >>> https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml >>> unity.saml.requester.metadataSource.clarin.perMetadataTranslationPr >>> ofile=clarinIdp >>> unity.saml.requester.metadataSource.clarin.perMetadataRegistrationF >>> orm=CLARIN-IDP >>> >>> On the integration instance it works fine, but on the eudat.eu >>> instance >>> it stops since at least last week (here we found this issue) after >>> selecting the IdP with the URL: >>> >>> https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef >>> >>> The log file does not provide any further information (trace). I >>> attached the log and the SAML flow information from a user, where >>> you >>> see a 500 error. Did you see this problem before? We dropped >>> already >>> the IdP and add it new. >> As this is easily reproducible (I was able on you instance without >> any >> trouble): >> >> 1. pls try to obtain logged error from your server. Try to enable >> even >> full TRACE (all subsystems) for a sec, and trigger the issue. There >> should be something logged on jetty or vaadin level >> >> 2. if you fail with the above try to provide your authenticator >> configuration, so that it can be configured on my end. Then I can try >> to >> debug it. It would be perfect if you replicated this problem with >> other >> environment - there must be some difference between your testbed and >> prod instance. >> >> >> Cheers >> Krzysztof >> |