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?
Note: In our case we are only using renew and issue but I see the token being added in the AbstractSTSClient.validate() and AbstractSTSClient.cancel() as well that might be causing an issue too.