Hi Colm, We are having issues working with Secure Conversation and SAML Token renewing (or reissuing) SCT in a (SAML1.1 + SCT) scenario (using the mock STS for SCTs).
When CXF tries to renew (or reissue) and expired SCT, it includes the IssuedTokenOutInterceptor in the interceptors chain (as expected) to renew or reissue the SAML token. However, the contextual properties "ws-security.token" and "ws-security.token.id" ‘received’ in the IssuedTokenOutInterceptor are referencing the expired SCT token (added to the context in the AbstractSTSClient) so it tries to renew the SCT token (created by the mock STS) against the SAML STS failing of course. If we understand right how this is working, the AbstractSTSClient.renew() method, when renewing the SCT, must put the token in the RCT going to the MockSTS but can not put the SCT in the context that is intended to be used by the IssuedTokenOutInterceptor that is expecting a SAML token to be there (and it's getting an SCT). The attached CXF patch fixed the issue for us and illustrate the behaviour we are expecting. Are we missing something here or it's something going on wrong in the way 'token' and 'token.id' are being copied from the STSClient to the Interceptors? Thanks, Freddy sct+saml-issue.patch <http://cxf.547215.n5.nabble.com/file/n5746374/sct%2Bsaml-issue.patch> -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-SecureConversationTest-Fails-to-renew-SCT-no-examples-or-tests-tp5746139p5746374.html Sent from the cxf-dev mailing list archive at Nabble.com.
