cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-5877) SCT in a (SAML1.1 + SCT) scenario failing to renew ore reissue
Date Mon, 14 Jul 2014 15:04:04 GMT

     [ https://issues.apache.org/jira/browse/CXF-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Colm O hEigeartaigh updated CXF-5877:
-------------------------------------

    Fix Version/s: 2.7.12

> 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
>            Assignee: Colm O hEigeartaigh
>            Priority: Minor
>             Fix For: 2.7.12, 3.0.1
>
>         Attachments: sct+saml-issue.patch
>
>
> 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)

Mime
View raw message