We Keep Coding

Azure Mobile Services and Asp.net Identity Architecture

I am hoping someone can clear up how these things can work together.
I want to be my own identity provider, so in my web api I have an OAuth token provider. I want users to register with me and then be authenticated using my token provider. The idea in the future is that more of my mobile apps and web apps will be accessible using the OAuth login sharing the user's identity.
So, if I use azure mobile services how do I implement the normal asp.net identity stuff?
And, how would a normal web app be able to use the data stored in azure mobile services? Would I have two dbcontexts one for mobile and one for web?
I've been reading and watching a lot of stuff on azure but nothing seems to show how I can do this. Most of it has to do with using external providers like facebook, ms, twitter, etc. I want to be one of those external providers, just not sure how to do it and allow my websites to still use the .net identity data.
If you could point me to or post some example / tutorial / blogs that would be great.

This is a supported scenario, although it isn't documented very well at the moment.
The Mobile Services .NET runtime is built on the ASP.NET Katana authentication middleware. The mobile service abstracts these middleware using the LoginProvider base class. The authentication model was recently made extensible for situations such as yours. In order to have Mobile Services recognize and use your identity provider, you would have to create your own LoginProvider.
There are currently two examples of this:
Adding a Katana middleware as an identity provider - part of this post.
Creating a custom username/password setup - tutorial here.
You could certainly use these techniques to wrap the standard ASP.NET identity functionality.
As to your question about accessing the data, there are a variety of approaches. Your web app could treat Mobile Services as a backend and pass through requests. This is basically treating the web app as an additional client platform, peer to your mobile apps. Another option is to, as you said, create multiple DBContexts. While you might get slightly better performance, this comes with a code maintainability tradeoff. It also wouldn't scale well if you build multiple web apps on the same data backend.

How to implement role-based authorization in WPF application calling database through WCF services?

I have a WCF service that send queries to a database using stored procedure. The WCF services are called with a WPF application where role-based authorization is implemented with IIdentity and IPrincipal.
I want to use this role-based security to protect the WCF services, but I don't know how to proceed.
It's a bit of a mess in my head :) I read about Membership, RoleProvider... but don't really understand the difference and in what case to use these.

The SQL Role Provider is appropriate in this situation.
Information on How to set it up with WCF can be found here:
http://msdn.microsoft.com/en-us/library/ff647040.aspx

WCF Service authentication and authorization

I have the requirement to setup authentication and authorization on a WCF Service, right now the service is created and working but no authentication.
There is also the need to authenticate existing users and passwords that are being stored in a SQL database and are already used by another web application, but since I do not have the source code for it, and being still adjusting do .NET I am having some dificulties.
I can read the database and found several aspnet_ tables in the database such as aspnet_Users, aspnet_Roles etc that so far seem to match with the ones used in the web application.
My question is how can I easily implement authentication and method authorization using the existing database.
Please note that I do not have access to the web-application source code.
Thanks.

MVC uses the standard ASP.Net membership provider. If you click the Log On button/register link - you can add a user. ASP.Net will create App_Data\ASPNETDB.MDF containing the membership information. You can move ASPNETDB.MDF to a remote DB server, but you must use the Membership provider schema/DB (unless you write your own provider).
A few MVC links to get you started.
http://www.asp.net/mvc/tutorials/older-versions/security/authenticating-users-with-forms-authentication-vb
http://weblogs.asp.net/fredriknormen/archive/2007/11/25/asp-net-mvc-framework-security.aspx
http://blog.wekeroad.com/blog/aspnet-mvc-securing-your-controller-actions/
The default authentication/authorization configuration added use ASP.NET standard membership and role manager service provider( the local SQL Express one). If your existing database(for user login) is also ASP.NET standard sql membership database, you can simply change the connection string of the membership section. Otherwise, you might need to create a custom membership provider which uses your own database tables for user authentication.
Implementing a Membership Provider
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
Building Custom Providers for ASP.NET 2.0 Membership
http://msdn.microsoft.com/en-us/library/aa479048.aspx

Really no easy way to achieve your requirements. Here is the library you can use and follow stricktly steps described in this blog to setup authentication with SQL Membership provider for WCF services.
In my case I did small update to the library. I've commented out line of code
//if (!IsAnonymousAllowed)

OpenID, how to develop a provider

Currently I'm developing some infrastructure and I've implemented my own RESTful authentication mechanism.
Now I've in mind that maybe I shouldn't go this way and use an industry standard so interoperability with my project could be trivial and easier to understand in terms of authentication and authorization.
After checking some articles googling everywhere and reading some Q&A here in Stackoverflow, I don't find how to be an OpenID provider - I'm not talking about authenticate users using Google, Windows Live, Facebook Connect and so, I want to develop an OpenID-enabled system so if some want to register into my services, they'll do in my own domain -.
Actually my question is: can anyone become an OpenID provider and is DotNetOpenAuth a library to develop this protocol in your own infrastructure?
Thank you.

Developing an OpenID Provider as a means of Single-Sign-On (SSO) within an organizations ring of web sites is a very valid scenario. DotNetOpenAuth comes with a pair of sample web sites (a Provider and a Relying Party) that demonstrate a single-sign-on relationship. They're called OpenIdWebRingSsoProvider and OpenIdWebRingSsoRelyingParty.
Please do not attempt to implement OpenID by yourself any more than you'd implement SSL by yourself. Getting OpenID security and interoperability just right takes a very long time and a deep level of domain knowledge. DotNetOpenAuth in particular gives you programmatic access to do just about anything you'd want to with OpenID, and since it's free, it's hard to go wrong.
Disclosure: I am a developer behind DotNetOpenAuth.

Actually my question is: can anyone become an OpenID provider and is DotNetOpenAuth a library to develop this protocol in your own infrastructure?
How to become an OpenID Provider
DotNetOpenAuth has some hiccups but all-in-all is a good tool to use it under .NET
if you're think you can do it, you can follow this:
Lastly, and most challenging, is implementing custom support for OpenID in your software and account management tools. While this approach of course affords the greatest degree of control over the user experience, it is also the most risky and only for developers experienced with web security. Start by reviewing the specs and documentation.
But my question would always be:
Why one more provider? Facebook, Google, MyOpenID, ... already have it, and with them, plenty of users have (even without them knowing) an OpenID login...
StackExchange is an OpenID provider since a while ago, but... there's so much users cross StackExchange platform. Are you developing such a big community so it will be reasonable to create and implement your own provider?

I see the answers are couple of years old. If you are looking for the latest solution to build an OpenID provider using Microsoft technology stack, IdentityServer is the open source option. One can use this and build an Open ID connect Identity provider.
Documentation on how to use and build : https://identityserver4.readthedocs.io/en/latest/
IdentityServer4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core 2.
It enables the following features in your applications:
Authentication as a Service
Centralized login logic and workflow for all of your applications (web, native, mobile, services). IdentityServer is an officially certified implementation of OpenID Connect.
Single Sign-on / Sign-out
Single sign-on (and out) over multiple application types.
Access Control for APIs
Issue access tokens for APIs for various types of clients, e.g. server to server, web applications, SPAs and native/mobile apps.
Federation Gateway
Support for external identity providers like Azure Active Directory, Google, Facebook etc. This shields your applications from the details of how to connect to these external providers.
Focus on Customization
The most important part - many aspects of IdentityServer can be customized to fit your needs. Since IdentityServer is a framework and not a boxed product or a SaaS, you can write code to adapt the system the way it makes sense for your scenarios.
Mature Open Source
IdentityServer uses the permissive Apache 2 license that allows building commercial products on top of it. It is also part of the .NET Foundation which provides governance and legal backing.

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!