views:

121

answers:

1

WCF has a rich security model, I hope everyone can agree upon that as a given. I recently came across a situation where our client applications (WCF based applications that leverage the user's credentials within the domain) needed to communicate with services we had to deploy to a data center outside of our domain and control. Consequently, this broke our single sign-on model and I'd like know if any of you have had any success extending the security model to services beyond the domain.

Our identity model relies on the IIdentity and IPrincipal classes (not the WindowsIdentity/WindowsPrincipal) so using an alternative identity implementation is fine. As my question implies, I don't have an answer and I'm hoping you do. The one solution I have toyed around with requires the client to authenticate in our domain in the same fashion that they do now. As part of the authentication, they'd be provided with a X.509 certificate signed by our CA (which would be trusted by the data center). Certificates would be housed in a certificate store (I believe there is one that is bundled with .NET, but I'm unclear about it's ability to be leveraged in an environment where users move occasionally) and created/provided to the user when requested.

I'd appreciate any feedback and/or ideas.

Edit:

We have services that still reside within our data center in addition to the remote data center. I'd like to provide a solution that requires only a single signon (and fwiw, our users must enter their user name and password each and every time they launch this application).

+1  A: 

If you have more or less point-to-point requests between few participants, like in a B2B environment, then certificates are definitely the way to go. Everything works automagically - once you've set it all up correctly, of course! :-)

Basically, your service will have a certificate to authenticate itself, and the client will also have a certificate which will be sent to the service and authenticates the clients against the service. On the server side, you'll be able to tap into the ServiceSecurityContext.Current.PrimaryIdentity to get access to the IIdentity of the caller.

For more information, see these resources:

Hope this helps a bit!
Marc

marc_s
Certainly helps. Any thoughts on how I might go about tying the certificate to the authenticated user. Keep in mind, the user must login with their domain credentials from there, I have no problem using a certificate to authenticate with a remote service. Part of my hang-up has been managing the relationship between the domain-authenticated credentials and the certificate. Thought?
Ajaxx
You have basically two options: (1) create Windows users on your end and map the certificate to a local Windows user and authenticate that way, or (2) rely on just the certificate - if the user presents that certificate, he's authenticated.
marc_s
Or (3) - you could also create individual certificates for each user (which works OK if you have only a limited number of users) and set their "SubjectName" (on their certificate) to a particular name, and then check in your code against a list of valid users - something like that.
marc_s