I am trying to implement the WebMatrix.WebData.WebSecurity() method in a .Net desktop application, the application will connect to a database on the server together with a MVC4 project so I would like to use the current provider on both applications to authenticate a user.
I was wondering if this is possible as I am getting the exception:
{System.InvalidOperationException: To call this method, the
"Membership.Provider" property must be an instance of
"ExtendedMembershipProvider".
at WebMatrix.WebData.WebSecurity.VerifyProvider()
I have copied the Web.Config of my MVC4 application into my app.config file but I still cannot seem to get it to work. Any direction would be appreciated
Edit
It is something to do with the [InitializeSimpleMembership] attribute that sits on an MVC4 Controller. This performs some Initialisation for WebSecurity. Can anyone see how to initialise this code without it being an attribute?
Thanks again
Thanks
I am trying to implement the WebMatrix.WebData.WebSecurity() method in
a .Net desktop application
Forget about it. The Membership provider is tightly coupled with the ASP.NET context and not intended to be used in desktop applications. It depends on things like HttpContext, cookies, ... which do not exist in a desktop application.
What you could do instead is to define a reusable service layer that you could use in your desktop application directly and then have an implementation of an ASP.NET membership provider calling the methods of this service layer, thus reusing the same functionality between the two.
Related
I'll try to explain the situation in the best way possible, I hope someone out there can guide me a bit.
We have a working .NET MVC 4 app where we've added a service reference to consume a WCF external service.
We've created several classes and methods to translate our data model to service's one, so we can call it's different methods from within our app using our data model.
Now we have a new requisite: to add our own service, which can be accessed from outside our environment, and who has to replicate some of the methods of the original service.
The idea is that users will post info to our environment through our service, we'll apply several treatments to the info, and then post it to the original service.
So my question here is: How do I create and attach the new service to my MVC app so I can get advantage of the classes and methods that are already developed and the data model of the original service?
I have a Solution divided into 3 projects.
Two of them are MVC 5 web apps which use ASP.Net Identity provider.
One is a class library which is referenced by the other projects. All the CRUD actions take place in here.
All the projects point to same DB and operate via EF.
All the business logic happens in the class library but is user agnostic. User validation happens in web apps only. Problems here are user validation code is repeated across all web projects and the class library has no idea of the user invoking an API.
This kind of architecture will bring maintenance nightmares very soon so I would like only the class library to talk to db for business logic or user validation.
Now, since ASP.Net Identity provider doesn't work in class libraries, anybody found a way around it?
I am not sure what "maintenance nightmare" you are referring to by having security in the web application. It is a good thing to decouple your application domain from your security model. Your domain model and business logic may remain the same across certain web applications but the security model may vary. I would not bundle these together. And if it is in your class libraries how will you let the OWIN security framework handle forms authentication for you. Are you going to manage all of this in your class libraries as well.
When you refer to "user validation" I assume you are talking about authorization. If you must perform authorization in your class libraries I would implement a custom ClaimsAuthorizationManager. You would override the CheckAccess method to perform your authorization. The ClaimsAuthorizationManager is configured in your web.config so you could have different ClaimsAuthorizationManager's for different web applications. But the logic in your class libraries would remain the same. Anywhere that you want to authorize the user before performing an action you would insert:
ClaimsPrincipalPermission.CheckAccess("MyResource", "MyAction");
The resource and action passed is used in the custom ClaimsAuthorizationManager you created to know the context in which the authorization is taking place. I talk about this method for decoupling your security model from your application domain in this article. If the authorization fails a SecurityException is thrown. You would let this percolate up to your web application where you handle it appropriately (redirect in a controller or an HTTP unauthorized error for Web APi's). Note that this architecture will work if you use your class libraries in non-web applications as well. I have used this with ASP.NET Identity and it works well.
I have written a MVC web application that is used on our corporate intranet. We also have an MVC web site that is a seperate web application that is used by our customers. For our website to talk to our intranet systems database I have written a c# web service to access it.
The problem I have now is in the intranet application I have a complex routine that does some calculations that I now need in the web service for the website to do the same thing. I do not want to copy the logic and have it repeated in 2 locations for obvious reasons, so I need the web service and web application to share the same code base. I know this is possible but what is the best was to go about the use of application variables stored in web config files. For example if I move the code out of the intranet app and into a class library I will loose the functionality of being able to access the webconfig file, so where do I put these variables?
Any Suggestions on the best way to do this?
I will loose the functionality of being able to access the webconfig
file, so where do I put these variables?
You won't loose that ability. Every part of your application can access the configuration file, for instance by using the ConfigurationManager.AppSettings property.
Put the shared code in a class library that is referenced from both the web site and the web service.
Im developing a desktop application in WPF that relies on a webservice to log in and get license information. This means that the user logs in and i build a client side (in my desktop application) object with the licensing and the login date etc.
Im using StructureMap and want to pass my IMyUser implementation into my ViewModels constructor (constructor DI). My question is this, where should i put my initialization of my structure map if im to pass my IMyUser implementation into the constructor?
Im thinking after i login and have created the IMyUserObject i can configure StructureMap and pass it the instance of my user object. This would be somewhat "late" in my application (normally i put it in my app class, so its run as the first thing within my application).
If this is not the proper way to utilize the IMyUser and DI please advice, also alternative solitions would be greatly appreciated.
As this is a question about authorization I think it would be much better handled by a custom IPrincipal implementation.
When the application starts up, assign an implementation to Thread.CurrentPrincipal. This initial instance should not authorize the user.
When the user has logged in and received the license information, replace or update Thread.CurrentPrincipal to authorize the user to use the application.
This is an example of the Ambient Context pattern. You don't need to involve StructureMap in this interaction.
I am doing a rebuild of a website and I'm trying to use an SOA approach. The current website is in .NET 2.0 and uses the out of the box SqlMembershipProvider.
We're trying to eliminate direct connections to the database and push everything through a WCF service layer. The approach we're using for this is to have everything separated - There's a library for models and interfaces, a library for the services, and then a library for the service proxies.
The biggest hurdle so far is figuring out how to manage user authentication and their session. What's the best way to do this with this approach.
Should we scrap the .NET membership model and go with something like OpenId, and just allow users to reconnect their data to the new account?
I've done some searching and can't find a lot on how to manage this, though I know it's been done before.
Here's what I ended up doing, in case anyone is interested. I started off using the WCF Authentication Services, but then realized it didn't give me everything I wanted. I could log on and off, but will still have to create my own methods for registration and getting the MembershipUser.
So I went in my ServiceContracts library and create an interface I called IMembership. At first, I created it as a class and inherited from MembershipProvider so that I could get all the method stubs generated for me. Once they were generated I modified the stubs and made it into an interface.
Then I went into my Services Library and created the implementation for the interface which was simple, because for the implementation I just used Membership.Provider....
Then in my Service Provider Clients library, I did the usual implementing of the IMembership interface, also inheriting from ClientBase<>. Right next to it I created a WCFMembershipProvider, which implemented MembershipProvider, and called the methods from the MembershipClient I just created.
In my WebApp that host the WCF Services I set up my SQL Membership provider in the web.config, and then created my svc file and endpoints for the service.
In the consuming web app, I just added the service client reference to the svc, and then set up the Membership Provider for my WCFMembershipProvider.
And viola - I'm in business.
A lot of repetitive code, but it works nice.
The principal problem you will run into when trying to create a WCF service and maintain the equivalent of session state is that there are no cookies (since there is no browser to maintain them), so the .NET membership providers are not going to be terribly helpful by default. I know how I have handled the equivalent issue is to have a generated token (for instance, a Guid) correspond with the state information I need to maintain.
Your question, however, is more about authentication. I don't know that you would be able to make an OpenId implementation work through WCF (though I understand it works great for plain old ASPX). You could use just a simple username/password authentication scheme (possibly using the MembershipProvider manually, if you need it for dealing with the password encryption in the database), and you can pass the username and password through the service using (most likely) Transport security (SSL).
I hope this helps somewhat. Maybe someone has come up with a more standard session-state replacement for WCF, but I'm not aware of it if so.
Hard to provide a specific answer without knowing a little bit more about your desired setup.
Do you plan to expose your WCF service as a public accessible independent of your website? Will your web pages access your WCF service directly via AJAX?
The easiest scenario is probably a strict layered deployment UI talks only to Website, only website talks to WCF Service.
http://msdn.microsoft.com/en-us/library/ms731049.aspx is a good read on using the ASP.NET membership model with WCF.
I built a site that used AJAX to talk to the WCF service layer. We used the forms authentication provider with WCF. It worked fine except that there wasn't a graceful way to handle the login through a web service. In our case that was fine as we wanted to the user to go to the website and login by entering credentials.
If you have already invested in collecting user's credentials to work with SQLMembership provider, you could surface it via ADFS+claims based model. This would work with all 3 of the above scenarios. There is a bit of learning to do though