We Keep Coding

Existing MVC4 Project to share data with Winform

I have an MVC4 internet solution which uses the following setup
N Tier Application with Repository Design
Authentication etc all decoupled from UI and on DAL Layer (Accessed via SecurityRepository)
Uses SimpleAuthentication in background
I have been asked to add a WebAPI project to the solution so I can share the datasource, purely for reading some data out to a Winform application internally.
Is it possible to still decorate the Controllers in the API with [Authorize] and call the SecurityRepository.Login method to authenticate a winform? Winforms don't use cookies so not sure how I would supply a token and manage access via roles. I want it to authenticate in the background and not have a login page, ideally seamless to the end user we have switched the current Winform app datasource to point to this WebAPI.
[Edit]
For future searchers, look here too: ASP.NET MVC 4 Web API Authentication with Membership Provider

You will have to change your Authentication for WebApi. The easiest way is to implement token autentication. There is a simple article on Steves Coding Blog about Basic Authentication with Asp.Net WebAPI

Accessing WCF service sql membership provider from client

I have created a WCF service that is used for authentication. It uses an asp.net SQL membership provider for the accounts.I need a way for the client application to be able to register an account, change password ETC. The way I had originally planned and have started doing was basically interfacing the code within the service by creating matching methods that I could call from the client.
For instance to create the user I would create a method that has all the needed parameters and then within the code body I would access the membership provider so the client could just pass the details into it. So it is all actually done from within the same project/service.
Now that I have started I have began to wonder if I can access the sql membership provider directly from the client so I don't have to waste my time and interface the code.
If so could anyone point me in the right direction on how exactly I create an instance of the sql membership provider in another project so I can access it?

Microsoft has a standard framework that is targeted at what you're trying to do, it's called Client Application Services. There's a walkthrough on the MSDN site

Where is the default asp.net web application/database stored?

I have created a WCF service that is hosted within a web application. I want to add authorization to the service. Right now it uses a hardcoded username/password from a custom username password provider. What I am attempting to do is use the database that is by default in the web application to store users.
I went to the Web application configuration page and added a few users. So this means it must be going into a database. Where exactly is this stored? Or more precisely how exactly can I get the connection details for it? With the custom service I should be able to check against any DB with just some validation code and no other changes made to it, so could anyone show me an example of authorization through a DB in C#?

The databse is usually stored on you App_Data folder of you application
since you are using WCF here is the tutorial for you to implement a custom authentication provider for wcf.

Authentication in a multi layer architecture

I am designing an N-Layer system in .NET that will consist of
SQL Server 2008
EF 4
Repository Layer
Service Layer(Business Logic)
On top of this I will have:
ASP.NET MVC website
external API to be consumed by other clients(built with WCF or ServceStack.NET)
I would like to implement the typical username/password auth within the MVC app as well as OpenID/twitter/facebook login options
The api will need similar forms of authentication.
Where in the architecture is the best place to implement the authentication and are any samples available of how to implement something like this with a .NET Stack?
Is a custom Membership provider an option for this?
I realize that there are libraries available to implement the openID portion so that is not a concern at the moment but I would like to leave things open to add this in the future.
Suggestions?

Authentication should be done at the user facing point: MVC website and the WCF service.
In each point, use the appropriate authentication/authorization mechanism.
MVC website: forms authentication (or windows authentication etc.)
WCF service: (what method will you be taking, API key, user/name password on every request, secure key, auth cookie etc.)
For each point, call the service layer with the credentials used by the requestor (user) and validate it against your database (in the service layer).
The service layer should return valid/invalid for the credentials given to it.
If it's invalid, have your website or webservice reject any further actions from the user and inform them that it's not valid.
If it's valid, have your MVC website create the auth cookie (FormsAuthentication.SetAuthCookie) and your WCF service do the appropriate action for the authentication mechanism you chose.
Keep your service layer agnostic of the authentication. It should only respond with whether or not a set of credentials is valid and your front-facing layers should take care of setting the authentication tickets.
For Open ID/Twitter/Facebook logins, all the information needed is on the web app (via the login source cookies), so use that to setup your website's auth cookie.

A basic architecture would be to use the asp.net membership api for your service and web apps calling into the same membership database. Then use an impersonated user to connect to SQL Server.
You can then write custom membership providers for the other auth mechanisms or incorporate them all into one membership provider.

Sorry had to write this as another answer as didn't have enough space in the comments.
Configure the membership provider at the IIS level and use the OOTB SQL membership provider to get basic authentication working.
You can then write a custom membership the repository layer will be running in the context of the web application either web service or asp.net site so your authentication information will be in the httpcontext, you can then use that to connect through to your database or use an impersonated account i.e. the app pool user to connect instead.
You can then write a custom membership provider that authenticates against the other providers if you like and just swap out the standard SQL one for your custom one.

As an addition to Omar's answer:
You could also use a Facade Pattern which handles the authorization and is used by both the WCF and MVC code and provides the API to the business layer.
A rule of thumb is: Put authorization at one single point and let the auth-logic be handled by the client(s). Don't spread it over your service layer!

.Net authentication for both web and winforms

I have an ASP.NET web application I built for a client that uses default the ASP.NET forms authentication. They are now requesting a desktop (WinForms) app that works "with" the web application. I have created the webservices to access the data they want from the web app and put it into the desktop app. That works great.. but there needs to be the same level of security and data access based on roles that is already stored in the asp.net application.
So now it's time to make authentication work across both applications.
I would like to take advantage of the asp.net authentication by prompting a login when a user first opens the WinForms application and the calls possibly a web service to authenticate the user, get the users role, and profile.
I'm sure this has done and or asked about.. I'm just not finding the question/answer in SO.

First: Use WCF for your web services. It's a better framework than the old ASMX services.
Second: WCF can utilize the same RoleProvider and MembershipProvider classes that your ASP.NET application utilizes. It's a simple configuration switch. Use them both and your web service requires the same credentials as the web application.
And... that's pretty much it.
For more info, see:
Implementing a Role Provider
Implementing a Membership Provider
How to: Use the ASP.NET Membership Provider

To add to Randolpho's answer: another feature users might like is the ability to save their credentials rather than entering them every time they start your application. You can use the Credential Management API for this as described in this answer.