I'm wondering what the basic protocol is for storing users in a database, creating accounts, and authenticating them - with ASP.NET MVC 3 framework (using C#), and Azure SQL.
More specifically:
1.) Where in an ASP.NET C# MVC3 Visual Studio project do I write code that only runs on the back-end? Such as logging into my database as an admin, so I can write to and read from the database.
2.) Where should I make database calls from using MVC framework? Do I call a back-end function (e.g. - to create a new account in the database) from the controller?
Thanks for any help!
I'm not 100% sure whether you are talking about SQL Users or Application users.
However, generally, what ASP.Net MVC applications do is:
they use one or two defined users to connect to the database (e.g. they might define a read-write and a readonly connection for different types of queries)
they use the ASP.Net Membership API for application-level user accounts
they use an ORM framework like NHibernate or Entity Framework for other database access
There are lots of tutorials and articles for this sort of information out there - one place to look might be Scott Hanselman's blog - see:
a tutorial on using ASP.Net Membership with SQL Azure
the Mix11 tools walkthrough - including Code First Entity Framework
1) You could use Membership (which I used to use) or simply write your own Authentication code. There are 2 drawbacks with Membership. First, there are a ton of tables and stored procedures that are installed but worse, there's no way to change a user name via the Membership API. Try telling a customer that they cannot change their username (which is usually their email address) and they'll give you weird looks.
2) Forget EF and use your own repository, which simply harnesses SPROCs. Go ahead, make a ton of changes to your EF design canvas, change the db schema, and I can guarantee you will run into issues with the "behind the scene" files at one point or another.
Related
Azure AD
First, due to area restrictions, we are not using Azure AD B2C. We tested this option in the end of the last year but it was not stable. Azure AD B2B looks more stable, but we still have some beta API’s, like the invitation one.
The invitation procedure is working fine, but we could not customize the language. This would be helpful. We could customize the screen as we click in Get Started. However, when the user is already a member, we could not customize the login screen. We tried to do so, but unfortunately, it did not work, as you can see on the pictures.
Another point that I would like to comment is the process to transit between one Web App to another (we have five web apps using the same AD authentication process). The time to transit is too slow sometimes. I do not know if there is a different way to configure it.
Entity Framework Core
For basic use, EF Core is working fine, with a good performance.
However, we have difficulties regarding using EF Core for a multi-tenant scenario. In our scenario, a single user (owner of a supermarket, for example) can have access to different databases (stores). The solution we worked together with Felipe and Waldemir was setting up different schemas to different customers and stores. Therefore, we have to change the schema we are using online. We could handle it using EF Core, but it was not a simple task.
Talking about simple tasks in EF Core, we discovered that WITH NO LOCK and some Group By statements do not create a good SQL command. Our decision to this scenario is to work with some Stored Procedures. Maybe we are creating the lambda statement in a wrong way, but we need some documentation to do so.
We have a BI team that have created a wonderful data warehouse that works fine for the internal staff using it through Excel on the internal network. They use windows authentication through the domain controller, and everything works fine, including restricting the access to users and AD Groups.
The issue is that we now want to provide the same access to a wider audience that is not part of our Windows Domain. This is further complicated by the fact that the information on the users that need access to the system is already stored in another location (an application with a SQL database).
The goal is to make it so that they connect (probably using HTTPS) to the cube (using Excel Analysis services integration), and be authenticated using the Username/Password that they had in the main application.
The main application has a WCF Service interface for user authentication, and session management, so all I really need is a way to provide authentication in front of the MSMDpump.dll against that WebService. We can also add in a Role Mapping so that we can define the SSAS roles against the users in the application.
I was thinking that I could create a dll that has the same interface as the MSMDPUMP.dll, and have that translate calls between the client and the main dll, but this seems a bit of overkill.
Are there any pre-built tools to do this? (and yes I know that Sharepoint can do something like this, but that's not an option so please don't suggest it). Does anybody know of any blogs detailing how to do it?
Any pointers in where to start with creating an interface between the 2?
The question is similar to How to secure MS SSAS 2005 for HTTP remote access via Internet? however, I'm looking at providing the authentication mechanism from another datasource, and providing the Roles to SSAS, not the users. We don't want to have to setup a new user in SSAS for every user that is setup in the external application.
UPDATE: To be clear, they external users need to connect to the cube using Excel, and the data returned needs to be filtered by the role they're in and the security applied in the Cube.
We are able to cahnge the cube to use Dynamic Dimension Security and use CustomData attributes if that helps.
The eventual solution ended up being a combination of a Third Party Control and Dynamic Dimension Security.
We found that it's not possible to easily apply a MembershipProvider interface to the MSMDPUMP interface without significant effort, so our solution gave them a Web Interface to use instead.
The Control we used was by DevExpress and is their "PivotGrid" control. It's not free, but is significantly less than the development resource costs of implementing any other custom solution.
Along with the control, we've applied Dynamic Dimension Security to the Cube so each user of the Site will have a dedicated connectionString to the cube with "CustomData" appended to the connectionstring. This allows us to delegate Data Segregation tasks to the Cube and BI team, and let the Web Developers concentrate on the display of the controls.
The solution is working quite well, and doesn't involve heavy weight applications like Sharepoint/Excel Services. It can built directly into your site and branded as you need, providing a sales tool as well as a useful functional tool.
Can you create a limited-access user on the cube db (read-only, only for the relevant cube, etc.) and hard-code that user/password into a connection string on the app db?
I have made the database using ASP.Net Configuration(aspnet_regsql.exe tool) . I want to use EF 4.1 to write the
Data Access Layer. (I'll then use it in a WCF service and consume services from a WPF application)
How can I use EF 4.1 to do that .....
So for a simple demo sake .. I want to write Functions for User Management
I know I have to use DataBase first (IN EF 4.1) approach .. but there are so many tables and usually Database entry is done using Stored Procedures(Or the classes provided by the Sql Membership Provider).... and when I add one user or role... Many tables get Updated simultaneously (Sp's does that) ... will EF 4.1 will do the same by examining the structure of database..
I cant write any code because I don't know how to start off (except I have made the database)
How can I mimic the same behavior using EF 4.1
Any pointers in this regard will be helpful.
I want to write Functions for User Management
No you don't or at least you should not! Membership API is self contained. It contains whole logic for user management and that logic is divided between .NET and stored procedures. If you want to access the API through WCF either use Authentication Service directly or wrap the standard API calls into new WCF service without working directly with database.
Direct access to membership database means breaking membership API contract and in most cases it also means creating less secure and less encapsulated solution. Standard membership and role classes cannot be mapped with EF back to membership database - you will have to create your own entities which will break the original encapsulation.
If you just want to create custom authentication and you don't want to use anything from Membership API except the database you should create your own database for your exact requirements.
Apologies for the newbie web service question -
I am trying to create a webservice that has a list of methods to perform read/writes to a database. An example function will be of form -
CreateNewEmployee(string username, string employeeid, string deptname)
I created a webservice in .net (asmx) that has the above mentioned webmethod. In that, I open the connection to the data base and do an insert in to the database and then close the connections. Is this the right way to design the web service call?
Should I instead be passing an object instead of multiple parameters?
Any pointers toward best practices when trying to create a webservice that writes data into a database?
To add some more information
We would like to have web services since it might be reused by many different applications within the organization (both web and desktop).
We are also planning to create an environment where users can use these web services to create data mashups.
Thanks,
Nate
Yes - pass objects vs large parameter sets. Also, have you considered WCF if you're in a .Net environment? If you look at how ADO.Net Data Services (formerly Astoria) works, it will put you in the right direction.
Quoting from the winning answer to this SO question:
Web Services are an absolutely horrible choice for data access.
It's a ton of overhead and complexity for almost zero benefit.
You can read the rest of the discussion there.
Edit: One excellent approach to having a common data access functionality that can be shared by multiple applications - web, desktop, service - is to create a Visual Studio project that compiles to a DLL. Each solution that wants to use the data access functionality references the DLL, which can deployed to the GAC or some other central location, or just added to the project's bin folder. Alternately, in order to be able to step through the data access code, the data access project can be added to a solution.
This is a very common practice in large enterprises, where many back office applications share common functionality. It is used not just for data access, but also for other services such as logging and authentication/authorization. Some divisions create a set of these DLLs, which they refer to as their "framework". It ensures that every application will have the same functionality and the same business logic, and that there is a single place for revisions to be made that will affect all of the applications. This is a similar benefit to using web services, but it avoids the overhead and performance hit of web services.
There is a website with a server database. I'm building a desktop application which uses data from one of the tables. Hacker can just take password from assembly.
How can I protect the database?
I wouldn't store the database information in the application at all. Instead, I would create an API to the database on the website, perhaps implementing a RESTful interface or having queries that return data in an appropriate format, such as JSON, XML, or even plain text. The application could then call these web services and process the results. All of your database information stays on the server, where it is (hopefully) secure.
The API adds a sometimes unnecessary application layer. Not all applications i've been involved with easily convert from using database calls to webservice calls. If the application has not been written i guess it would not matter that much.
My alternative implementation is:
Connect to the server using a secure tunnel of some sort.
Save the password encrypted on disk.
This would save me the effort of creating an API, which in most of my projects would be a waste of time.
This alternative is not viable if let's say you want to distribute the application to customers.
Your can
A) create a three tier system. Your client could interface with a server that in turn interfaces with the database. The server stores the access credentials.
B) create personal accounts on the database for your users. This two tier model is applicable if fine grained access control to data is needed. E.g. in an inhouse application with different user roles.
Don't let the database user the application logs in as perform any write operations or read operations on anything but the application data.
Or, choose a sane architecture, as Thomas mentions above. Databases are for storing and retrieving data, they are not a generic application server.