[jira] [Created] (CXF-5877) SCT in a (SAML1.1 + SCT) scenario failing to renew ore reissue

["Freddy Exposito (JIRA)" <ji...@apache.org>]

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)