Application logon design/architecture - separate proxies sharing a single session?

I've watched all of Mike Taulty's videos talking about WCF but I'm still a bit vague on how to go about implementing various things, such as the idea of clients needing to "logon" in order to access bits of the service.

The clients I'm building will have multiple threads and these threads will need to be able to access the WCF Service independantly and they can't be waiting on one another (or on instances of classes that they're using server side). As such, my preference would be to use the [ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)] attribute on the implementation class for the ServiceContract.

Also, I don't want the user to have to login once for each thread that is running on the client - typically they'll log into the main app ONCE and the main app will spawn a bunch of threads that will all need to call methods of the WCF service.

As such, although the client threads won't be sharing any particular instance of the implementation class, they do need to share either a session or some kind of authorization code/token that the service will pass back to the client.

The idea of an authorization code/token seems a little bit redundant given that we already have a GUID for the session - i.e. the SessionId. So my thinking was that the main app could call the Logon(<some credentials here>) method, which would either succeed of fail. In the case that it succeeded some kind of flag could be stored in the session server side indicating that the client with SessionId = foo was now logged in and thus could call other methods on the service.

What I'm wondering is, if the main app spawns various other threads (each of which will have their own proxy to the WCF service), can it also pass these other threads a particular SessionId to be used so that the spawned threads also operate in the security context (i.e. logged in state) of the main thread

Answer this question

Application logon design/architecture - separate proxies sharing a single session?

blue_devil
There's not an easy way to share session state across channels. But I think this all hinges on what one means by "logon" and "security context". In particular, it's important to understand authentication and authorization happen every time a secure call is made to a service. The auth details may differ from call to call, notably if a session is established, but both authN and authZ still happen on every sessionful call.

The most common model for this sort of app is to have one ChannelFactory, set the client's credentials on that factory, and then create n channels; one for each thread. When the first message is sent on each channel bootstrap authN is done, a secure conversation session is established, and the claims from bootstrap auth are placed in a SCT (SecurityContextToken) bound to the session. The SCT may be passed back to the client as a cookie or may be cached on the service, but the point here is even though every channel establishes its own session and therefore has its own session id, the claims are identical in every session SCT because all of the sessions were created using the same bootstrap credentials. This is inefficient in the sense that there's higher latency on the first call each thread makes to the service and that redundant SCTs are stored, but both the latency and storage requirements are small. And the latency is amortized over the lifetime of the session. So, before spending a lot of time doing custom things to get one SCT and share it around to other channels, I'd suggest implementing or doing a mock up of a one thread per channel approach and profiling. The prospective gains are marginal enough optimization probably won't be worthwhile. If you really want to use multiple proxies/ChannelFactories you can still capture user credentials once and then set them on all of the proxy/ChannelFactory instances before creating the channels. (If you're using federation, you might check out the durable issued token provider sample too.)

Additionally, WCF channels are free threaded. So, in principle, you could have all your threads make concurrent calls to the same channel instance. Given proper calling, this would mean bootstrap authentication happens only once and only one session SCT is generated. Which is what you want, aside from the fact there's only one proxy/ChannelFactory/channel rather than n of them. However, this approach is seldom used, so I personally would consider it a use at your own risk feature.
bird.tw
Hey Todd, thanks for the reply. This all sounds like good stuff that I could sink my teeth into but I'm pretty unfamiliar with a lot of the material you're talking about. SCT sounds like something I've always called an authorization code when talking to myself. It sounds like storing this server side or returning it to the client are the basic two choices I was thinking of as well (every client having to be bound to the same session if the SCT was stored in a session server side, alternatively each client could establish a separate session providing it had a copy of the SCT returned when the first session was established).

When you're talking about an SCT though are you talking about some industry standard SCT or are you talking about a custom block of text/binary data that I build myself (what I originally had in mind) Federation is another word that I've heard but I'm pretty vague on the meaning of... which kind of gave me the impression that maybe you were talking about a particular industry standard for authentication and I was wandering down some proprietary route (which may indeed be easier - I guess it depends how complicated the industry standard is).

Basically I'm faced with the situation where I will be building a WinForms client and an ASP.NET client for a WCF service... No one else needs to write clients for this service (so security can be proprietary) but people need to be able to authenticate via the web as well as from Windows machines. That means pure Windows Authentication is out (the requirement to login via the web) but if I could come up with some solution that didn't require the WinForms app users to enter a username/password at all then that would be good.

On the one hand, it sounds like I might have a bit of reading to do but on the other hand I don't particularly want to spend months simply building in logon capabilities for this app - I'd kind of like to get around to working on the business logic for it at some stage too .

If you have any good recommendations for reading material then I'm all ears though.

Thanks again.

Jimmy
Behn26
I'm referring to WS-SecureConversation SCTs. The WCF docs call having a binding with secure conversation a secure session.
Application logon design/architecture - separate proxies sharing a single session?

Answer this question