Displaying #apache-syncope/2017-08-03.log:

Thu Aug 3 06:14:20 2017  ilgrosso:Joined the channel
Thu Aug 3 06:55:19 2017  andreapatricelli:Joined the channel
Thu Aug 3 07:21:40 2017  svizzero81:Joined the channel
Thu Aug 3 08:17:25 2017  sberyozkin:Joined the channel
Thu Aug 3 08:38:41 2017  coheigea:Joined the channel
Thu Aug 3 08:47:34 2017  coheigea:ilgrosso: WSS4J trunk + CXF master have the updated javamail dependency now
Thu Aug 3 08:47:47 2017  ilgrosso:coheigea: good to hear, thx!
Thu Aug 3 08:48:47 2017  ilgrosso:coheigea: FYI I have placed the call to ssoResponseValidator in the code, I am starting to test in few mins
Thu Aug 3 08:48:59 2017  coheigea:ok great
Thu Aug 3 08:49:24 2017  coheigea:the tests I added probably break with the change
Thu Aug 3 09:16:02 2017  ilgrosso:coheigea: I might have an issue with SAMLSSOResponseValidator
Thu Aug 3 09:16:15 2017  ilgrosso:around line 248 and following
Thu Aug 3 09:17:13 2017  ilgrosso:the problem is that subjectConfData.getAddress() contains my public IP address (e.g. the one with which my latptop goes to Internet), while clientAddress is my laptop's private IP address
Thu Aug 3 09:17:45 2017  coheigea:one sec
Thu Aug 3 09:20:28 2017  ilgrosso:this happens because the IdP (on the Internet, it's https://www.testshib.org/) can only see my public IP address, while the SP is running on my laptop, and can only provide my private IP address: hence, the comparison fails - but I don't think that my case is rare
Thu Aug 3 09:23:19 2017  ilgrosso:coheigea: FYI, this is the only problem I've found so far - when I hardcode my public IP address, everything works as expected
Thu Aug 3 09:25:29 2017  coheigea:ilgrosso: OK. I will add a check there to only do the comparison if clientAddress is null. We can then just not set the client address in Syncope...sound ok? I'll make it configurable in CXF as well.
Thu Aug 3 09:25:38 2017  coheigea:is (not )null
Thu Aug 3 09:26:33 2017  ilgrosso:coheigea: sounds ok, but this means we'll need to temporarily import SAMLSSOResponseValidator in Syncope
Thu Aug 3 09:27:24 2017  coheigea:yep. Just add a new JIRA for 2.0.6 as a reminder to remove it when we upgrade CXF.
Thu Aug 3 09:28:21 2017  ilgrosso:correct
Thu Aug 3 09:28:45 2017  ilgrosso:coheigea: could you please ping when you're done with that change in CXF?
Thu Aug 3 09:28:58 2017  coheigea:yep
Thu Aug 3 09:34:05 2017  coheigea:ilgrosso: done
Thu Aug 3 09:34:40 2017  ilgrosso:coheigea: thx
Thu Aug 3 09:57:47 2017  ilgrosso:coheigea: things look fine now, after importing the updated SAMLSSOResponseValidator
Thu Aug 3 09:58:10 2017  ilgrosso:only, as you suggested, the two new cases in SAML2ITCase are failing
Thu Aug 3 09:58:14 2017  ilgrosso:let me dig into that...
Thu Aug 3 09:59:14 2017  coheigea:some of the values need to be changed in the genrated SAML Response, I just copied them from the CXF tests
Thu Aug 3 09:59:42 2017  ilgrosso:ok
Thu Aug 3 10:36:39 2017  ilgrosso:coheigea: I have only one failure left
Thu Aug 3 10:36:42 2017  ilgrosso:in testLoginResponseWrappingAttack()
Thu Aug 3 10:37:13 2017  ilgrosso:it's failing because assertionConsumerURL is not as expected
Thu Aug 3 10:37:23 2017  ilgrosso:I don't understand if that was on purpose or not..
Thu Aug 3 10:39:30 2017  coheigea:ilgrosso: It's the same Response as for the valid case just with an extra Assertion though....what's the stacktrace?
Thu Aug 3 10:39:52 2017  ilgrosso:12:34:24.001 ERROR org.apache.syncope.core.logic.AbstractLogic - While validating AuthnResponse
Thu Aug 3 10:39:52 2017  ilgrosso:org.apache.wss4j.common.ext.WSSecurityException: SAML token security failure
Thu Aug 3 10:39:52 2017  ilgrosso: at org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator.validateSubjectConfirmation(SAMLSSOResponseValidator.java:225) ~[classes/:3.1.12]
Thu Aug 3 10:39:52 2017  ilgrosso: at org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator.validateAuthenticationSubject(SAMLSSOResponseValidator.java:201) ~[classes/:3.1.12]
Thu Aug 3 10:39:52 2017  ilgrosso: at org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator.validateSamlResponse(SAMLSSOResponseValidator.java:123) ~[classes/:3.1.12]
Thu Aug 3 10:39:53 2017  ilgrosso: at org.apache.syncope.core.logic.saml2.SAML2ReaderWriter.validate(SAML2ReaderWriter.java:233) ~[classes/:2.0.5-SNAPSHOT]
Thu Aug 3 10:39:56 2017  ilgrosso: at org.apache.syncope.core.logic.SAML2SPLogic.validateLoginResponse(SAML2SPLogic.java:462) ~[classes/:2.0.5-SNAPSHOT]
Thu Aug 3 10:41:58 2017  ilgrosso:coheigea: I've probably found the reason
Thu Aug 3 10:42:16 2017  coheigea:Did you change: "subjectConfirmationData.setRecipient("http://recipient.apache.org");" ?
Thu Aug 3 10:43:34 2017  ilgrosso:yes, I did
Thu Aug 3 10:43:38 2017  ilgrosso:now it is subjectConfirmationData.setRecipient("http://recipient.apache.org/saml2sp/assertion-consumer");
Thu Aug 3 10:43:54 2017  ilgrosso:it's in createResponse(), so other test cases are using it
Thu Aug 3 10:44:03 2017  ilgrosso:anyway, now the stacktrace has changed
Thu Aug 3 10:44:19 2017  ilgrosso:12:43:13.879 ERROR org.apache.syncope.core.logic.AbstractLogic - While validating AuthnResponse
Thu Aug 3 10:44:19 2017  ilgrosso:org.apache.wss4j.common.ext.WSSecurityException: SAML token security failure
Thu Aug 3 10:44:19 2017  ilgrosso: at org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator.validateSamlResponse(SAMLSSOResponseValidator.java:115) ~[classes/:3.1.12]
Thu Aug 3 10:44:19 2017  ilgrosso: at org.apache.syncope.core.logic.saml2.SAML2ReaderWriter.validate(SAML2ReaderWriter.java:233) ~[classes/:2.0.5-SNAPSHOT]
Thu Aug 3 10:44:19 2017  ilgrosso: at org.apache.syncope.core.logic.SAML2SPLogic.validateLoginResponse(SAML2SPLogic.java:462) ~[classes/:2.0.5-SNAPSHOT]
Thu Aug 3 10:44:45 2017  ilgrosso:it's because the assertion is not signed
Thu Aug 3 10:47:45 2017  coheigea:ah ok good. That's an extra layer of protection to avoid wrapping attacks
Thu Aug 3 10:48:11 2017  ilgrosso:..so, what should I do? change the test?
Thu Aug 3 10:48:19 2017  coheigea:Yeah, just to assert the failure
Thu Aug 3 10:48:24 2017  ilgrosso:cool :-)
Thu Aug 3 11:20:33 2017  coheigea:ilgrosso: Just with regards to the keystore change, signature validation is now passing because WSS4J can get the key from crypto.setKeyStore(loader.getKeyStore()); - really though this is intended for decryption, it just falls back to get the key from it if there is no match in the truststore. The test-case previously got the key from the IdP metadata, which is probably a better thing to test IMO
Thu Aug 3 11:26:58 2017  ilgrosso:coheigea: oh sorry, I did not get that, I just wanted to avoid to cause unwanted copies into standalone / archetype
Thu Aug 3 11:27:27 2017  coheigea:ah right. Well it's no big deal really in that case.
Thu Aug 3 11:28:20 2017  ilgrosso:if you think it's more appropriate, I can restore the usage of the keystore I've removed
Thu Aug 3 11:28:38 2017  coheigea:We could always dynamically generate the keystore, and write the encoded cert out into fediz.xml?
Thu Aug 3 11:29:01 2017  ilgrosso:in the test code, you mean?
Thu Aug 3 11:29:03 2017  coheigea:yeah
Thu Aug 3 11:29:08 2017  ilgrosso:that would be nice
Thu Aug 3 11:29:29 2017  coheigea:ok I will do it. I'll wait until you're done anyway with working on the SAML code.
Thu Aug 3 11:30:10 2017  ilgrosso:thx, fortunately it seems that the changes stashed this morning still apply with success
Thu Aug 3 11:30:22 2017  ilgrosso:good news, I haven't lost my work from yesterday :-)
Thu Aug 3 11:30:56 2017  coheigea:always good ;-)
Thu Aug 3 12:49:17 2017  andreapatricelli:Joined the channel
Thu Aug 3 14:36:41 2017  sberyozkin:Joined the channel
Thu Aug 3 15:51:26 2017  jbonofre:Joined the channel
Thu Aug 3 16:43:26 2017  coheigea:Left the channel

Comments