| Subject: WCF Secure Session Key Renewal best practice? |
| Group: microsoft.public.windows.developer.winfx.indigo |
| Date: 12/19/2007 2:13:01 AM |
| From: =?Utf-8?B?TWFya3VzIExlZGVy?= [Email Address Protection] |
I've got a .NET 3.0/WCF client-server app that implements a duplex message exchange pattern, using message security and per session instance mode, tcp transport. After an established connection, the server is periodically sending back notifications to connected clients. There may be NO forward client-to-service operation calls during a long time. However, right after 15 hours I get a "The session key must be renewed before it can secure application messages" error message on the server. I figured out this is related to the local client or service security property "SessionKeyRenewalIntervalproperty". I don't think it's a good idea just to increase this property. However I must prevent callback notifications from being lost. So what is the best practice to renew this session key before expiring the session? Thanks for any hints. Did not find anything so far. |
| Back |
| Subject: Re: WCF Secure Session Key Renewal best practice? |
| Group: microsoft.public.windows.developer.winfx.indigo |
| Date: 12/19/2007 1:51:03 PM |
| From: tiago.halm@gmail.com |
I may be out of my league on this one, since I have not had this problem yet. However, in your case, the client is the initiator, so the client is the one responsible for re-initializing the session key, in other words, re-establishing the a new session or renewing the current one, although I don't know if the later is expected. The exception is thrown to the server when sending back notifications, not the client, which would be the one responsible for renewing the session he started. The documentation states: "Gets or sets the time span after which the initiator renews the key for the security session" So, its in fact the initiator the one responsible for renewing the session. Having said this, and although I'm not familiar with your scenario, I'd assume that the server would wait for a message by the client (periodically) before continue to send notifications. In fact, 15 hours later the client might not even be there anymore. On the other hand, if you could renew a session key programatically, it would allow the server to send a certain notification to make the client perform the renewal (or re-open the channel) and therefore wakeup/renew the session key, although this one seems a bit far-fetched, since it was the client that initiated the conversation and its the client who will eventually end it. I know its not a complete answer :), but it was an interesting enough scenario. Let me know your thoughts or updates ... regards, Tiago Halm |
| Back |