We Keep Coding

Securing WCF Service Call Between Server Applications with Federated Security

I've got two MVC sites that use the same STS for authentication. I need to create a WCF service as part of one of the sites that allows the other site to retrieve data.
These sites could be on different machines accessible over the internet (although currently they're on the same machine) and the WCF service should only be able to be accessed from the client site. The authentication token used to log into the client site should be passed through to the WCF service.
I've been looking at the different WS-Security options available (Transport, Message etc) and it's not quite sinking in 100%, and I feel like I'd end up implementing something that seemed secure but wasn't actually secure due to a lack of understanding. Any help much appreciated.
Edit:
My first attempt was with transport layer security and setting the WCF service virtual directory with require SSL in IIS. However that left me with an error of:
"The remote certificate is invalid according to the validation procedure."
And I had no way of ensuring that a specific client was connecting to the service, only that a client had a certificate from a trusted CA. At least as far as I know. I'm probably missing something vital here.

The authentication token used to log into the client site should be
passed through to the WCF service.
In this case you should be requesting an "ActAs" token from the STS:
The WCF service should be configured as a Relying Party of the STS.
The MVC site should call back to the STS and request an ActAs token specific to the WCF service.
The MVC site uses the ActAs token to call the service.
The motivation for the complexity: Delegation, or traversing multilayer architectures
Since you mentioned WS standards:
Requesting Delegation (ActAs) Tokens using WSTrustChannel (as opposed to Configuration Madness)
Not knowing your STS its hard to say more, but Googling "ActAs token" will probably give you what you need.

WCF Service - how to protect so only my clients can use it?

I am building a client program that interacts with a WCF Service via Internet. Everything works as intended but I am wondering how I can protect my services so that only my client program can make use of it?
Right now everyone with the correct URL to my services can use it with WCFTestClient (e.g).
What is the best way to make it private so only my clients can make use of the service? Rotating token strings? Certificate? Password?
I have no idea and haven't found anything useful on the Internet.
Best regards
UPDATE: The client program is intended to be downloaded for the public (everyone). So it is not for internal use, it will be a service we are gonna provide, ones in official production.
My own thinking was like: Bind a certificate in my client programs (if thats possible even?). On the IIS where the WCF service is running, check for valid certificate. Is that possible? Or better solutions out there?

Protect .net Web Service URL
Along with the other answers, that can't be bad too,
and if you want to be super careful you can implement a token system, where the clients get the first token from you, each request returns a new token, and you always check a client vs it's current token (but that's being over careful in my opinion)
Update - because it's for the public, the client can have a way of generating a valid token to check on the server, you can have a token be valid for an interval of seconds, so even if people caught the request and found the token, it will not be valid after ..15 seconds or 30,etc

If you are using Form Authentication then you can leverage the ASP.NET to check for FormAuthentication Cookie by enabling AspNetCompatibilityRequirementsMode to Required
Or if your service is stand alone i.e is consumed by everyone then you can use oauth authentication you can read more about it Oauth Authentication
What you could do is there would be a consumer secret key which would be shared to all authenticated clients. The caller would sign some info using this key and server would also sign it using the same key and then compare it.
Hope it helps

What's the simplest security method of a WCF service

It's running into an Intranet, .net framework 3.5, hosted in IIS 7.0 and it's using wsHttpBinding with null security. Now I have to protect it to allow only specific users can run it.
Seems that I should use SSL and certificates but I'd really like stay away of that because looks complex, basically I'm looking for the simplest way.
I took a look to netTcpBinding and seems to me this is the right way, if so, can you confirm if using net.tcp it would be able to be consumed by some asp.net site.
Any comments are welcome.
Thanks,

In your case you have an intranet, which means that you have internal users. It depends where the call to the WCF service is coming from.
If we assume:
Internal users, who login to a windows domain
The client machines and the server are in the same domain
The user runs a windows app on their machine, which makes the WCF call
Then the simplest solution is to use windows authentication
The client makes the call in the security context of the logged on user
The server checks the group membership of the user to determin if it should allow access

You said you are using an Intranet app.
If so, you could turn on Windows Authentication, and allow only specific users in IIS (this is also controlled in the web.config). If everyone is on the intranet, it should authenticate automatically without users needing to enter a password or user name.
However, if anyone outside your intranet needs to reach this service, you'll need to include SSL & https to protect the credentials sent to the service.

Passing Kerberos Credentials from Web Service to WCF Service

A system I'm working on has a web service which calls a WCF service. The request to the web service is received with the user's Kerberos credentials and we want to call the WCF service using these credentials.
Is it possible? if yes, how?

Yes. It is possible. You may have to use the WCF delegation. Delegation is perfect fit for backend service calls with the authentication done on front end.
Please refer to Delegates and Impersonation. The impersonation level set to Delegate would enable you to authenticate a service running in a different machine from the caller server.

What type of web service should I put together?

I want to write a web service using Visual Studio. The service needs to support some type of authentication, and should be able to receive commands via simple HTTP GET requests. The input would only be a method call with some parameters, and the responses will be simple status/error codes. My instinct would be to go with an ASP.NET Web Service, but this isn't an option in C# 4.0 and it makes me wonder if I should be using something that's more up-to-date. I've looked into WCF, but it seems like this requires a running application on the client-side - is there a way to query a WCF host by just accessing a URL?
The authentication is also an important piece. Developing my own little authentication system seems like a bad idea - I've read that it's too easy to mess up. What would be the standard way of authenticating with a web service like this?
I'd love to look up all of the specifics on this and learn it myself, but I really don't even know where to begin. Some direction would be greatly appreciated!

For a simple HTTP service that takes commands via GET (you should actually consider using POST...) I would use straight ASP MVC, not a true
'web service'. WCF wants to guide you down the path of SOAP and your clients will curse you forever. RESTful WCF is also an alternative, but it still seem overkill imho.
As for authentication, you have two viable authentication schemes:
Windows Integrated security, which will work only if client is inside intranet or connected with a VPN or DirectAccess solution
HTTP Digest, which is poorly supported by the ASP authentication modes (only support authenticating against a Active Directory forest user base).
With Windows authentication you don't do anything on the server side code, simply mark the the web.config <authentication mode="Windows" />. 'Windows' authentication is understood by most user agents. Is trivial to program clients of your service to use Windows authentication too, simple set the request's Credentials to the current user DefaultCredentials.
With Digest authentication the server will challenge the user agent to authenticate, but the ASP validation unfortunately, as I said, only works for validating a trusted NT domain. The client though does not need to be in the intranet (there is no NTLM SSPI exchange between client and server). Programming a client is faily easy, in .Net simply set the requet Credentials to a properly initialized CredentialsCache:
CredentialCache myCache = new CredentialCache();
myCache.Add(new Uri("http://www.contoso.com/"),"Digest", new NetworkCredential(UserName,SecurelyStoredPassword,Domain));
...
request.PreAuthenticate = true;
request.Credentials = myCache;
It is important to reuse the cache between requests, otherwise the client will do two round-trips with each call.
In theory you can also have a third authentication path: full duplex SSL. But the 'trivial' problem of client certificate deployment makes this alternative a dead end for anybody short of a fully pre-installed enterprise PKI.