How to integrate Windows domain accounts in ASP. NET applications for permission Control

How to integrate Windows domain accounts in ASP. NET applications for permission Control

 

Enterprise ApplicationsProgramDomain Users have many advantages over independent user management modules.

• The program itself does not need to write a separate user account management module
• Integrated with Domain Users, users can achieve seamless login without having to remember their usernames and passwords separately
• Enhanced security by using the domain user solution. The password is not transmitted online during authentication, and the domain user security level
• Many other benefits

First, you need to configure IIS:

Create a WEB virtual directory for your application, right-click the Directory Security in the attribute, and choose permission and access control. If you do not select "enable Anonymous Access", just select "integrate windows permission authentication ", do not select anything else. OK.

 

There are two ways to integrate domain users to control user access. One is to use NTFS permission to control the table. The disadvantage is that after each application is transferred, Directory Access Permissions must be set one by one. The other method is to configure the Web. config file and control it through the URL. The advantage is that you can directly modify the configuration file without changing the directory once every time you publish an application. Next I will mainly introduce the latter.

 

Drag the application directory tree:

The root directory permission settings overwrite the sub-directory settings and place the management page in a single path. For example, setting an admin sub-directory management page under the root directory is placed under this directory; set a sub-directory of sales. Only the sales comrades can access the sub-directory, and the user can be accessed by anyone. Example:

\ Root \

\ Root \ admin

\ Root \ sales

\ Root \ User

 

Modify the configuration file:

Create the Web. config file under the directory for permission configuration. A configuration file is required under root. In this example, the Management page is placed under the admin path. Therefore, a Web. config configuration file is created under admin.

 

The permission-related content of the web. config configuration file under root is as follows:

<? XML version = "1.0" ?>
< Configuration >
< Connectionstrings >
< Add Name = "Appconnectionstring" Connectionstring = "Data Source = machinename; initial catalog = databasename; Integrated Security = sspi"
</Connectionstrings >
< System. Web >
< Authentication Mode = "Windows"   />
<! -- <Identity impersonate = "true" username = "username" Password = "password"/> -->
< Identity Impersonate = "True" />
< Authorization >
< Allow Roles = "Username, domainname \ username1, domainname \ username2, domainname \ usergroup1"   />
< Deny Users = "*" />
</ Authorization >
</ System. Web >
</ Configuration >

 

Add a web. config file under the Admin directory (the configuration file under the sales directory is similar, that is, allow the sales account to access this directory)

<? XML version = "1.0" ?>
< Configuration >
< System. Web >
< Authorization >
< Allow Roles = "Domainname \ username1, domainname \ usergroup1"   />
< Deny Users = "*" />
</ Authorization >
</ System. Web >
</ Configuration >

 

First, explain the configuration file below Admin. I allow domainname \ username1 to access this management directory, and prohibit any other users from accessing these functional pages.

Next, let's take a look at the configuration file below the root. I added a database link string using the secure connection recommended by MS, and did not use SQL management accounts such as SA.

 

Authentication mode = "Windows"This statement is the key to enabling the application to support domain users.

Allow roles = ",,,"In the list, I specify users who can access the root user. Each user is separated by a comma. Here, you can specify the local server user, the domain user, or the domain user group.

Deny users = ",,,"In the list, I have specified that all users are prohibited from accessing (except for users in the list)

Which of the above two types of tables can use wildcards? Anonymous user, * All Users

 

So far, it's actually done, that's easy.

 

User Agent

Impersonate, unless there are special requirements, such as running the same application on the same server, you need to differentiate the operations of different companies, you can create application pools, using different proxy accounts, otherwise, this proxy account is not required (and may cause performance degradation). This proxy user phenomenon is disabled by default.

 

If the user agent is not used, the system automatically matches the domain username of the client used by the current user to log on to the application each time the user logs on to the application.

If a user agent is used, a proxy user is specified to represent all operation requests of previous users.

 

You can use the following configuration to specify a fixed proxy user.

<Identity impersonate = "true" username = "username" Password = "password"/>

Or use the following settings to specify the user of the application pool as the proxy.

<Identity impersonate = "true"/>

 

By default, this user agent is disabled and has many disadvantages. MS is not recommended for use. Therefore, skip this section.

 

 

The following describes how to use a trusted account to connect to the SQL database.

In fact, this part is widely used. msdn has a special article to explain this. You can refer to it,

Http://msdn.microsoft.com/en-us/library/ms998292.aspx

 

If sa or other SQL-managed user accounts are used, I actually write the password to the configuration file, which is not secure. Of course, Microsoft also provides a remedy, that is, it can use a command line encryption tool to encrypt the configuration file into a password. In short, it is not good. How can we connect to the database with trust? Write the configuration file as follows,

<Connectionstrings>

<Add name = "connectionstringname" connectionstring = "Data Source = servername; initial catalog = databasename; Integrated Security = sspi" providername = "system. Data. sqlclient"/>
</Connectionstrings>

The next step is how to configure the permissions of this trusted user. This account must have the permissions to run IIS applications and to access SQL. Generally, you can specify a specific new user. to simplify the configuration, if both the Web server and SQL Server are on one machine, you can also use the preset service account nt authority \ network service, otherwise, you need to create a domain user in the format of domainname \ webmachinename. Then, the user is assigned the permission to access SQL.

 

 

Specify a running user for the Application

Create a new application pool, right-click the application pool, select attributes, and remove Anonymous users in the identity user representation. Select the user below and select the user you created, you can also use nt authority "network service.

InCodeTo call the domain user permission
Use the following code in the code to view the identity of the visitor domain user.

Page. User. Identity. Name

Page. User. Identity. isauthenticated

Add using system. Security. Principal;

 

Use the following code to view the identity of the user accessing SQL using a trusted link, that is, the user name you specified in the application pool.

Windowsidentity. getcurrent (). Name

 

If you have any mistakes, please criticize and correct them.

 

The icon below illustrates the principle that the application layer uses Windows users for security authentication, while the application layer and data server use trusted links for unified access.