The client I work for at the moment wants to use their Active Directory logins with single sign-on when connecting from a domain computer. I have however no experience with Windows Authentication.
The problem however is, that I need to reference the users in the database. Also, the users already should be in the database even if they haven't logged on yet. (Guessing I'm syncing with active directory with LDAP every night??) The reason for that is that other users should be able to assign the user to specific tasks.
See the following basic diagram:
My question is:
Should I use a MemberShipProvider or just extend IPrincipal?
Am I thinking the right way by syncing every night?
How can I prevent the user data is fetched from the database every request?
Use membership provider to connect to LDAP for you, then authenticate with the ValidateUser method in the provider.
Related
I have an application that accesses a database directly. This application controls what user can do according to the context.
At the moment, I am using Windows authentication, but all the users has permissions to select, insert, update and delete, because it is the application which controls the action.
For example, one user can modify a document, but only if the document is created by this user. So in the database the user has to have permissions to create a update, but only if it is the owner of the document. I am not sure if I can handle this case with SQL Server user roles.
But the problem is that all users have all the permissions to the database, so they could use another application, like SQL Server Management Studio, to access the database and do what they want.
So I was thinking in the option to use SQL Server authentication, with full access to the database. This user is not known by users, so they can't use another applications to modify the database.
The problem that I see with this solution is that I have to store the credentials in the client application, and I don't know if it is really a secure way to do it.
If using SQL Server authentication is an good option, how could I store the credentials of the user in a safe way?
I have read about application roles too, but it is needed to store the password in the client application, so I think I would have the same problem. And also I don't see the difference between application role and to use SQL Server authentication.
In summary, is it a good solution to use SQL Server authentication in the way I explained above? And if it is a good option, how could I store credentials in a safe way?
Thanks.
The difference between an application role and using SQL Auth is that the application role password is not enough, by itself, to access the database. The user must be individually authorized first and can be individually monitored and audited.
how could I store the credentials of the user in a safe way?
The application role (or SQL Auth) password is never truly secure when used from a client application running on a machine where the user is an administrator. So you could run the app in desktop virtualization, or a kiosk-mode PC.
But for many scenarios involving mostly-trusted users application role security is good enough, especially when combined with Windows Integrated auth so the users access to the database can be audited.
I have an ASP Core web app that connects to an Azure SQL database.
The users (a handfull of people) can log into the web app using Microsoft, Google or Facebook logins.
Since I've lost my appetite for developing web apps, I want to turn this app into a desktop app.
This presents a number of problems, obviously, with regards to keeping the database credentials safe on the local machine where the app will be running.
I know the advice is to use a web service as data layer between the app and the database, but since I want to scale down my web development activities, not scale them up, this is not a preferred scenario.
I've looked at using DPAPI to encrypt the credentials, but that would mean the credentials need to be encrypted on the local machines. Ideally I'd encrypt them on my machine in a way they can't decrypt them.
Since that's impossible, I don't think this scenario can work.
Ideally I'd have them connect to the database directly with unique credentials, without me having to manage all these accounts manually.
So, is there a way to have users login to Azure SQL using the same 'socials' they use to log in at the moment?
Cheers,
CJ
For instance, how will you prohibit users from removing data from other users. To keep people from updating data from other users and from inputting enormous volumes of data.
As suggests in comment by MaaretenDev building API seems to be best suited. Create an API that will allow you to get greater sophistication and control over the database. Consider utilizing an API instead than direct database access since it causes more difficulties than it solves.
Else you can leverage Azure Active directory users to login so as to have the control.
Note: The new admin name (user or group) cannot already be existing in the virtual master database as a server authentication
user when setting up the Azure AD admin. If such an admin (name)
already exists, the Azure AD admin setup will fail, rolling back its
creation and notifying that such an admin (name) already exists.
Because such a server authentication user is not a member of Azure AD,
any attempt to connect to the server using Azure AD authentication
fails.
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 currently have an app which using Active Directory for authentication. In other words, the IIS virtual directory is setup Active Directory authentication and I do no have to deal with it at all. If you are on the domain, you can get in.
Some customers now also want to add a feature where they can log in using a standard userid/password combo. The scenario being a contractor coming in for a few days with their laptop and need access to the app. There is no point of creating an Active Directory account for such a person.
Is this possible in an ASP.NET app? How would I go about it?
If you converted your app to use Forms Authentication, then you could configure 2 membership providers; one to authenticate against active directory, and the other could use the standard SqlMembershipProvider. This second provider is the one you would create your temporary accounts in.
In regards to authenticating against multiple providers, this is quite straight-forward. This article describes the process.
If you convert the application to use Forms Authentication, you can then process the login method to authenticate off of either Active Directory, or your own internal user database, depending on whatever criteria you expect. There are several articles out there on how to write your own code to perform a simple authentication against Active Directory.
I'd say you probably want your own Authentication Provider as discussed in this article. You'd build the validation logic to auth against the right store depending on your criteria.
We currently have a winforms app that allows users to log in in order to access the system. The authentication system is a custom made kludge. I'm working on a implementing a change that links users NT username and domainname to their existing custom account so that they don't need to repeatedly log in. I'm using WindowsIdentity.GetCurrent().Name then storing that information in a database table that maps to their old accountid. What I'm wondering is if it would be possible for a user to vpn into the network with a computer name that mirrors the real domain name? This could potentially give a rogue user access to someone elses account. I guess the real question is: is there a way to differentiate between the sql servers domain and a users domain without just doing a string compare on the names.
Yes it would if your app was using SQL Authentication to access the database. If you change the Database connection to use trusted authentication then the SQL Server will authenticate the login against the domain controller. So despite the user having access to the application they wouldn't be able to access the database driving the applicaiton. If you did this you could also move the capturing of the user name to a SQL Server stored procedure which would ensure that the name captured matched that of the Domain rather than the local users.
THE SERVER MUST NOT TRUST THE CLIENT.
If the client can get and use credentials to log in to the database server you're toast.
If your server is only a database server and your application does not use trusted connections and your application does not prompt for db credentials you're toast. (See previous statement.)
I'm lazy. I'll patch WindowsIdentity.GetCurrent().Name to return "Administrator" if I feel like it.