I'm new to MVC and currently working with MVC6 (EF7, Identity3, VS2015)...
I would like create two different/independent WebApps in one company domain (in different sub domains).
I would like use common/shared identity/login system for both Apps - in different words I would allow user to have one account across both Apps.
I do not have option for domain authentication (the company doesn't use the domain - I know it's weird), so I must? use Individual User Accounts...
What is the best way/practice to create and use common user account across multiple apps ?
In first place I thought about creating two different DBContext in both App: one for Identity (Users DB) and second for App-Related Db...
Such an approach would give me three different databases:
IdentityDb - common for both WebApps,
App1Db
App2Db
However I have doubts if it's good practice and the best way ?
Probably will be enough one DBContext with proper configuration, but I don't have idea where I should start.
I have read about SSO (Single Sign On) - but as far I understand it's about Authentication process, so it's little bit later - so I'm not sure about this direction.
Anyway can't find example how to create common user account/profile across multiple apps.
UPDATE:
My original question is probably too open... I would like ask not only 'what to do' but also 'how to do in MVC6'...
So my additional question is: how can I achieve this in MVC6? What I have to do? Perhaps some example?
If I decide for a separate User DB - then from the point of view of the application I will have two DB? What to do with this in code? Should I create two separate DBContexts - or just one?
Also I have read few opinion here on SO, that using only one DbContext is better and simpler option...
Anyway I have try yesterday works with 2x DBContext - everything works when I create new controller for IdentityDbContext, but I have error when trying create any controller for second DBContext (not associated with Identity)...
(I've put description of this error to new question: MVC6 Working with two DBContexts and error when create new controller)
Thanks in advance for any advice :)
The answer to your question if having three databases is the best way, is: It depends.
The answer to wether or not this is a good practice is irrelevant.
Let me elaborate.
The notion of every app having its dedicated database stems from old fashioned thinking. Big enterprise architectures are made up of all kinds of persistence storages, each chosen to do what it can do best. So it has nothing to do with good practices. You should store the data where it is suited best. Have a look at Domain Driven Design and Bounded Contexts in particular to get a better understanding of what I am talking about.
So the question if you need three databases, if in your particular situation this is the best option, then that is what you should do. To make this answer complete I' ll describe our situation. We have an old user database with users in it. We can't get rid of it untill all web apps have been phased out. To minimize the effect it has on our customers. So for our new web apps we only use this old database for the users and use azure storage for everything else we need to store. In other words, conceptually our situation is like what you describe. A seperate storage for the users that all other web apps use.
sounds like a good solution to the problem to you?
Update
As to MVC6, Identity Server 3 specific. ID server 3 has the ability to use custom User Service which allowes you to couple any user storage you want. Here are the details: https://identityserver.github.io/Documentation/docs/advanced/userService.html. This is exactly what we have done.
As for your other question; we will put the users in Azure Table Storage probably and retrieve it from there via IdentityServer4 when all old apps are gone. Right now there is nothing left in the legacy MySQL DB but users for us. But there are some old apps still using it, so...
Does this answer your questions?
In previous version of ASP.NET Identity (2) sharing identity cookie across subdomains was the sloution. I'm not sure about ver 3 but you can test it:
change Identity config in Configure method of Startup class:
services.AddIdentity<ApplicationUser, IdentityRole>(config =>
{
config.Cookies.ApplicationCookie.CookieDomain = ".domain.com";
})
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddDefaultTokenProviders();
Related
For example I have 2 databases. One of them is called ecommerce which contains real customer information. Another is called ec1 which basically contains only views from tables of ecommerce.
We use our ec1 database to connect to our website or apps. How secure is this method in terms of back end security?
Only exposing ec1 is better than exposing ecommerce because you can reset ec1 using your "safe" values in case of corruption and you can keep some secret data only stored in ecommerce if it doesn't need to be used by your website or your app.
However, this is only a small portion of backend security. Having two different databases with real data and data views doesn't matter a lot if someone can access your server OR can corrupt your data.
I mean, if someone found a way to get some data he should be not authorized to read, it is bad even if it comes from ec1 and not from ecommerce
So yeah, exposing only views is a BETTER solution, but nothing can be said on the overall security because it mainly doesn't depend on that
EDIT: A detailed explaination of backend security is way beyond the possibility of a simple stackoverflow answer (and probably i am not the best teacher) but for basic server security you must take care of:
- Firewall to stop every request but your webapps ones.
- Updated software
- good database passwords
- The user you use for your application queries must only be able to perform operations on ecl1 database, while the views should be generated with a cron and using a different user
These are the main security enhancement tips that comes to my mind
I've used MongoDB before, but never with ASP.NET MVC.
Currently, I'm stuck trying to implement authentication for system which is going to use exclusively MongoDB (so, I don't have the option of leaving the users table to a SQL database).
Now, I figured a solution would be implementing my own Membership provider. However, that requires quite a lot of code. And, since it is related to security, it is not wise to reivent the wheel if I can avoid it.
Coming from Rails, it would be rather simple to just add something like Devise, set it up to use MongoDB and call it a day. I couldn't find anything similar for ASP.NET MVC - I am not sure if it is an uncommon use case, or if my Google-Fu is inadequate.
I don't need anything fancy -just the ability to create users, check their credentials and protect controllers from being called from unauthenticated users. Are there any packages that could solve my problem?
https://github.com/osuritz/MongoDB.Web
A collection of ASP.NET providers (caching, membership, profiles, roles, session state, web events) for MongoDB.
I would suggest to use https://extmongomembership.codeplex.com/ as this is newer provider that was presented in ASP.NET MVC4. And it contin eve more features (for instance permissions system if need)
I'm looking at implemented a muli-tenant portal solution for my SaaS application using Orchard CMS. I'm pleased that it appears multi-tenancy is a first class feature, but it looks like in order to achieve it, I've got to either a) Create a set of tables for each tenant with a table prefix or b) Have separate databases for each tenant.
I'm trying to build a solution for 10,000+ customers, and so anything that requires me to make physical data schema changes per tenant won't scale. In our SaaS application, we use a tenantID column on all tables, plus the use of nHibernate filters and a heck of a lot of indexes to allow us to scale.
I'd like to do the same in Orchard. So instead of a table for each tenant, I'd like ONE set of tables with a tenantID, and then use filters in the data access layer (NHib) to always pull the right data.
Questions:
1) Is this possible?
2) Has anyone done this?
3) Any thoughts on the best way? I was going to modify the MultiTenancy/NHiberate module source directly.
It is possible, but quite hard to do.
It's also most likely not a scenario for Orchard multi-tenancy, but without any further details I cannot be sure.
This feature fits best in cases where you need to have a totally independent applications and (almost) nothing is supposed to be shared between them - like in shared hosting, for instance. The major drawback is the memory overhead, because each tenant has its own copy of the whole internal object infrastructure.
A much easier approach, instead of trying to put a square peg in a round hole tweaking multi-tenancy, would be to use single tenant and implement your desired multi-tenancy scheme in a separate module on your own, from scratch. You could eg. have a "Tenant" content type and build your module around it.
I have a desktop ERP application used by around 100 customers at different locations.Since its cumbersome to manage deployment and installation of such environment,i am planning to move this to web platform.I came accross this concept of software as service..I intend to go for this design approach...
The challenge i face here is that all customers will have there own databases and i want to make single web application which can connect to all the databases based on some licensing mechanism...
I am not quite sure how to do this.
Feedback and suggestions on this are most welcome.
The SaaS philosophy is building in two principles. Multi tenant principles and local tenant principles. At first you store user stuff in one database, for second user created new database, for third - created new database and etc. In local tenant option you store all data of all users in one database.
At first - you need a database storage (mysql,msslg, other with) , web aplication for use in browser (buld in php, or html5, of adobe flash(OMG!).
Web application conect with database - used permission for users and etc.
at simple thats all!
And a have a question in which for you ERP store a users,passwords,documents and other?
Depending on the answer, to look for a solution.
I need some opinions.
I'm going to develop a POS and inventory software for a friend. This is a one man small scale project so I want to make the architecture as simple as possible.
I'm using Winform to develop the GUI (web interface doesn't make sense for POS software). For the database, I am using Postgresql.
The program will control access based on user roles, so either I have to develop a middle tier, using a web server, to control user access or I can just set user priveleges directly in Postgresql.
Developing a middle tier will be time consuming, and the maintenance will be more complex. So I prefer to set access control directly in the database.
Now it appears that using database to control user access is troublesome. I have to set priveleges for each role. Not to mention that for some tables, the priveleges are at column level. This makes reasoning about the security very hard.
So what I'm doing now is to set all the tables to be inaccessible except by superusers. The program will connect to the database using public role. Because the tables are inaccessible by public, I'm going to make publicly accessible stored functions with SECURITY DEFINER (with superuser role). The only way to access the tables is by using these functions.
I'll put the user roles and passwords in a table. Because the user table itself is inaccessible by non-superuser, I'll make a login function, let's call it fn_login(username, password). fn_login will return a session key if login is successful.
To call other functions, we need to supply session key for the user, e.g.: fn_purchase_list(session_key), fn_purchase_new(session_key, purchase_id, ...).
That way, I'm treating the stored functions as APIs. Adding new user will be easier as I only need to add new rows in the user table rather than adding new Postgresql roles. I won't need to set priveleges at column level. All controls will be done programmatically.
So what do you think? Is this approach feasible and scalable? Is there a better way to do it?
Thanks!
I believe there is a better way to do it. But since you haven't discussed what type of security you need, I cannot elaborate on specifics.
Since you are developing the application code in .NET, that code needs to be trusted (unlike a web application). Therefore, why don't you simply implement your roles and permissions in the application code, rather than the database?
My concern with your stated approach is the human overhead of stored procedures. Would much rather see you write the stated functions in C#, rather than in PostgreSQL. Then, standard version control and software development techniques could apply.
If you wait until somebody has at your database to check security, I think you'll be too late. That's a client/server mentality that went out at the end of the 90s. It's part of the reason why n-tier architectures came into vogue. Client/server can't scale horizontally as well as an n-tier solution.
I'd advise that you take better advantage of the middle tier. Security should be a cross-cutting concern that's further up the stack than your persistence layer.
If the MANAGEMENT of the database security is the issue, then you should add the task of automating that management. That means that you can store higher level data with the database tables, and then your application can convert that data in to the appropriate details and artifacts that the database requires.
It sounds like the database has the detail that you need, you just need to facilitate the management of that detail, and roll that in to your app.
My honest advice: Do not invent POS and inventory software. Take one of existing projects and make it better.