I am working on a 3-tier asp.net mvc project and want to build a custom provider for user authentication and authorization based on the default one provided by asp.net. At which tier should the membership provider be implemented?
We currently have a web tier, web service tier and a database tier. The two options I have come up with so far are:
Implement the provider in the web tier. The implementation will call methods exposed by the web service which in turn talks to the database.
Implement the provider in the web service tier. The implementation will talk to the database directly.
Web Tier will be the ideal place to implement membership provider, if you are planning to have only one UI which consumes your services.
Related
I'm working with a legacy asp.net web application that runs on two servers;
frontend server, IIS web server, accessible from the web
backend server, can't be accessed from the outside, running IIS and a database.
They communicate using old fashioned asmx-web services.
ASP.Net membership is used for user management and the database is on the backend server. The asmx web services for membership looks pretty much like the example found at http://www.codeproject.com/Articles/13032/Custom-MembershipProvider-and-RoleProvider-Impleme
My question; Can I do something like this with the ASP.NET Identity (2.0)? Which interfaces will I need to implement? Are there any examples?
I guess I will use WCF instad of asmx :)
Ivar
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
Just like "Log in with StackExchange", I expect that StackExchange have a custom membership provider to be used for many applications.
I have many web applications, subjected to extend and i would like to have one database and a shared membership application to handle Login, Registration, profile and Role-based membership management.
After some research, I also found that using a WCF Service to handle this implementation would be a good idea.
I am just trying to get a feel of it before I go ahead with any application, and if there is any open source projects or even resources, I would prefer not to reinvent the wheel.
Could anyone tell me how could it be implemented?
There are several options available to you - the ASP.NET Membership Provider connected to a shared membership database, WCF Authentication Services, or OAuth.
ASP.NET Membership Provider
This doesn't have to be a custom membership provider - the standard SqlMembershipProvider model will cover your requirements, as long as each site can access the shared database. See here : http://msdn.microsoft.com/en-us/library/ms731049%28v=vs.110%29.aspx
WCF Authentication Services
If connecting to a shared database is not an option, then yes, WCF Authentication Services are available to you. WCF already gives you lots of pre-built code, so you wouldn't be reinventing the wheel. See here for specific code examples:
Walkthrough: Using ASP.NET Application Services
How to: Enable the WCF Authentication Service
How to: Customize User Login When Using the WCF Authentication Service
How to: Use Non-default Membership Provider for WCF Authentication Service
How to: Customize the Authentication Cookie from the WCF Authentication Service
OAuth
OAuth is a big topic, and a big opinion splitter. Have a read of this introductory article on MSDN. You may also want to consider a pre-built .NET OAuth library - see this one : http://oauth.net/code/
We have the following structure on our project in order to get data.
Acces to Database Using Entity Framework
ProjectName.DAL
Services that call Entity Framework.(UoW)
ProjectName.Service
Our Actions inside Controllers call Services and return data needed.
ProjectName.Web
The Question:
Our services take info directly with Entity Framework, What are the advantages and disadvantages about creating WebServices in order to replace the connection with EF? "In that case only WebServices will have access to Entity Framework,"
ProjectName.DAL
ProjectName.WebServices
ProjectName.Service
ProjectName.Web
The main advantage is that you would have a more decoupled design.
By exposing your DAL through web services you "disconnect" it from your frontend. For example, a mobile app, a web app and a WPF desktop app could all access your DAL through the same web services. So you can reuse your DAL accross different apps which can save you a lot of development time. Have a look at ServiceStack and advantages of its web services.
Disadvantages? Having to do some additional development work and testing. If your app is a simple and will not be used in different environments it may be overkill to use web services.
Disadvantages:
Web services tend to consume more resources from your server than just a plain CLR (aka dll) layer in your project.
whatever web service you plan to use (legacy web services, service stack, wcf, Web API, etc) you'll find that all of them have to use a process to serialize the data and it could be the case that you'll need to do the inverse process in your front end application.
you have to design your ws very carefully because you have to think how you're going to expose those services and the level of encapsulation/abstraction you will have to put in place, a bad design in a web service layer definetely will be a headache for you during development and production.
Security: In most cases you will have to validate every input in those web services as well
Advantages
well that's very relative to call an advantage, it depends more on what are your app requirements, some questions you need to answer are like the following:
Do I need to share data with other apps (mobile, desktop, other web
apps)?
Do I need to expose some functionalities to other business (third
parties)?
Recomendation
If you plan to do a CRUD application I'll recomend to go with REST definetely is the best option due to it's architecture (POST,DELETE,GET,ETC).
if you don't need you a web service right now, you can try to develop your service layer kind of like a service implementation in service stack but try to remain as POCO as possible and if for some reason you'll need a web service you can try to refector the service layer intead to have another level of indirection in the middle.
just my two cents...
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!