Security Model for Windows Server AppFabric
You must protect your .NET Framework applications managed by Windows Server AppFabric so that you allow users to access only the services and data for which they have authorization. To do this, you must identify users, verify that they are who they say they are, and determine if they have permission to view the information or to perform the task requested. The message exchange between client and server must take place over a secure channel to ensure private information transfer. The Microsoft technologies that support AppFabric provide integrated services that enable companies to securely connect to and use your applications. AppFabric administrators do not need to maintain multiple sets of user databases, and all of the services for literally hundreds of intranet servers can easily be managed from a single graphical tool. The integration of the Microsoft security technologies and products that support AppFabric enable you to assign users access to all resources needed to run their applications.
Key Parts of AppFabric Security
The primary goal of the AppFabric security model is to provide a simple, yet effective, mechanism for the majority of AppFabric users. Because of its integration with existing Windows, .NET Framework, IIS, and SQL Server security models, users can leverage existing security knowledge and skill sets to use the AppFabric security model. Specifically it uses Windows, .NET Framework, IIS, and SQL Server security concepts to enforce different levels of security on the WCF and WF applications it manages. Because AppFabric adds only minor enhancements to an already robust integrated Microsoft security picture, its security model is familiar to administrators who are knowledgeable in Microsoft security concepts. This results in a lower long-term total cost of ownership for AppFabric customers. If you are already familiar with these products and technologies, you can easily secure your application by following the guidance in the Security and Protection section.
AppFabric uses existing security concepts as follows:
Windows security. AppFabric leverages Windows groups and file system security. The robust security architecture of Windows is used consistently across all components of an application, with authentication tied to controlled access to AppFabric resources. For more information, see Windows Security.
.NET Framework security. AppFabric leverages Windows Communication Foundation security for its WCF and WF services. WCF is a SOAP message-based distributed programming platform, and securing messages between clients and services is essential to protecting data. WCF provides a versatile and interoperable platform for exchanging secure messages based upon both the existing security infrastructure and the recognized security standards for SOAP messages. WCF uses concepts that are familiar if you have built secure, distributed applications with existing technologies such as HTTPS, Windows integrated security, or user names and passwords to authenticate users. For more information, see IIS and .NET Framework Security.
IIS security. AppFabric leverages a subset of IIS security features because its services are hosted in the Windows Process Activation service (WAS) and its administration tools are displayed in IIS Manager. IIS is tightly integrated with the Windows operating system to provide the highest levels of security for applications and data. IIS integrates into the Windows NT security model and operating system services such as the file system and directory. AppFabric leverages the concept of application pool identity when AppFabric workflow services need to access the persistence database at runtime. IIS uses the same Windows NT Server Access Control Lists (ACLs) as all other Windows services. And because IIS uses the Windows NT Server user database, AppFabric administrators do not need to create separate user accounts on every Web server, and intranet users need only to log on to their network once. For more information, see IIS and .NET Framework Security.
SQL Server security. AppFabric creates SQL Server database roles to control access to its persistence and monitoring databases. AppFabric uses Windows integrated authentication for access to its SQL Server databases. Integrated security uses the current Windows identity established on the calling thread to access the SQL Server databases. You can then map the Windows identity to the AppFabric SQL Server databases and permissions. For more information, see SQL Server Security.
AppFabric Conceptual Security Roles
To understand the AppFabric security model it helps to understand the attributes of the three AppFabric security roles. These roles are purely conceptual, and you will not find entities with these names anywhere in the security model. However, the conceptual roles manifest themselves in correspondingly mapped physical Windows security groups and SQL Server database roles. In your security solution, you assign users and permissions to these roles as follows:
Application Server Observers. This administrative role gives you full visibility into application persistence and monitoring data. Application Server Observers can:
Enumerate applications and services
View application and service configuration
View monitoring data
Examine persisted instances
Application Server Administrators. This administrative role gives you full control over application configuration, monitoring, and persistence. Application Server Administrators can execute all tasks that the Application Server Observers group can do, as well as the following tasks:
Suspend, resume, terminate, cancel, and delete persisted instances
Create and remove event sources and event collectors
View, purge, and archive monitoring data
Application Server Users. The runtime role is used by IIS at run time to assign the identities of all its application pools hosting applications. This gives the services contained in the applications shared access to persistence databases and system services.
All you need to know as an AppFabric user is that these are the three conceptual AppFabric roles you use when designing your security solution. You assign the appropriate users and permissions as directed in this documentation to their corresponding Windows NT groups and accounts, IIS application pools, and SQL Server logins and database roles. For more information and important security guidance about using AppFabric roles, the security permissions they have, and how they map to Windows security groups and SQL Server database roles, see Windows Security, IIS and .NET Framework Security, and SQL Server Security.
Scope of AppFabric Security
AppFabric uses Windows security accounts and SQL Server logins and database roles to determine the access a user or application has to system resources such as persistence databases, timer data, monitoring data, and configuration files. Access to these resources occurs at both the application and management levels, which are the two areas of logical scope that relate to the AppFabric security model. Application scope surrounds the process of running AppFabric services hosted as IIS applications. Management scope relates to the management of AppFabric from an administration standpoint. To further understand the use of the three AppFabric security roles, let’s examine their use in the context of application scope and management scope.
Application Scope
Application scope defines the actual running of .NET Framework services that are configured in AppFabric and hosted in the WAS process space under IIS. It is not about administration or tooling; these fall under management scope. Application scope concepts apply to the conceptual AppFabric Application Server Users security role. This role maps to the IIS_IUSRS Windows group, which is a Windows security group used for the IIS service account. For more information, see Windows Security, IIS and .NET Framework Security, and SQL Server Security.
Each application runs within one application pool. This pool can be the default application pool, or you can create and configure your own application pool. (The creation and configuration of an application pool is an administrative function discussed in the “Management scope” section below.) You use an application pool to group applications and services into the same worker process space, thus sharing configuration settings and other operating system entities. Because each worker process operates as a separate instance of the worker process executable, W3WP.EXE, the worker process that services one application pool is separated from the worker process that services another. This allows application isolation if you host an application in its own application pool. Application isolation ensures that if a Web application fails, it will not affect applications that are running in other application pools.
Another benefit of application isolation is customized security isolation. This ensures that the configured security principal of the worker process hosting the application pool (which contains the AppFabric.NET Framework service) is used when accessing downstream resources, such as SQL Server. The default application pool identity is the Network_Service account. You can assign your own custom Windows account identity when your application pool is configured in IIS. At run time, WAS forwards any incoming messages from the application pool queue to the proper W3WP.EXE worker process by using the Web application bindings specified in the IIS metabase. This is how AppFabric allows activation using non-HTTP protocols for WCF endpoints and services. IIS dynamically takes all the Windows accounts of its application pools and adds them to the local BUILTIN\IIS_IUSRS Windows security group. This means that if you create your own application pool for your application, IIS automatically adds the identity of your application pool to the IIS_IUsers Windows group.
Using multiple application pools with different security identities allows application isolation with respect to accessing both the AppFabric persistence and monitoring databases at run time. By default these databases are completely shared to all authenticated AppFabric identities used by their hosted application pools. If you need a higher level of security using isolation, you can more granularly assign permissions on specific database resources to specific identities used by specific IIS application pools. You can also control security at run time by creating your own databases for specific applications, and ensuring that connection occurs to those custom databases for the specific identities. Or on a per-application basis you can isolate an application from the monitoring database and only allow it access to the persistence database.
Application scope also applies to the system services that AppFabric installs and uses:
Event Collection service. Collects events sourced by AppFabric and hosted applications.
Workflow Management service. Processes workflow control commands, activates workflow instances with expiring timers, and restarts abandoned workflow services.
Both services run as the NTAuthority\LocalService account. The LocalService account has permission to emit tracking events and also to manipulate persisted instances (terminate, suspend, and resume).
Increasing security controls typically decreases performance. While application isolation increases security capabilities, it also requires increased use of memory and process resources due to the existence of multiple processes. To conserve resources, you might isolate applications by using the .NET Framework appDomain model instead of using separate processes. Two or more applications can safely coexist with the same process within different appDomains and respect each others’ virtual memory and data values.
Management Scope
Management scope defines the administration and tooling related to the administrative management of applications. It is not about the actual execution of .NET Framework services configured in AppFabric; this falls under application scope. Management scope concepts apply to the conceptual AppFabric Application Server Administrators and Application Server Observers security roles.
Management scope relates to the management of AppFabric and its supporting technologies from an administration and system services standpoint. You can perform management operations before an application executes, for example, deploying and configuring a .NET Framework application into AppFabric. You can also perform management operations during execution when a workflow state has been persisted and its next step needs to be processed through the AppFabric user interface. For example, a suspended workflow may need to be resumed. Security permission to manage the configuration and execution of .NET Framework services configured in AppFabric is based upon membership in specific Windows security groups. Management scope also applies to the Event Collection service and Workflow Management service, but in this case from a management and control standpoint rather than from an application standpoint.
The conceptual Application Server Administrators and Application Server Observers security roles map respectively to the local AS_Administrators and AS_Observers Windows NT security groups. The AS_Administrators group contains the Service ID (SID) of the Workflow Management service and the Event Collection service. After the services are registered with the Service Control Manager their SIDs remain constant. This means that the Event Collection service and the Workflow Management service will be members of AS_Administrators regardless of the identity under which they run. This identity is typically NTAuthority\LocalService. So using the SIDs, instead of the service identities, ensures that no other process or service running under the NTAuthority\LocalService identity can be a member of AS_Administrators. For more information about the AppFabric conceptual security roles and how to use them, see Windows Security, IIS and .NET Framework Security, and SQL Server Security.
AppFabric secures management scope at installation time. When Windows PowerShell cmdlets create the monitoring and persistence databases at setup time, the appropriate SQL Server database roles are created based upon the corresponding AppFabric conceptual security roles. For example, all the roles created in SQL Server for AS_Observers are reader roles (MonitoringDbReader role for monitoring and System.Activities.DurableInstancing.InstanceStoreObservers for persistence). The SQL Server database roles defined for the AS_Administrators logon account include all of the database roles linked to the AS_Observers logon account and additional roles to create and modify database entities from an administrative standpoint.
By default, AppFabric setup runs some of the AppFabric cmdlets during its process. AppFabric creates all the necessary local Windows security groups and accounts for a single-server installation of AppFabric. If you are using AppFabric on more than one server, you will have to manually create the Windows domain groups and assign them to the proper Windows security groups for that server to remotely administer the AppFabric installation. As an administrator you should create domain groups as physical manifestations of the Application Server Administrators and Application Server Observers conceptual security roles (that is, DOMAIN\MyAppFabricAdmins and DOMAIN\MyAppFabricObservers). You can then assign those domain accounts to the LOCAL\AS_Administrators and LOCAL\AS_Observers groups on all the AppFabric computers in the domain.
Security Model for Custom Windows PowerShell Scripts and AppFabric Cmdlets
AppFabric does not provide a new security model for custom Windows PowerShell scripts, or for the many Windows PowerShell cmdlets that the AppFabric release contains. As with other aspects of its security model, AppFabric leverages existing security models in its supporting technology. In this case, AppFabric uses the Windows PowerShell security model to enforce security for custom scripts and pre-packaged AppFabric cmdlets.
When an AppFabric Windows PowerShell script runs, it does so by using the identity of its hosting process. This means that the security principal of the user running the cmdlet is passed through as the process ID. There is no way to use impersonation to run the cmdlet under a security context other that that of the user running the hosting process.
While you can interactively execute Windows PowerShell commands by default, the running of Windows PowerShell scripts is disabled initially for the sake of security. You need to enable this through the Windows PowerShell Script Execution group policy to allow your scripts to run.
The Windows PowerShell scripts that ship with AppFabric are digitally signed with a certificate acquired from a certification authority (CA). Signing an entity with a digital certificate from a CA protects the integrity of the package. Through the use of one-way hashing and public key encryption algorithms, the signing process ensures that any modifications made to a package after it was signed by the author are detected and execution of the script is subsequently blocked. You can also use digital signatures to verify that the signed entity has indeed been created by the party who claims to have created it. A simple and less costly alternative to using a CA is to use a local CA and Microsoft Certificate Server to generate a self-signed certificate. You can further protect the certificate by using private key encryption.
.gif "security") Security Note |
|---|
| Using a local CA to sign a Windows PowerShell script package is minimal in its trust policy. While a locally signed package is trusted on the local system, it is not trusted if run on external systems. |
Federated Identity Management and Single Sign-On (SSO)
Federated authentication systems are also known as Web single sign-on (SSO) systems. Federated systems operate across organizational boundaries and connect processes that are using different technologies, identity storage, security approaches, and programming models. With Active Directory Federation Services (ADFS), people in one company can use their existing Active Directory accounts to access servers hosted by a different company. ADFS also establishes a trust relationship between the two companies and a seamless one-time logon (SSO) experience for end users. It enables organizations to share a user's identity information securely.
An HTTP-based application managed by AppFabric is in many ways simply an IIS application. If you need to integrate federated identity management and Web SSO authentication with your application, you can use ADFS just as you would use it for an IIS application. ADFS maps the login account that accesses the application to a domain account, and then authenticates by using that domain account to IIS.
Because .NET Framework 4 uses WCF and its security model for communication between its managed services and their clients, the traditional IIS model of supporting only HTTP-based applications extends beyond HTTP. If you are using HTTP without Transport authentication, or with a non-HTTP application, use the programmatic interface within your service to implement claims identity processing. A claims-aware application uses claims that are present in an ADFS security token to make authorization decisions and provide additional application personalization. As with ADFS, you should understand how claims identity processing works with an IIS application to integrate clams processing with your application.