Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
MIME-Version: 1.0
Reply-To: coheigea@apache.org
In-Reply-To: <1404892086855-5746187.post@n5.nabble.com>
References: <1404773597139-5746139.post@n5.nabble.com>
	<CAB8XdGDLsNs0enVY4_L52poxRn1CXLE3JBj1Yq+tAUDEoEUTJg@mail.gmail.com>
	<1404892086855-5746187.post@n5.nabble.com>
Date: Wed, 9 Jul 2014 11:50:15 +0100
Message-ID: 
 <CAB8XdGB0gX27Uikek4J+Pb9QFyhpUct+_OeQPoSL7owGMHPLGg@mail.gmail.com>
Subject: Re: CXF SecureConversationTest - Fails to renew SCT,
 no examples or tests.
From: Colm O hEigeartaigh <coheigea@apache.org>
To: "dev@cxf.apache.org" <dev@cxf.apache.org>
Content-Type: multipart/alternative; boundary=089e0102fb462b577704fdc079c8

--089e0102fb462b577704fdc079c8
Content-Type: text/plain; charset=UTF-8

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

--089e0102fb462b577704fdc079c8--