cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: CXF SecureConversationTest - Fails to renew SCT, no examples or tests.
Date Wed, 09 Jul 2014 10:50:15 GMT
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 <frankmisa@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message