Using WCF Sessions for Security State in a Smart Client app

Hi

I would value your advice whether it is advisible to 'man handle' the
WCF Session {ServiceContract (Session=true)} for the purpose of a
custom security session.

We are using WCF for a Smart Client development (WCF splits the SC
presentation from the Back end SOA style Service Layer)
Despite the Smart Client, we will likely use a connectionless binding
(e.g. Web Service), which will allow for easy reuse of the Services by
Other clients (e.g. for EAI or Portal expansion later on), scalability
etc.

It seems that WCF session isn't quite an ASP.NET Session
http://msdn2.microsoft.com/en-us/library/ms731193.aspx

Would it be advisable to try and re-use the WCF session for this
purpose, given that:
=> We would still want to retain a logical Security "Session" on the
Server for each Client connection, primarily for low level security
'state' such as caching of Security / Authentication info, inactivity
expiry, tying the Client's session endpoint to a single IP etc.
=> We do not want to be reliant on the IIS / ASP Session State for
this (i.e. must be available on e.g. Windows Service hosted Services)
=> We can probably live with only "Synchronous" / blocking
communication from each client (although multiple clients will connect
simultaneously)
=> We need to reuse the same session across multiple Service Contracts
- from the sounds of it, every time the Client's Service Proxy is
closed, the session ends (can we e.g. take the Session obtained e.g.
from an "Login" Service on an IAuthentication contract and then
'inject it' into subsequent calls into other, different, contracts ?)
?

Ideally we would like:
Client -> Server : Authenticate
Server -> Client : Authenticated OK, here's a Session
Client -> Server : (on all subsequent WCF service calls, on different
Services / Contracts) DoSomething1(), DoSomething2() -Each time,
adding in the session obtained
Client -> Server : Logout

Thanks in advance

Stuart

For your scenario, and if you need the client to contact any contracts or
services within the same "logon" session, I would advise the use of SAML.
Think of SAML as Kerberos, where the client contacts an issuer (KDC) which
in itself is a WebService operation with the only purpose of gathering your
credentials and providing you with a Security Token (SAML in this case) with
a certain lifetime and an authenticator only descryptable by the destination
webservice(s) which your client will contact further on.

client => Issuer (sends credentials)
client <= Issuer (gets SAML)
client => svc1 (sends SAML + operation call)
client <= svc1 (gets result)
client => svc2 (sends SAML + operation call)
client <= svc2 (gets result)
....
[the SAML will expire based on its lifetime]

Basically, an ASP session is associated a VDir (always checked InProc), as
ASPX session can be associated with a VDir (when InProc) or with a SQLServer
(SQLCluster mode). Its the backends that trully hold all the informaiton to
the session and the storage for that session is either in memory or in SQL
Server.

A SAML token is a ticket a client asks an Issuer for and the SAML holds all
the needed information required to be validated ... there is no external
storage associated. Afterwards the client is free to call any WebService
that can validate that SAML token, where the SAML token will represent the
credentials the client is sending. Of course, the Issuer and WebServices
contacted afterwards have a sort of agreement, where the Issuer not only
validates the client credentials but also knows how to insert data only
viewable and verifyable by the WebServices contacted afterwads.

While trying to provide you with informaiton I may have created more
confusion, but the focus is on understanding the "session" concept you need
here. WCF gives you a lot of funcionality, but its essence is based in the
WS-* standards which in itself present a multitude of options for the
majority of business scenario already out there.

Hope it helps

Tiago Halm

"NonNB" <nonamebrande@xxxxxx> wrote in message
news:27b73bd3-bd7f-49c4-8ca8-79d8cbbba236@xxxxxx

Thanks for pointing me in this direction Tiago

You are 100% right, security is an enterprise consideration, not a
"per system" one and the session is not necessarily restricted to just
the one server.

http://weblogs.asp.net/cibrax/archiv...27/441227.aspx
http://msdn.microsoft.com/msdnmag/is...s/default.aspx

Regards

Stuart