DNA Authentication Processes

In essence our DNA applications are three-tiered, providing a client layer, a business rules layer, and a data store layer. However, in reality, there are several individual components within the business rules layer that have to be able to communicate with each other. We're talking about components in the widest sense here—they could be custom compiled components (in VB, C++ or Java, for example), Service software such as ODBC drivers, ASP scripts, etc.

These components pass information back and forth, and can create instances of other components in order to use their services. Ultimately, they will talk to a data store of some kind, perhaps through a message queue. Alternatively, they may interface with legacy systems via SNA Server or a similar bridging software layer. At each point of contact along the line, there will be a check that the calling component has the appropriate Windows NT authorization to use the services of the next component.

However, DNA (through MTS, MSMQ, SQL Server, etc.) defines ways of configuring each component-to-component interface to provide two big advantages:

• A more flexible yet secure environment for your application
  
  
• Easier administration and maintenance while the application is in use

We'll see how this is achieved in the remainder of this chapter.

The Different User Contexts

In the following diagram, you can see the most common interfaces where the authentication and checking of permissions is applied:

The numbers in the diagram represent:

1.  - The client accessing our application can be authenticated in a variety of ways. The  access the server via IIS, and this can also encrypt the communication if appropriate. This is where we left off in the previous chapter, when we looked at NT Authentication and IIS security. The end result is that we will either have identified the user via NT and IIS, or they will be accessing our application as an anonymous users under the IUSR_machinename account allocated to IIS.
   
   
2. - IIS now interfaces with one or more components on the server to create the returned page. These could be running stand-alone on the server, in which case the user context from IIS—a validated NT account or the IUSR account—must have access to the component's files (including any system components such as ADO and OLEDB drivers). In our example, however, the components are running inside MTS, and this changes the way the authentication process works. We use the MTS Explorer to define a set of roles for each package and map NT accounts to these roles. The components in each package can use this information to check the permissions for users that access them.
   
   
3. - If a component creates an instance of another component, or just uses its services, it must have permission to do so. We can assign a user context (an NT account) to each MTS package, and MTS will use that account to access other components outside the package rather than the original user's account. If the components are running within the same package, however, permissions are not checked.
   
   
4. - If a component needs to work with MSMQ it must have the appropriate permissions to access queues and to send messages. If security has been enabled in MTS, and an NT user account has been assigned to the package containing this component, the user context that will be presented to MSMQ will be that of the MTS package account, not the original NT user account.
   
   
5. - Finally, to access a data store, a component will again assume the user account context assigned to its package. These details will be passed on to the data store, which must have appropriate permission set up for that account—again, not the original NT user. It's also possible that the data store driver software will access the data store using a different account if this is set up within the driver software, as is sometimes the case with ODBC drivers.

Integrated security with SQL Server and IIS on different machines has certain caveats applied to it. Resources that require Challenge/Response authentication to access resources on another physical NT machine will not be able to do so unless the machine running IIS is a domain controller. This implies that you will not be able to connect to SQL Server on another physical NT machine if the IIS Machine is not the controller for the domain. In this case, basic authentication can be used instead of Challenge/Response, and users won’t be able to access Web pages and connect to the SQL Server with their NT user accounts. This limitation ties back to the inability to delegate. When IIS attempts to make the Name Pipes connection to SQL Server, it will not be able to encrypt a token because it does not have the user’s password necessary as the encryption key.

User Impersonation

The important point to realize is that the account used to access components or services downstream from the user does not have to be the actual user's account. This works in much the same way as when we map multiple users to a single Windows NT account within IIS—either with Certificates or through the anonymous IUSR account. In our DNA application, we can use the features of MTS to map multiple users to one or more Windows NT accounts that are created solely with the purpose of accessing downstream components and resources.

All this swapping of account contexts may seem like it's only making the whole process more complex. Of course, when you are logged on as the system administrator, or if you haven't enabled security on the components and the services they use, there's no problem—it all runs like clockwork. In the next section we'll see how we make sure it still runs like clockwork when we come to deploy it in the 'real world'.

© 1998 by Wrox Press. All rights reserved.