I'm creating a WCF service to share all membership operations (such as user creation, login, change password, etc) between multiple applications (websites, WS, IPhone App, etc), using the ASP.NET Membership Provider.
I want also to store information about application sending the request.
I'm wondering if it make sense to dynamically set the Membershio provider's Application
Name so to store this info in the membership tables? Since the provider is a singleton it would be something like :
System.Web.Security.Membership.ApplicationName = application;
bool isValid = System.Web.Security.Membership.ValidateUser(username, password);
It actually works but don't know if this is a proper use and if it can cause any trouble in future. Usually as far as I know the application name comes from the Web.config (but in my scenario it would be always the same, the WCF one) and I haven't seen any example where this Property is dynamically set.
Another option would be to store this info in a separate table and leave the Application Name static coming from web.config.
Any suggestion is welcome!
That's not what the application name is for in the membership providers.
You say that you want the user accounts to be shared between multiple applications. In this case the membership application name must be the same between all applications.
The app name is there to allow multiple applications to share the same database but keep their users isolated - a web site configured with an application of app1 will not share users with an application of app2 even if they share the same physical membership database.
Log it elsewhere!
Related
So, I am developing an Web Application in .Net Core 6. I have two API's, one for User authentication (using Identity), and another for executing my app services. For each API i have an separate DB, one for storing the users information, and another for storing my services information. Let's say that one of my services is uploading a file to my server. In that case i need to know witch user has uploaded the file, relating the file with the user. However, since my user is in another DB, i cannot make an relationship between them.
I thought in referencing the user Id with an Integer, getting the information in API requests, but in that case, if i delete the user, it will still reference him. Should I just make my app services tables in the DB that stores the user authentication info ?
For distributed systems like your describing, I recommend using a Guid/Unique Identifiers.
It's also not uncommon to store some user information across distributed systems for that exact purpose of not losing the associated information. That said, you should be careful to always have a source of truth such as the identity server, and possible setup sync jobs that will keep the other services "eventually updated." This is often done using message bus to send updates and have listeners for your services that will pickup changes such as name, contact info, or hierarchy data.
Hope that helps.
We have about 10 internal .NET Core 2.1+ and .NET 5 MVC web applications, all using Windows auth with hard-coded permissions based on AD groups. Some extend roles and permissions to the database, but each project have their own scheme.
I’m trying to move to a centralized identity database that all applications can talk to, as well as claims-based permissions (CanEditThing instead of wrapping in User.IsInRole(“Marketing”)). A benefit of this is to keep Active Directory data synchronized in one location instead of putting the same slow DirectorySearcher boilerplate code in each application, as well as quickly generate reports for Auditors showing who has been authorized access to what application.
What is the best or standard way to handle this? All applications share a central Users/Permissions database via common connection string? Or, authenticate users via IdentityServer and JWT combo and keep individual permissions confined to the individual application’s db? Is there a better way to handle this?
Thanks for your insight!
Background
I'm building a single tier application Winforms application using C#. A SQL Server localdb database is attached to the application that runs when the application does. The plan was to use Windows Authentication to verify that the user is part of the MyApplication role/group and can use the application. But, in order to prevent users from accessing the database via other means, I was thinking of using an Application Role so that only the one SQL application user can edit the db tables.
Question
My understanding is that in order to use an Application Role, you need to provide a username and password in the connection string. I can encrypt this information, but obviously it will need decoded before being sent to the database. Is this a concern in a single tier application? What are other alternatives?
To use an application Role, you'll use the sp_setapprole stored procedure where you will provide the name of the application role and the password, rather than sending it in the connection string. When you use application roles, you still connect using an ordinary login, but once you successfully sp_setapprole, your connection loses its user permissions and instead gains the permissions of the application role. Having the decoded password in memory is a concern if you have reason to believe that users may decide to use a debugger to attach to your process to extract the password. Any administrator would also be able to decrypt the encrypted password on disk as well if you choose to use windows machine-level key containers. Using only a single tier for an application that uses a database is a security risk, and you have to decide based on the circumstances surrounding the application whether it is an acceptable risk to gain the reward of skipping a few weeks of design and development.
Source:
https://technet.microsoft.com/en-us/library/ms190998(v=sql.110).aspx
I highly recommend implementing a web api to manage your application's interactions with the database as well as security. This web api could use a windows "service" account to authenticate with the database, and users would authenticate with the api using their individual windows accounts. This has the added benefit of you never having to think about passwords. As far as managing API permissions, that is an issue that is up to you to design and implement as you see fit. The main issue you need to understand and deal with is uniquely identifying AD users. Take a look at this SO post for more info on that: What Active Directory field do I use to uniquely identify a user?
Your service account would have all necessary permissions on the database to do what the application needs to do, but not all api users would necessarily have permission to use all api functions. You would manage a store of uniquely identified AD users that have permission to use the application and what permissions they have. The rest is design and implementation details that are up to you.
Define user with privilege only to execute stored procedures. By this way if someone use SQL Management Studio, s/he cannot browse/edit tables and even cannot see the table names.
I'm starting to use the membership provider.
My first idea is to create 2 different mvc3 applications: one for the Web Site and the other to administer the first one. Each application has a different applicationName (WebSite and AdminWebSite).
I want to create Users of WebSite using the application AdminWebSite. Is it possible?
Yes, can specify multiple providers and reference them by provider name. Just make sure that the provider settings for WebSite in AdminWebSite are defined exactly the same way.
Hi Developers/Architects,
This is more of an Architectural question:
I have a web application. The application use ASP Membership API (froms authentication) for users/roles management.
We host a separate application for each of our clients. So basically each client has an Application Name in ASP Membership database. That client then create his roles/users according to his need.
The reason why we have same website, hosted on IIS for each client separately under client name's virtual directory, is because all of the clients have their separate Application Name (in terms of ASP Membership), and the underlying database is separate for each client as well.
so each client has a separate URL, e.g: http://mysite/client1. and then client1 has his own users, roles. The underlying application database used by application is clients individual.
The Web Application and the database schema is exactly same for all clients.
I can not take any decision regarding the database part. So i am not going to discuss that.
But i want to change the approach of hosting separate application for each client. I want to host one application for all clients:
this brings some questions:
Q1. how would i create these urls: http://mysite/client1, http://mysite/client2 (as i can not put names of all clients on the main login page, and then once user selects the client name, provides username/password .... i can not do that due to the nature of the business)*
Q2. I can not create single application (on IIS and on ASP Membership level) and then separate clients by roles, because all clients have roles within themselves, and plus, 2 or more clients can have a user by same name; so userX for client1 and userX for client2. theses users are different, but they happen to have same names.
* One solution to Q1 can be: that i create a new forwarder application, which is hosted for each client separately in IIS under client's virtual directory. And when client opens their url (e.g: http://mysiteforworder/client1) they are redirected to (http://mysite/Default.apsx?app=hjuk98jkio8) where (hjuk98jkio8) is a encrypted name of the client, that we use internally.
this would resolve Q1, but not Q2.
let me know what options do I have ...
Here's an idea I've used a few times before.
You can set up multiple Web Applications / Virtual Directories in IIS, e.g. /client1 and /client2, that point to the same physical web application path on disk. That way the code is still the same for all customers, all managed centrally, but there are different URLs for different customers.
Using WMI you can even script or automate creation/maintenance of the webapps/vdirs in IIS.
To determine which DB to connect to, or which app is running, you can look at the URL being accessed and use the first part of the path as a key into a configuration dictionary for that customer.