You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Frank Misa <fr...@hotmail.com> on 2014/07/08 00:53:17 UTC
CXF SecureConversationTest - Fails to renew SCT, no examples or
tests.
Hi,
I'm struggling to get a client to renew SCT in a (SAML1.1 + SCT) scenario.
Very little documentation or test examples on this.
Using the current CXF trunk codebase - I've modified some tests to
delay/expire security token between calls.
This test seems to work - but I'm unclear - by the comment:
>> The service endpoint must contact the STS to validate the received SCT
org.apache.cxf.systest.sts.secure_conv.SecureConversationTest
This test, however, fails - in a very similar fashion - to my more
complicated (SAML1.1 + SCT) case:
org.apache.cxf.systest.wssec.examples.secconv.SecureConversationTest
I've modified the test:
@org.junit.Test
public void testSecureConversation() throws Exception {
...
samlPort.doubleIt(25);
delay(5); //delay 5 minutes
samlPort.doubleIt(50);
...
}
Seems SCT are not being renewed correctly ?
Question:
* Shouldn't the above test - renew SCT if tokens expired between calls ?
* Are there any tests or documentation on SCT renewal in a (SAML1.1 + SCT)
scenario ?
Hope to hear from someone.
Thanks
Frank
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-SecureConversationTest-Fails-to-renew-SCT-no-examples-or-tests-tp5746139.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CXF SecureConversationTest - Fails to renew SCT, no examples or tests.
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Freddy,
The patch looks good. Could you create a JIRA + attach it please?
Colm.
On Fri, Jul 11, 2014 at 9:36 PM, Freddy Exposito <ex...@gmail.com> wrote:
> 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.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF SecureConversationTest - Fails to renew SCT, no examples or
tests.
Posted by Freddy Exposito <ex...@gmail.com>.
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.
Re: CXF SecureConversationTest - Fails to renew SCT, no examples or
tests.
Posted by Frank Misa <fr...@hotmail.com>.
Thank You Colm,
I'll pull together a test for you to run - to demonstrate what I'm seeing.
Our thinking here - is that the CXF:
SecureConversationTokenInterceptorProvider.setupClient - pulls over too many
properties - it's call to: mapSecurityProps().
We can workaround - by clearing some keys out - in our own
IssuedTokenInterceptor.
But I will pull together an example for you - that I hope will make
discussing this easier.
Talk Soon
F
Layout of test - attached.
<http://cxf.547215.n5.nabble.com/file/n5746287/imageCXFOverview.jpg>
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-SecureConversationTest-Fails-to-renew-SCT-no-examples-or-tests-tp5746139p5746287.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CXF SecureConversationTest - Fails to renew SCT, no examples or tests.
Posted by Colm O hEigeartaigh <co...@apache.org>.
I can't follow your test-case. Do you have a sample project?
Colm.
On Wed, Jul 9, 2014 at 8:48 AM, Frank Misa <fr...@hotmail.com> wrote:
> Hi Colm,
>
> Thank you very much - for your help.
>
> I can see your new code exercised - and it fixes the failure to renew SCT I
> observed in the referenced unit test; that's now working.
>
> It doesn't help resolve the SoapFaults/failure to renew SCT I'm seeing in
> my
> own scenario unfortunately.
> I'm trying to debug a (SAML + SCT) type setup - where the SCT issuing STS
> is
> co-local with the service or "mock STS".
>
> If I force an expiry of both tokens (SAML and SCT) by pausing for 5 minutes
> after the initial SAML RST, RSTR, SCT and successful call to service are
> made. The subsequent call to service fails because the tokens are expired.
>
> * The CXF SecureConversationOutInterceptor attempts to renew the SCT.
> * Our own IssuedTokenInterceptor - successfully obtain a new SAML1.1 token
> -
> and attempt to place this token on the Message
> cache/setContextualProperty(SecurityConstants.TOKEN, newToken) - but the
> set
> is ignored because an expired SCT token is already in cache; I'm not sure
> if it's wrongly propagated into the message cache by
> MessageImpl.calcContextCache() ?
> * The subsequent call (to co-local/mock STS I believe) to renew the SCT
> fails; it only ever sees the expired SCT in message cache. Our renewed
> SAML token never gets picked up.
>
> Without an example or some tests of this scenario - it's tough to tell if:
> * My interceptor should be clearing anything out of message context - prior
> to obtaining new SAML token.
> * What the co-local/mock STS needs/expects - in order to be able to renew
> the SCT.
> You mention that "renew" is not supported - but with your new code - it
> should issue a new SCT in my
> scenario - after I've obtained a new/valid SAML token - but it does not.
> Co-local STS rejects the call to
> RequestSecurityToken
> * If both SAML and SCT tokens are placed into cache at the same key - how
> is
> a re-issue/re-new type
> scenario supposed to work.
>
> My question: Do we have any examples, tests of this type of use-case ?
> Appreciate you sharing any thoughts you have.
>
> Thanks
> F
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-SecureConversationTest-Fails-to-renew-SCT-no-examples-or-tests-tp5746139p5746187.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF SecureConversationTest - Fails to renew SCT, no examples or
tests.
Posted by Frank Misa <fr...@hotmail.com>.
Hi Colm,
Thank you very much - for your help.
I can see your new code exercised - and it fixes the failure to renew SCT I
observed in the referenced unit test; that's now working.
It doesn't help resolve the SoapFaults/failure to renew SCT I'm seeing in my
own scenario unfortunately.
I'm trying to debug a (SAML + SCT) type setup - where the SCT issuing STS is
co-local with the service or "mock STS".
If I force an expiry of both tokens (SAML and SCT) by pausing for 5 minutes
after the initial SAML RST, RSTR, SCT and successful call to service are
made. The subsequent call to service fails because the tokens are expired.
* The CXF SecureConversationOutInterceptor attempts to renew the SCT.
* Our own IssuedTokenInterceptor - successfully obtain a new SAML1.1 token -
and attempt to place this token on the Message
cache/setContextualProperty(SecurityConstants.TOKEN, newToken) - but the set
is ignored because an expired SCT token is already in cache; I'm not sure
if it's wrongly propagated into the message cache by
MessageImpl.calcContextCache() ?
* The subsequent call (to co-local/mock STS I believe) to renew the SCT
fails; it only ever sees the expired SCT in message cache. Our renewed
SAML token never gets picked up.
Without an example or some tests of this scenario - it's tough to tell if:
* My interceptor should be clearing anything out of message context - prior
to obtaining new SAML token.
* What the co-local/mock STS needs/expects - in order to be able to renew
the SCT.
You mention that "renew" is not supported - but with your new code - it
should issue a new SCT in my
scenario - after I've obtained a new/valid SAML token - but it does not.
Co-local STS rejects the call to
RequestSecurityToken
* If both SAML and SCT tokens are placed into cache at the same key - how is
a re-issue/re-new type
scenario supposed to work.
My question: Do we have any examples, tests of this type of use-case ?
Appreciate you sharing any thoughts you have.
Thanks
F
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-SecureConversationTest-Fails-to-renew-SCT-no-examples-or-tests-tp5746139p5746187.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CXF SecureConversationTest - Fails to renew SCT, no examples or tests.
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi,
> This test seems to work - but I'm unclear - by the comment:
> >> The service endpoint must contact the STS to validate the received SCT
> org.apache.cxf.systest.sts.secure_conv.SecureConversationTest
SecureConversation is supported in two ways in CXF. The first is where the
STS is created by a service endpoint + co-located with it. The STS in
question is a kind of mock STS that just supports simple issuing of tokens.
The second is that you can instead use the full power of the CXF STS to
issue tokens via SecureConversation. This is not as efficient as the first
method, as it is not co-located with the service endpoint. This means that
when the service gets the secured request, it needs to call out to the STS
to ask it if the received SecurityContextToken is actually valid or not (+
to retrieve the associated secret). The first method does not have this
problem as the STS is co-located with the service endpoint.
> Seems SCT are not being renewed correctly ?
Renew is not supported for SecurityContextTokens (in either the co-located
or full STS). However, I've just merged a fix that makes the client call
out to "Issue" if "Renew" fails. Does this meet your requirements? If not
the CXF STS allows you to plug in custom implementations to handling
renewing tokens.
Colm.
On Mon, Jul 7, 2014 at 11:53 PM, Frank Misa <fr...@hotmail.com> wrote:
> Hi,
> I'm struggling to get a client to renew SCT in a (SAML1.1 + SCT) scenario.
> Very little documentation or test examples on this.
>
> Using the current CXF trunk codebase - I've modified some tests to
> delay/expire security token between calls.
>
> This test seems to work - but I'm unclear - by the comment:
> >> The service endpoint must contact the STS to validate the received SCT
> org.apache.cxf.systest.sts.secure_conv.SecureConversationTest
>
> This test, however, fails - in a very similar fashion - to my more
> complicated (SAML1.1 + SCT) case:
> org.apache.cxf.systest.wssec.examples.secconv.SecureConversationTest
>
> I've modified the test:
> @org.junit.Test
> public void testSecureConversation() throws Exception {
> ...
> samlPort.doubleIt(25);
>
> delay(5); //delay 5 minutes
>
> samlPort.doubleIt(50);
> ...
> }
>
> Seems SCT are not being renewed correctly ?
>
> Question:
> * Shouldn't the above test - renew SCT if tokens expired between calls ?
> * Are there any tests or documentation on SCT renewal in a (SAML1.1 + SCT)
> scenario ?
>
> Hope to hear from someone.
>
> Thanks
> Frank
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-SecureConversationTest-Fails-to-renew-SCT-no-examples-or-tests-tp5746139.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com