Develop Reference

Is it possible to pass logged in user credentials to WCF services?

I currently have a service layer which is exposed via WCF. The service layer includes private endpoints that are to be accessed internally using the TCP protocol but also includes public endpoints (API) for some services to be accessed publicly via HTTP. So far so good... My problem is I don't know how to implement authentication and authorization correctly.
Question 1: If I have an asp.net application that uses asp.net Identity for authentication (Forms Based Authentication) and authorization. Is it possible to pass in those credentials to the WCF service automatically i.e. so that I can perform role based authorization on each service within my service layer? If this is indeed possible can someone provide me with some sample code or point me in the right direction for further reading? If it is not possible? Is there an alternative solution?
Question 2: Do I need two separate databases? i.e. one database for the web application that contains all the users, roles etc and then another database for my service layer that contains all the business data of the application?

WCF web service security

I am moving from ASMX web services across to WCF. With ASMX, for security purposes I passed a password as a parameter to my web methods. I'd like to introduce a better layer of security going forward. Theoretically an attacker could decompile my application that consumes the web service, extract the password and consume the web service maliciously. Can I make it in some way so that the web service can only be consumed by my client application and not by any other means including a decompiled version of its executable? Does WCF introduce any any superior security methods? I notice that the client object that consumes the web services has properties for credentials. What exactly are these properties and how are they implemented?

A good way to add security, when using WCF, is through message security (WCF also supports transport security but this has some quirks) which is configured in the binding on an endpoint, very straightforward. With this security you authenticate clients via a username or password or even a SQL membership store (with the correct configuration)
Check this example out:
http://dotnetmentors.com/wcf/wcf-message-level-security-by-example.aspx
Biggest benefits are quick bolting on of secure messaging and not having username and password parameters on your operations!

Authentication and Authorization through a Web API Service Layer accessed by an ASP.NET web application and an iOS mobile app

I am about to start working on a new ASP.NET MVC web application that I intend to build an iOS mobile version of as well.
I am planning on using MVC 4 Web API as a service layer that will sit in front of the business layer and be accessed by both the web application and the mobile application.
I am a little confused however about how I will implement authentication and authorization in this architecture.
Normally in an MVC application, once a user submits proper credentials, I would make a call to
FormsAuthentication.SetAuthCookie(username, false);
Which will create a cookie that will then be passed back and forth from one request to another to maintain a user's session in the application.
I'm confused as to how this will function through a service layer when accessed from the web application. Or how it will function when the service is called from the mobile application.

You could design your Web API in such a manner that it would require the forms authentication cookie should be sent on each request. You would then use this cookie to extract the username of the currently authenticated user from it.
But when designing an API it is usually better to use some other means of authentication than cookies. For example you could use the Authorization HTTP header where the client will be required to send the encrypted value of a forms authentication ticket.
You might also take a look at the following article about token based security.

ssl channel wcf web api?

I'm currently developing a web api, with WCF web api, which allows me to write restful apis. One concern I have is security. For this reason I decided to protect my api with the OAuth protocol which works very good. However, the team got to the conclusion that our own applications shouldn't be authorized by oauth, instead they sould be authorized by http basic, meaning that the client application should send username and password.
So I have 2 questions:
How can I set up WCF Web Api to work with SSL, I'm using Web Api preview 6, and the project is a MVC3 application?
I have an operation handler which takes care of the creation of IPrincipal from the client access token, and then injects it into the operation parameters, so I can access the user's info. I would like to have in the same operation handler a condition where I could check if the authorization scheme is OAuth or http basic, and then in the case of http basic extract the user's credentials and authenticate that specific user against my data base, if authentication is successful create an IPrincipal and inject it to the operation parameters. However, as I see it, everytime an application using http basic requests something to the api, I would have to go to the data base and authenticate. So my question is: Am I in the right path, or this could be accomplished in some other way?
Any answers would be appreciate it. Thank you in advanced!

You setup SSL for WCF Web API just like you would any other WCF service exposed over HTTPS. If you are hosted in IIS, then you need to configure a site binding for HTTPS. If you are self hosted, then the configuration is bit more involved. See http://msdn.microsoft.com/en-us/library/ms733768.aspx for all of the details.
To handle basic auth against a custom identity provider you would typically use a custom authz module when hosted in IIS. See [http://custombasicauth.codeplex.com/] for an example of how to do this. If you are self hosted then you can use a custom username passworld validator. See http://msdn.microsoft.com/en-us/library/aa702565.aspx for details.
Yes, I believe you are correct that every request will require authentication unless you establish some sort of session-like semantics.
Hope this helps.

Best strategy to pass a token / cookie to a WCF service?

We are building a web service with WCF on .net 4.0. The service will be used mainly by an ASP.net MVC frontend, but will also be used by a .net Windows App.
The basic username/password auth provided won't do since we don't want to save user credentials, so I was thinking about authenticating once and creating a simple token (or should I call it a cookie?) with RNGCryptoServiceProvider.GetBytes() and then using that to authenticate further requests.
I've looked into the various common methods to do security with WCF and they mostly seem overly complex, especially when all we want to do is essentially pass a cookie to every method call.
What would be the best strategy to pass this cookie from a WCF client to our WCF services? The preferred method would be as tightly coupled with WCF's security architecture as possible.
So far I was leaning on either using custom HTTP headers, or custom authorization but I'm not convinced which is the more appropriate method, if any.
Keep in mind that for the ASP website, a new channel would be created for every request, while it would be reused on the Windows app.

IMO there are two ways to do wcf security, Transport or Messsage.
You could implement username type authentication in your application. So the client side would have to fill in a username and password for sending a message.
so the binding on the client side would look like
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName"/>
</security>
On the server side you could implement your own password validator, as shown in this example
doing this would authenticate your message on the server, you can implement whatever logic you want for your password validation. using this your message would be encrypted using ssl and authenticated using your own logic implemented on the service side.