On our production servers, the admins created a WebUser active directory account which is users for anonymous access to IIS and is also used to authenticate database access with our SQL Server instances using Integrated Security=SSPI in the connection string and identity impersonate="true" in the web.config.
I've often come across situations where I would like to or even need to use forms authentication. However, I using forms authentication, Integrated Security seems to use the logged in user's credentials to authenticate against the database. In these cases I have changed the connection string to use the credentials of a SQL Server users instead. I would prefer to not have a hard coded username and password in the connection string or rather worse in code.
Is it possible to use forms authentication just for user authentication for users and windows authentication with the IIS user for database access? What would be the best practice in such a situation?
Yes, turn off impersonation (ie: impersonate=false) and the forms auth will be used for the web authentication and authorization, but remote calls will use the asp.net process identity.
Related
We are going enhance the authentication and authorization system of our Intranet web app. After having few days reading about ADFS, STS, claim based authentication, asp.net Identity. Still not sure how these things works together.
Most of our intranet web applications are using Windows Integrated Authentication, we uses windows group or AzMan to do role base authorization. We have few applications(Vendor application) use it own user database and form base authentication.
We want to add following features to our web applications.
For Windows Authentication application, we want to let user to Sign Out / Sign in as different user. So when User A using his/her computer to access the application, it will auto logged in (default windows integrated authentication). When he/she do log out, it will redirect to a form to allow to input other user credential.
We want to allow user login to System A using System B username/password.
e.g. For the windows authentication application, we want allow user login to the application using the credential of the Form base application (Vendor application) of via visa
I don't know if ADFS can solve these two problems.
From my understanding, the main purpose of ADFS is to allow access to internal application from Internet, and it require SSL.
Our application all are in Intranet, and we don't want to manage the ssl cert.
But by using ADFS, perhaps I can enable both Windows and Form Authentication on my application, so then let use log out and re-direct him to the login form as which just like he access outside company network. It should solve the problem 1.
For problem 2, what if I can create a custom STS to issue security token by using the user database of the form base authentication appliaction. Then I can use claim based authentication and allow one application can use ADFS and my STS. It should solve my problem 2.
Is my direction correct? or am I complicated the problem?
ADFS will not work without SSL.
Furthermore, all RP have to use SSL.
Internally, users will be logged in seamlessly using WIA. When they logout, they will simply be seamlessly logged in again.
Also ADFS v3.0 and below can only authenticate against AD.
While what you want is possible using ADFS, the question is whether it's a good idea and worth the trouble. It may be more appropriate to ask the user to log out of the machine and log in with a different account so you can stick with Integrated Windows Authentication (IWA). Writing your own security infrastructure is fraught with peril.
If you really feel these are hard requirements and it is worth the trouble, the following may work.
Write an ASP.NET web application based on Katana and enable Integrated Windows Authentication. This will make sure that the first time a completely unauthenticated request comes in, the application will challenge the browser. Subsequent requests will have a WindowsPrincipal populated in the HttpContext.User and Thread.CurrentPrincipal.
Now, write a piece of OWIN middleware that checks if an authentication cookie is present. If the cookie is not present, it checks the Thread.CurrentPrincipal and serializes the claims into a secure cookie.
If the security cookie is present, it overwrites the WindowsPrincipal in Thread.CurrentPrincipal with a new ClaimsPrincipal created from the claims in the cookie.
Now, when a user navigates to the web application the first time, he/she will be logged in automatically using IWA and the cookie will be created. Now, provide a logout action which deletes the authentication cookie and presents the user with a username and password dialog.
In the POST handler for that action, use WIF to talk to the username endpoint in ADFS (using WS-Trust protocol) and try to authenticate the user with the supplied credentials. If successful, use the claims from the returned token to create a new authentication cookie.
We have an internal asp.net web application which has ASP.NET authentication and Windows Authentication enabled so that users can be logged in as soon as they connect to the website using their domain credentials (this is a requirement that we cannot change).
We are currently looking to upgrade our SQL database and understand that SQL Authentication is less secure than integrated security (e.g. https://msdn.microsoft.com/en-us/library/bb669066(v=vs.110).aspx). Currently we use SQL Authentication.
We could easily change the connection string to run using integrated security, however IIS presents the user as the domain user connected to the website (e.g. domain\greg) instead of the service (domain\WebsiteServiceUser), because IIS impersonates the user. This impersonation is needed to access their Exchange Mailbox, files and other things.
If we were to go down this path, we would have to add logons for every user (using AD groups) to SQL Server. This is possible, but in itself presents a new security issue - users would be able to create a SQL connection outside of our web application and run whatever queries they like against the database. All of our authorization could be bypassed.
Is there a way to connect to SQL using Integrated Authentication using the user that the AppPool runs as (Domain\WebsiteServiceUser) instead of connecting as the currently logged on user (Domain\Greg)?
Is it possible to pass Windows domain credentials (users) from their browser directly to MSSQL for database authentication?
Still learning ASP.NET and EF, but I have a working webapp that uses a static DB connection string in my webconfig. I'm using Windows Authentication via IIS to control access to the website, but I need to support read/write permissions in the database, per user.
It would be great if I could just use AD and assign permissions directly in SQL server, instead of having to maintain my own user table and permissions/roles.
It is possible with impersonation. You can configure it to pass the same credentials from the IIS to SQL Server, however, if SQL server is physically in another server, you might need to give some permissions to users. I have done this years ago, but couldn't do it again recently.
Just curious as to best practice for managing db access from an asp.net web application. We were currently putting the username and password in the web.config, but this wasn't good enough internal security (obviously), so I decided to use a windows domain user instead by modifying the web.config to use windows domain, and then adding the user to the app pool identity. This all works fine, but what happens when the domain user's password changes? Does that mean that all the webapps that use this user's identity in app pool will require the password change too? This would be an IT nightmare. Does anyone have suggestions on best approach for allowing webapp to access database without exposing password and without having to update passwords in all webapps if the password changes? Thanks
A better solution would be to set up a separate app pool that is set up with a service account that has full access to the database restart the web app after selecting the new app pool and use integrated security.
Use a very strong ( and lengthy ) password and set the account to password does not expire and user can not change password.
This prevents using clear text in the web.config files.
I would recommend using SQL Mixed-mode Authentication and using a SQL account for your app. The username and password in the web.config and encrypt that section of the config file.
Here is some information about configuration encryption.
http://msdn.microsoft.com/en-us/library/zhhddkxy(v=vs.100).aspx
I use a dbml for my Data Access Layer to provide the data that i need in my app.
When i connect from the server explorer everything seems fine. I choose to use my windows authentication and the connection test shows everything works just fine. When i Build my solution and run it on my IIS it says that i'm using a login that is not working.
How to solve this issue?
The web site will be logging in to the SQL Server using the identity of the application pool of the web site, you have to grant that user (normally network service) access to the database.
When you try to connect from server-explorer and chose windows authentication, it uses currently logged in user to authenticate with the sql-server. You must be logged in as Administrator of the local system so it lets you in using windows authentication.
But when you run your application through IIS, and try to authenticate using windows authentication it uses local system aspnet_user account to authenticate which must not have authorization to access your database. You need to authorize aspnet_user to access your database and it will work.
A recommended practice is to not
authenticate using windows
authentication but to use sql server
authentication which will work in every context.
Did you define the appropriate connectionstring in your web.config?