From: André M. <an...@cl...> - 2017-07-04 15:31:45
|
Hi Krzysztof, Just to clarify, the values I mentioned are in seconds. So the strange boundary is actually 5 minutes 58 seconds! By what you wrote, I assume your tests are covering update intervals far superior to this boundary (“typically in a range of one hour”). This makes me think that you are probably not able to reproduce the issue and that it is most likely caused by some misconfiguration on our side. Do you see anything wrong with the configuration bellow? Full conf/endpoints/saml-webidp.properties file ####################################### # SAML web IdP SAML endpoint settings ####################################### unity.saml.issuerURI=https://idm.clarin.eu unity.saml.credential=IDP unity.saml.defaultGroup=/clarin unity.saml.spAcceptPolicy=validRequester unity.saml.signResponses=asRequest unity.saml.validityPeriod=3600 unity.saml.requestValidityPeriod=600 unity.saml.authenticationTimeout=20 unity.saml.acceptedSPMetadataSource.1.url=https://infra.clarin.eu/aai/md_about_spf_sps.xml unity.saml.acceptedSPMetadataSource.2.url=file:///opt/dev-sp.clarin.eu.xml unity.saml.acceptedSPMetadataSource.3.url=file:///opt/b2access.eudat.eu.xml unity.saml.refreshInterval=3600 # <== works if this is set to unity.saml.refreshInterval=358 or less unity.saml.translationProfile=SAML-Attributes unity.saml.skipConsent=true Regards, André > On 4 Jul 2017, at 16:33, Krzysztof Benedyczak <kb...@un...> wrote: > > Hi, > > W dniu 30.06.2017 o 17:53, André Moreira pisze: >> Hi Krzysztof, thank you very much for your answer. Based on the >> suggestions I ran some tests while setting the logging to TRACE but >> the results puzzled me even further. So when I set >> unity.saml.refreshInterval to a value <=358 , the auto refresh works >> just fine. If I set it to anything >358 it stops working. The logs >> still show the refresh action and the various entityIDs being updated >> but it behaves as if no changes were made to the metadata source. > > Indeed that's very strange. We test and use smaller values (typically in a range of one hour) so it is quite likely that > this is untested. Still the 378 boundary is very puzzling. I'll look into it. > > At least it seems you have a decent workaround for now ;-) > > Best > Krzysztof > |