The challenge: Make the original caller’s identity flow all the way to the database in a service-oriented architecture.
Here are the assumptions:
1. You are designing an enterprise-wide system and have decided it will consist of a number of autonomous, SOAP-based services.
2. Much of the data behind these services is sensitive. Personal health history information (PHHI), for example.
3. Both internal users (with Active Directory accounts) and external users (without Active Directory accounts) will need to access the services.
4. A user’s identity determines what activities they can perform and what data they can access.
5. Detailed auditing about individual user activity is required.
The diagram below shows a common deployment model for this kind of application. This is similar to Figure 7.4 in Building Secure ASP.Net Applications.
Both internal users and external users access the system through an ASP.Net web application. This web server is located in a demilitarized zone – firewalls separate it from both the Internet and the internal network. Internal users’ credentials are stored in Active Directory. External users’ credentials are checked against a SQL Server database. Since only internal users are in Active Directory, roles for all users are stored in an authorization database. Information in this database is used to construct a GenericPrincipal for each user of the web application.
The application server is configured for Integrated Windows authentication. It authenticates the process identity of the web application. Windows authentication is used to connect to the SQL Server database, which authenticates the identity of the process running on the application server.
Here’s the issue: There is no per-user authorization on the application server or the database. Once we move from the web server to the application server, we authenticate against a single identity. So, we cannot perform any meaningful role-based authorization in the application layer. We also do not know the original caller’s identity for auditing purposes.
How do we design around this? What are the alternatives? What are the tradeoffs?