Freddy Exposito created CXF-5877:
------------------------------------
Summary: SCT in a (SAML1.1 + SCT) scenario failing to renew ore
reissue
Key: CXF-5877
URL: https://issues.apache.org/jira/browse/CXF-5877
Project: CXF
Issue Type: Bug
Reporter: Freddy Exposito
Priority: Minor
Hi All,
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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
