Most Real world web applications have at least one dll library behind them. If we use the ASP.NET membership provider, how can we call the Roles.IsInRole method in the dll?
The possibility of referencing HttpContext is not good. Because, we have a few console application tools that use the same dll to complete a few bulk operations.
It sounds like you need to decouple your Membership mechanism from ASP.NET.
There are some good resources here on how to reference the ASP.NET Membership Provider from Windows Forms applications, which would work in the same way for console applications.
The best one is here (in VB.NET).
However, all suffer the same basic problem, which is that a malicious user could change their configuration to use their own authorisation database. (ASP.NET configuration is not available to users so we don't have the same problem there.)
So a better approach would be to either directly query the ASP.NET membership databases from your code in ADO.NET (which isn't hard: they're fairly straightforward) or to roll your own implementation of the underlying Membership Provider interfaces (detailer on MSDN here). You could then have the ASP.NET Membership Provider call your own code to establish if a user is in a role, and use this code in the same way from your console application.
Related
I have two applications, one in asp.net and the other in asp.net core. I want to share a common database, as well as the same login. Ie, a user can register via asp.net application, and then their identity will be shared with asp.net core application.
Is this possible? I notice that each have their own identity models, and I am looking for a way of sharing this, ie. some documentation to resolve this.
Looking for:
- Is this possible?
- Documentation and more information on implementation (how to)
I am resolving by use of Identity Server, which both applications will hook into. Will just take a bit of re-jigging.
I am writing a new web site and am looking at Asp.Net Identity 2.0. Out of the box, it uses Entity Framework for all of its data access. For the rest of the site, we were creating middleware web services for data access. Our original plan for security sake was that the web servers would talk to middleware and middleware would talk to the database via Entity Framework. We had planned on blocking via firewall database access from the web server.
I see that I can create a custom provider for Identity 2.0 and it in turn could use middleware for it's data access.
Here are my questions:
Is it more secure to not allow the web servers to have direct database access?
If it is more secure, why would Microsoft not build it that way out of the box
If you were starting from scratch like we are, would you recommend using entity framework or writing a custom provider that goes through our middleware layer?
Thanks.
1.) It can be secure. I don't see it as a security issue but coupling issue. What if you want to upgrade or change from Entity Framework in the future? What if you want to change from Identity 2.0? What if you want to upgrade one but you can't because the other doesn't support it yet.
2.) Microsoft wanted to promote it products first and foremost. For simplicity sake if your ok with Entity Framework and Identity 2.0 and don't mind how coupled they are it could be perfectly fine solution.
3.) How much time/effort can you afford to spend on the custom provider? It might not be worth the effort to create your own provider.
Asp.NET Identity out-of-the-box is actually Asp.Net Identity on Entity Framework. It generates a database, connection string, the model files, the controllers and a context class for you, which you can redirect to your own database for it to generate the Identity tables within. Everything is very secure, and they've taken care of a lot of the authentication/password hashing for you. I wouldn't say it is worth it to create your own provider, but you can also create your own provider within Identity if you want. Identity 2.0 is great. Very easy to add custom table properties, etc.
I'd like to make an OOB Silverlight app based on the Silverlight Business Application template in Visual Studio. The template uses the default ASP.Net membership provider. I understand how to use that to add users and roles, etc. I've found plenty of tutorials on that. What I'd like to be able to do, is configure the Silverlight template so that it uses an existing ASP.Net membership base. We'd like this app to have a companion website (ASP.Net based).
To clarify: We've been able to setup an ASP.Net website and have created a SQL database with the required tables (aspnet_Users, aspnet_Membership, etc.). I'd like to configure a Silverlight app to access the same users and roles that are in those tables.
Can anyone help me out in terms of what I'd need to put in the Web.config? Do I just need a connection string? I'm new to ASP.Net authentication, but I'd rather use what ASP.Net gives me out of the box than have to write my own authentication service. I feel like this should be really easy, and is just a matter of pointing the Silverlight app in the right direction.
I'd like to use Silverlight 5 and .Net 4.5 if I can but I don't mind using an older version of either if it makes things easier.
You can just point the connection string to the existing database.
From this answer:
You can point your connection string for authentication to a database that all application can access.
So if you have the default database that .NET creates, you can point your other application to that as well for authentication.
I have a Webpage made with ASP.Net and another set of tools like a WPF, Windows Forms applications. Is mandatory that the ASP.Net webpage and all the set of applications be authenticated against the same ASP.Net membership provider database.
What I want to know is the best way to authenticate using a WCF service that uses ASP.NET membership provider for the authentication. Is anything made out of the box for authenticate a ASP.NET webpage against a WCF authentication service? I have to implement a Custom Provider? Because the Membership in ASP.NET Webpage fill the IPrinciple User property with user information and I want the same behaviour with a WCF service authentication.
a custom membership provider is how i have done this before. it worked pretty well. my group made the mistake of making the wcf service match the interface of the membership provider, which was unnecessary and messy. if you choose to go this route, i'd recommend making your service contract on your own as you want it and implementing your provider to consume that.
if i was doing it again, though, i wouldn't use wcf at all, but rather just use a membership provider (existing or a custom one, depending on your needs) for the asp.net application that talks directly to the database rather than a wcf layer and have a shared assembly the other tools could use that talks directly to the database. even having common code in a wcf service tier. i don't think using a service really provides a whole lot that you couldn't get by just using a common assembly. the asp.net membership provider is going to be something separate anyway.
this is assuming you are within an environment where you can just have the desktop tools connect to the database. if this is an internet deployed scenario, you probably do need to do this through some kind of service, and wcf is a great candidate for that. it's probably a shorter path, though, to use an existing membership provider and build your wcf service on top of the database that goes with that than to build a membership provider that consumes the wcf service. i don't think it would be a bad choice to do the latter, but you'd probably be better off with the former. this, of course, depends on a lot of factors, though.
I'm currently working on an application that will likely be deployed amongst various organizations within my current workplace. I need to develop a testable and properly designed authentication framework so that for each implementation folks can choose to use either Windows Authentication, Forms Authentication, a home-grown Single-SignOn system OR OpenID.
So given ASP.NET MVC (and in particular I'm using the S#arp Architecture framework) how should I go about doing this?
Ideally it would be nice if folks can simply make changes to the web.config file in each case.
Thanks
ASP .NET MVC supports ASP .NET membership provider, making it easier for you to handle Windows/Forms Authentication without any hassle. As long as you specify the required information on the web.config. The default site comes with an example.
For other options of implementation, Kigg has an OpenID implementation which also includes the unit testing code.
I guess that after learning how those work you'll find a way to include your "home-grown Single-SignOn" authentication framework :P
Update:
In order to use the membership provider using your own users table, you must implement a custom provider. The configuration through the web.config will be available anyways, but you'll need to create a class which implements the MembershipProvider abstract class.
Here's a link to a video and some source code explaining how to achieve this.