After couples of WCF tutorials, I could develop a WCF client/Server application, both service and client applications are Windows Forms Application. I can call service using each client by specifying UserName and password. My WCF service applications also shows all the connected clients with their username as well. But, When multiple clients send a request to service then I'm not being able to identity which user has called the method. This is important as my application tend to have its own session for each client processing, just as any regular ASP.NET application has. Each user have their own Identity and its own Application Domain.
Moreover, I want my service to send messages back to client, so I have implemented callback contract. In addition, I'm using netTcpBinding as my applications need to run on my intranet.
How can I implement this scenario in WCF client/server application ?
Any help please ??
Thanks
Thanks for your previous reply. Its really helpful to me.
Now, What If I want to use custom authentication using username and password.
Lets assume that I have 50 clients with valid username and password. How can I get an identity of a client (out of those 50) whose is invoking a service method at a particular point of time ?
Thanks
In your server side code, you should be able to retrieve the caller's identity from the security context - something like:
if(ServiceSecurityContext.Current != null &&
ServiceSecurityContext.Current.PrimaryIdentity != null)
{
string userName = ServiceSecurityContext.Current.PrimaryIdentity.Name;
}
If you're calling a service with Windows authentication (which might also work for you - if you're on a corporate LAN, as it would seem) - you should be able to access the security context's .WindowsIdentity instead (this will be null for any other authencation mechanism).
Related
I've been reading about WCF security for a whole day and can't say I'm comfortable with it.
I've developed some WCF services and deployed them to a test server and can call from a client. Both sides C# / VS 2010. The services are hosted under IIS 6. No option to go more recent at the moment.
So - I've read that I can only use HTTP with IIS 6 - which I believe restricts me to basicHttpBinding or wsHttpBinding as the binding.
I've also read that the XML sent over the wire using wsHttpBinding is encrypted, whereas basicHttpBinding is not.
So it looks like I want to go with wsHttpBinding as I will want some sort of authentication and I suppose user name / password will be passed along with the incoming messages.
First question is - if I use wsHttpBinding do clients have to call using https? And then do I need to worry about certificates etc. on the server?
Second question is - what security options are available to me? Do the callers have to be Windows users on the server, or can I make up my own user name / password and have that part of the service and the service do the validation and have nothing to do with Windows users? If I have to go with Windows users I suppose it's common to set up one user account on the server and have all callers use that?
The basic idea is I need to open this service to selected callers, but don't want just anyone to be able to discover the service and call it. I need to control somehow who calls the service. Is user name / password the standard way of doing this? Could I define a GUID for example which all callers would have to pass?
In answer to your first question. wsHttpBinding does not require HTTPS. You can use HTTP if you set the SecurityMode to Message or None. However, since you are proposing to send a username and password with the service calls you definately shouldn't do that. If you do then anyone will be able to look at the message in transit and read the username and password and your security is totally compromised. I'm afraid you will have to get a certificate and use HTTPS. It's not so bad though and there are lots of resources on the web to help you.
By the way, you can do HTTPS with basicHttpBinding aswell as wsHttpBinding. Also, you should consider using REST for simplicity. WCF has good support for it (webHttpBinding) and better support coming with the Web API.
In answer to your second questions, you do not need the callers to be Windows users on your server and you can use a username and password. This is called Basic Authentication. Again, there is lots about it on the web. Start here.
If you do this you will obviously have to have a database to store usernames and password so you can validate then and grant or denay access to your service. The simplest way to achieve this with WCF is to use one of the default membership providers.
I have a web service hosted in IIS 7 that is to be called from a WCF client that runs in a different domain.
Currently, the wsHTTP binding has been configured using default settings. When the call is made the service complains that the client couldn't be authenticated (Message : The request for security token could not be satisfied because authentication failed.). I guess this is because it's trying to use windows authentication and the clients ID cannot be validated against the AD server of the service.
What's the best way to get around this? Can the service be configured to run under the ID of a local account? How best to check the call has come from authorised client? I'd rather avoid certificate generation and management if possible. Ideally, I'd authenticate the client by username / password by then have the service operate under it's own local ID - to gain access to resources on the service server.
Any advise gratefully received.
Thanks
Rob.
You can use user name and password but your service should use certificate if you don't want to send user name and password in plain text. Your option is either:
HTTPS with user name and password in message
Message security with user name and password in message
Both requires certificate.
Here's a good tutorial that I used to do just that.
http://www.codeproject.com/KB/WCF/wcf_https_usernameauth.aspx?msg=3527563#xx3527563xx
I need to propagate the Windows Identity of the current user across two service calls.
Service A (which runs under integrated authentication) calls Service B (which also runs under integrated authentication). I need to identify the user identity which was used to call Service A in Service B's code.
I know this is possible using delegation, by impersonating the User in Service A code and then call Service B from the impersonated code.
However, I only want to flow the identity and not impersonate the user. Is this possible without impersonation?
get the authenticated user using ServiceSecurityontext.Current.PrimaryIdentity.Name
Add this as either a header or a field in the downstream service request
I think you are looking for the impersonation level called "Identity". See this article for a description of different impersonation levels in WCF.
I like to use wcf (windows communication foundation) with windows authentication.
Do I need Active directory for this purpose?
How the server knows about the identity of the client?
If someone can found out the pass of the client that is using the wcf services, can he create the same user name on different computer and use the password to access the wcf services ?
Yes, if you want to use Windows authentication, you need Active Directory as the source where the user gets validated.
The way this happens is by means of a user "token" - when your client logs into his PC with his Windows credentials, the login process will check with AD whether the user is legit and issue a "token". This token is then used in calls to a WCF service to determine who it is that is calling the service.
hello i have a desktop application that communicate with a wcf service that i building as well
i want to be able to manage the logged on users inside the server without a db (statefull server)
i also want the server to know how to handle 2 client from same computer, whats the simplest way of doing it?
i also have more than 1 service that the client work with (login service and app service)
is there any operationContext Property that can help me?
You can deffinetly manage the logged users inside the server. I have created a personal pattern for dealing with such situations, and it ussually goes like this:
create a client class inside the WCF server that will hold all the needed information about the client.
create 2 methods in the service: logIn, logOut. the login method should be able to gather all the informations about the client that you want to store. Make sure to define properties that can uniquely identify a client instance. When the client conencts to the server it calls the login method, allowing the server to gather and save the information from the client. If using callbacks, this is the place to save the CallBack context object, in the client obejt. You can now save the Client object in the WCF server instance (I use a dictioary). When the client logs out, it calls the log out method and the server removes the entry.
create a KeepAlive method in the server that regularry checks the connected clients to see if they are still connected (in case of network failure or app crash a client may not call the logout method).
I think this is the simplest way (not saying it's the best) to manage clients in the server.
There is no problem with having multiple clients from the same computer (you save the Context when a client logges in) as long as you have a way of uniquely identify clients.
As for your last question, having multiple services should not be a problem. In fact you have the same WCF server with different contracts (and endpoints) for the different services you offer. ALl the contracts reside in the same WCF server instance so they all can access the connected client list.
If you have further questions, I would be happy to answer them.