In a multi-tenant (seperate database per client) model is possible or even desireable to use either the Microsoft MembershipProvider or the SimpleMembership providers?
the original membership provider is configured from the web.config and the Simplemembershipprovider (in MVC4 template) has a method which initialises the database per application start rather than per session or request.
Is it the case that the membership/simplemembership providers are therefore tied into the application or inprinciple is it a sensible fit to change the database connection to point to the requesting clients database per request?
It's possible with my custom membership provider:
http://blog.gauffin.org/2011/09/a-more-structured-membershipprovider/
Create your custom IAccountRepository on top of the one in the SqlServer package. A lot easier than implementing your own provider.
I've seen and implemented something very similar to that, based on code from ASP.NET: Supporting Dynamic Applications.
This is not the same as what you are asking - the goal here it to use the same membership database, but with a different Application Name for each client.
I am not sure how you can set the connection string dynamically though - SqlMembershipProvider does not expose that property. You might start with Initialize, but as you've said, it doesn't run on each request. There is also the option of creating your own provider, and creating an internal SqlMembershipProvider per request.
We established that we needed to use dependancy injection to add custommembership providers per tenant request. Through thorough investigation it was apparent that we couldnt modify the connection for the membership provider and ensure it hadnt been remodified by another request prior to completion of the request. Due to its singleton design.
Cheers
Tim
Related
We are starting a new ASP.NET Core web site and the customer would like to handle the authorization using the database. So they want to configure custom roles and the actions to be configured in the database.
I have been trying to find an example or something to help me implement this, but could not find. Can this be achieved using the Authorize attribute from framework or a custom filter needs to be implemented?
EDIT:
I should probably mention that the application is an intranet so Windows Authentication is used for authentication
Short answer Yes.
Long answer...
This can all be achieved from the database you can configure up using existing methods with Identity, and from there create all the custom roles and even policies that you want to have and be able to assign, to each user individually or via roles.. Authorize attribute will work just fine with cookies. My only recommendation is that you try not handle security yourself but let the framework handle this for you.
I have been exploring on spring-session framework for session management in our application, and we want to store session in database. I understand that spring provides implementation with JDBC and we can configure our own DataSource. The problem I'm facing is that we don't have direct access to db and need to make web service call to do any sort of crud operations.
So, is there a way to integrate spring-session to consume web services for session related crud operations in db ?
Another question is, can we change the schema for session related tables. I know that we can change the table names, but is it possible to add or remove further columns in the given tables ?
You can employ your custom session repository fairly easy - use #EnableSpringHttpSession (which imports SpringHttpSessionConfiguration) to configure common Spring Session components and register your SessionRepository implementation #Bean.
Regarding more advanced customization of schema used by JdbcOperationsSessionRepository, this was considered during implementation of JDBC support however decision was made not to provide this initially. If you need this feature please consider creating an feature request in Spring Session issue tracker.
I am currently developing an ASP.Net MVC web application that requires username and password authentication. I started looking into using ASP.Net Identity for this however I have a very important requirement, the requirement is that the web application itself has no direct access to any databases, all DB Access is to be exposed to the application via an internal REST service. This is due to certain security polices we follow.
I realise that ASP.Net identity is capable of supporting external authentication methods but my question is split into 2 parts.
1) How would I configure ASP.Net Identity to use my custom REST service for authentication?
2) How would I go about developing a service that can be used by Identity for authentication ? (what would need to be returned from the service to ASP.Net Identity)
Any help on this would be most appreciated.
I just did what you are asking about. First, as FPar suggested, you need to implement an IUserStore and pass that to your UserManager. Your custom IUserStore will implement the interface, I used Resharper to generate stubs, but instead of using entity framework, you will use HttpClient to make calls to your REST service.
The REST service will have one action on a controller, I called my identityController, for each of the interface methods you actually need. I implemented the userstore, userloginstore and the rolestore, with code for about 10 calls I actually used. The identitycontroller then is what actually accesses the database.
I also retained the fully async pattern, using async REST calls and Database looks, both with and without entity framework. A shortened version of my data access code is in another question here, regarding IUserLoginStore::AddLoginAsync. In that class I actually used the original entityframework implementation of the user store for part of work, and eventually settled on plain (except for async) ado.net for the parts I couldn't make work that way. The tables are simple enough, using your ORM of choice would not take a lot of time.
Good luck!
You want to implement your own IUserStore and then pass a reference to the UserManager. Look into the Startup and the IdentityConfig files in the standarad ASP.NET MVC with individual user account authentication, to see, how to use them.
You can look here for an IUserStore implementation with entity framework. This is a template, you could start from and change it to your needs. However, you don't have to implement all interfaces, just implement the interfaces, you really need. The UserManager is able to handle that (it throws an exception, if you call a method, that requires an interface, that you don't implement.)
These are two excellent articles on this subject:
http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
http://www.codeproject.com/Articles/762428/ASP-NET-MVC-and-Identity-Understanding-the-Basics
I have a few classes that are instantiated using ninject "Session Scoping" - because these objects get passed between controller methods and then only get persisted once, this technique worked well for this project.
With Azure's multi-hosting capabilities I assume that InSessionScope is no longer reliable because any of the servers could be servicing my request.
Does anyone know if I am wrong and can still use Session Scoping with Azure or does anyone know of an alternative to this?
In this case you would use a custom session state provider that works with Windows Azure:
Session State Provider for Windows Azure Caching
Azure Providers
Now if you use a session state provider other than InProc, you'll need to make sure that whatever you store in session is serializable. You should test this since this might have an impact on how your application works today.
I'm using ASP.NET MVC and I am trying to separate a lot of my logic. Eventually, this application will be pretty big. It's basically a SaaS app that I need to allow for different kinds of clients to access. I have a two part question; the first deals with my general design and the second deals with how to utilize in ASP.NET MVC
Primarily, there will initially be an ASP.NET MVC "client" front-end and there will be a set of web-services for third parties to interact with (perhaps mobile, etc).
I realize I could have the ASP.NET MVC app interact just through the Web Service but I think that is unnecessary overhead.
So, I am creating an API that will essentially be a DLL that the Web App and the Web Services will utilize. The API consists of the main set of business logic and Data Transfer Objects, etc. (So, this includes methods like CreateCustomer, EditProduct, etc for example)
Also, my permissions requirements are a little complicated. I can't really use a straight Roles system as I need to have some fine-grained permissions (but all permissions are positive rights). So, I don't think I can really use the ASP.NET Roles/Membership system or if I can it seems like I'd be doing more work than rolling my own. I've used Membership before and for this one I think I'd rather roll my own.
Both the Web App and Web Services will need to keep security as a concern. So, my design is kind of like this:
Each method in the API will need to verify the security of the caller
In the Web App, each "page" ("action" in MVC speak) will also check the user's permissions (So, don't present the user with the "Add Customer" button if the user does not have that right but also whenever the API receives AddCustomer(), check the security too)
I think the Web Service really needs the checking in the DLL because it may not always be used in some kind of pre-authenticated context (like using Session/Cookies in a Web App); also having the security checks in the API means I don't really HAVE TO check it in other places if I'm on a mobile (say iPhone) and don't want to do all kinds of checking on the client
However, in the Web App I think there will be some duplication of work since the Web App checks the user's security before presenting the user with options, which is ok, but I was thinking of a way to avoid this duplication by allowing the Web App to tell the API not check the security; while the Web Service would always want security to be verified
Is this a good method? If not, what's better? If so, what's a good way of implementing this. I was thinking of doing this:
In the API, I would have two functions for each action:
// Here, "Credential" objects are just something I made up
public void AddCustomer(string customerName, Credential credential
, bool checkSecurity)
{
if(checkSecurity)
{
if(Has_Rights_To_Add_Customer(credential)) // made up for clarity
{
AddCustomer(customerName);
}
else
// throw an exception or somehow present an error
}
else
AddCustomer(customerName);
}
public void AddCustomer(string customerName)
{
// actual logic to add the customer into the DB or whatever
// Would it be good for this method to verify that the caller is the Web App
// through some method?
}
So, is this a good design or should I do something differently?
My next question is that clearly it doesn't seem like I can really use [Authorize ...] for determining if a user has the permissions to do something. In fact, one action might depend on a variety of permissions and the View might hide or show certain options depending on the permission.
What's the best way to do this? Should I have some kind of PermissionSet object that the user carries around throughout the Web App in Session or whatever and the MVC Action method would check if that user can use that Action and then the View will have some ViewData or whatever where it checks the various permissions to do Hide/Show?
What you propose will not work. Actions can be cached, and when they are, the action (and hence your home-rolled security) does not run. ASP.NET membership, however, still works, since the MVC caching is aware of it.
You need to work with ASP.NET membership instead of trying to reinvent it. You can, among other things:
Implement a custom membership provider or role provider.
Subtype AuthorizeAttribute and reimplement AuthorizeCore.
Use Microsoft Geneva/Windows Identity Foundation for claims-based access.
Also, I completely disagree with ChaosPandion, who suggests making structural changes in your code before profiling. Avoiding exceptions for "performance" reasons is absurd -- especially the idea that the mere potential to throw an exception for invalid users will somehow tank the performance for valid users. The slowest part of your code is likely elsewhere. Use a profiler to find the real performance issues instead of jumping on the latest micro-"optimization" fad.
The correct reason to avoid exceptions for authorizations is that the correct way to indicate an attempt at unauthorized access in a web app is to change the HTTP status code to 401 Unauthorized, not throwing an exception (which would return 500).
Define your authorisation requirements as a domain service so they are available to both the web and web service implementations.
Use an authorisation filter to perform your authorisation checks within the web application, this should be as simple as creating an auth request object and then passing it to your auth domain service.
If the authorisation fails, return the correct error - a 401 as indicated by Craig Stuntz.
ALWAYS authorise the action. If you can hide the link to unauthorised users - thats nice.
Simplify your views / view logic by writing a HtmlHelper extension method that can show / hide things based on a call to the auth domain service.
To use your authorisation service from the web service is simply a matter of constructing the auth request object from something passed in via the service message instead of from a cookie passed by the users browser.