I am working on a project on ASP.Net with MVC and using ado.net instead of Entity Framework (i mean, all communications with DB done with stored procedure and followed n-tier architecture). Is there any possibility to use OWIN for security and authentication using ado.net?
if not...then suggest any other reference for implementing security and authentication with ADO.Net
you have to implement IAuthenticationManager interface, and write your corresponding services which calls the ADO.Net codes in there.
Rick Strahls article explains well enough.
Related
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.
We want to start using Asp.net web api for our future enterprise services however we do not want to use EF for data access.
Are there any samples out there for Asp.net Web APi working with regular ado.net classes instead of EF?
Thanks.
Are you looking for code samples for how to use e.g., SqlConnection, SqlCommand, SqlDataReader?
You would use the classes in System.Data.SqlClient if you are trying to talk to SQL Server, System.Data.OracleClient if you're trying to talk to Oracle, or System.Data.Odbc if you're trying to talk to MySQL.
Here are some code samples for how to call a stored procedure from ADO.NET. Good luck!
I have a legacy ASP.Net web application that is basically used to process web services.
I am adding some new functionality and would like to start using EF4.1. I'm fairly new to EF, and I'm not quite sure the correct path to take here.
The client using this web service is a Linux based client running Apache, so data will be passed back and forth using SOAP.
My question is, what is the best practice for getting EF models into and out of a SOAP data class? Would using EF POCO classes be the best for this?
You could use the Entity Framework for data access with either a ASMX or WCF web service that will use SOAP.
Using Entities with Web show give you some direction and ideas.
I am designing an ASP.NET (3.5) web application that connects to a Rocket Software UniVerse database. I am in the planning stages right now and need some help in being pointed in the right direction. I am brand new to ASP and C#.
I am shooting for a RESTful design and a MVC pattern. Rocket provides a .NET library called UniObjects.NET which handles everything for connecting and retrieving information from the database.
What would be the best way to in general to log my users into the database, then use that session via connection pooling? I see that in 3.5 there is the ASP.NET Routing Infrastructure and that looks promising am I in the right direction on this?
Also does C# support decorators like Python and Java?
For your application I highly recommend taking a look at the official ASP.NET MVC framework (www.asp.net/mvc). The traditional ASP.NET (which is called WebForms) is clunky when it comes to true separation of concerns, dependency injection, unit testing etc. A very good starting point is:
Free End-to-End tutorial EBook "NerdDinner" - walks you through a complete application with ASP.NET MVC
As for connecting to a database: If your Database has an ADO.NET Provider you should learn the basics of accessing data via ADO.NET (http://msdn.microsoft.com/en-us/library/aa719474.aspx)
It is also recommended to use some kind of OR Mapper like NHibernate or Microsoft Entity Framework for converting relational data to the object-oriented world.
[http://en.wikipedia.org/wiki/Object-relational_mapping]
[http://en.wikipedia.org/wiki/NHibernate]
[http://msdn.microsoft.com/en-us/library/bb399572.aspx]
As this is a very broad topic, please feel free to follow up with any questions you might have. I suggest starting with the NerdDinner Tutorial.
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.