Skip to main content

[RSP/BSP] Question 02/01/2010 - Renew secure context (scenario 1.7 1.7 Secure Conversation)

4 replies [Last post]
Anonymous

Hi Marek , Ram,

I got a question during the implementation of scenario 1.7 with Metro client
and WCF endpoint: We configured the secure context lifetime in metro
client's configuration file :

3000

We expect the secure context will be expired in 3 sec. But in fact, it
doesn't . I just wonder how the secure context expiration time be negotiated
between client and server? My understanding is when client send out RST, it
will carry the client configured expiration time in the soap message. If
the server doesn't agree with the expiration time client sends out, it will
send back a new one in the RSTR. Is that correct?
--
Regards!
Jinshan Yang

Tel: +86 010-64076695
Fax: +86 010-64072011
Email: jsyang@thoughtworks.com
Yahoo Messager: ejsyang@yahoo.com
Address: Room1105,11th Floor GuoHua Plaza, No.3 Dongzhimen South Street,
Dongcheng District, Beijing, China 100007
www.thoughtworks.com
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kumar Jayanti

Jinshan Yang wrote:
> Hi Marek , Ram,
>
> I got a question during the implementation of scenario 1.7 with Metro
> client and WCF endpoint: We configured the secure context lifetime in
> metro client's configuration file :
> > renewExpiredSCT="true" requireCancelSCT="true">
> 3000
>

>
> We expect the secure context will be expired in 3 sec. But in fact, it
> doesn't . I just wonder how the secure context expiration time be
> negotiated between client and server? My understanding is when client
> send out RST, it will carry the client configured expiration time in
> the soap message. If the server doesn't agree with the expiration
> time client sends out, it will send back a new one in the RSTR. Is
> that correct?
I am CCing Jiandong who works on SecureConversation. He should be able
to clarify if this is a bug or misconfiguration.

regards,
kumar

> --
> Regards!
> Jinshan Yang
>
> Tel: +86 010-64076695
> Fax: +86 010-64072011
> Email: jsyang@thoughtworks.com
> Yahoo Messager: ejsyang@yahoo.com
> Address: Room1105,11th Floor GuoHua Plaza, No.3 Dongzhimen South
> Street, Dongcheng District, Beijing, China 100007
> www.thoughtworks.com

[att1.html]

Jiandong Guo

Kumar Jayanti wrote:
> Jinshan Yang wrote:
>> Hi Marek , Ram,
>>
>> I got a question during the implementation of scenario 1.7 with Metro
>> client and WCF endpoint: We configured the secure context lifetime in
>> metro client's configuration file :
>> >> renewExpiredSCT="true" requireCancelSCT="true">
>> 3000
>>

>>
>> We expect the secure context will be expired in 3 sec. But in fact,
>> it doesn't . I just wonder how the secure context expiration time be
>> negotiated between client and server? My understanding is when client
>> send out RST, it will carry the client configured expiration time in
>> the soap message. If the server doesn't agree with the expiration
>> time client sends out, it will send back a new one in the RSTR. Is
>> that correct?

Yes, that is correct. We do include the Lifetime in RST if configured on
the client side. Not sure if WCF service honor it or not.

Please attach the RST and RSTR so we can see.

Thanks!

Jiandong
[att1.html]

Jinshan Yang

Hi Jiandong ,
Thanks for the prompt response. But the traffic between Metro client and WCF
endpoint is encrypted so we don't what is expiration time in RSTR from the
WCF endpoint.

BR,
Jinshan

On Tue, Feb 2, 2010 at 12:38 AM, Jiandong Guo wrote:

> Kumar Jayanti wrote:
>
> Jinshan Yang wrote:
>
> Hi Marek , Ram,
>
> I got a question during the implementation of scenario 1.7 with Metro
> client and WCF endpoint: We configured the secure context lifetime in metro
> client's configuration file :
> > requireCancelSCT="true">
> 3000
>

>
> We expect the secure context will be expired in 3 sec. But in fact, it
> doesn't . I just wonder how the secure context expiration time be negotiated
> between client and server? My understanding is when client send out RST, it
> will carry the client configured expiration time in the soap message. If
> the server doesn't agree with the expiration time client sends out, it will
> send back a new one in the RSTR. Is that correct?
>
>
> Yes, that is correct. We do include the Lifetime in RST if configured on
> the client side. Not sure if WCF service honor it or not.
>
> Please attach the RST and RSTR so we can see.
>
> Thanks!
>
> Jiandong
>

--
Regards!
Jinshan Yang

Tel: +86 010-64076695
Fax: +86 010-64072011
Email: jsyang@thoughtworks.com
Yahoo Messager: ejsyang@yahoo.com
Address: Room1105,11th Floor GuoHua Plaza, No.3 Dongzhimen South Street,
Dongcheng District, Beijing, China 100007
www.thoughtworks.com
[att1.html]

Jiandong Guo

Try https://metro.dev.java.net/guide/Logging.html for security tube.

Thanks!

Jiandong

Jinshan Yang wrote:
> Hi Jiandong ,
> Thanks for the prompt response. But the traffic between Metro client
> and WCF endpoint is encrypted so we don't what is expiration time in
> RSTR from the WCF endpoint.
>
> BR,
> Jinshan
>
> On Tue, Feb 2, 2010 at 12:38 AM, Jiandong Guo > > wrote:
>
> Kumar Jayanti wrote:
>> Jinshan Yang wrote:
>>> Hi Marek , Ram,
>>>
>>> I got a question during the implementation of scenario 1.7 with
>>> Metro client and WCF endpoint: We configured the secure context
>>> lifetime in metro client's configuration file :
>>> >>> renewExpiredSCT="true" requireCancelSCT="true">
>>> 3000
>>>

>>>
>>> We expect the secure context will be expired in 3 sec. But in
>>> fact, it doesn't . I just wonder how the secure context
>>> expiration time be negotiated between client and server? My
>>> understanding is when client send out RST, it will carry the
>>> client configured expiration time in the soap message. If the
>>> server doesn't agree with the expiration time client sends out,
>>> it will send back a new one in the RSTR. Is that correct?
>
> Yes, that is correct. We do include the Lifetime in RST if
> configured on the client side. Not sure if WCF service honor it or
> not.
>
> Please attach the RST and RSTR so we can see.
>
> Thanks!
>
> Jiandong
>
>
>
>
> --
> Regards!
> Jinshan Yang
>
> Tel: +86 010-64076695
> Fax: +86 010-64072011
> Email: jsyang@thoughtworks.com
> Yahoo Messager: ejsyang@yahoo.com
> Address: Room1105,11th Floor GuoHua Plaza, No.3 Dongzhimen South
> Street, Dongcheng District, Beijing, China 100007
> www.thoughtworks.com

[att1.html]