Trusted Subsystem Design
Summary: This paper describes a core set of design principles and an approach for implementing multi-tiered applications that are restricted to only communicate with application components that meet certain quality or security levels. (15 printed pages)
The concept of multi-tiered applications predates the current generation of service-based computing, but remains a valid best practice today for decoupling and encapsulating the functionalities of complex distributed applications.
While decomposing applications into multiple layers facilitates certain design and deployment activities, it also introduces challenges into the development of different facets of application solutions. Of those design issues, recurring ones concern controlling and accounting for access to business data and computing resources exposed by each application tier.
Figure 1. Access control and auditing requirements for multi-tiered applications
We will use a simple scenario illustrated by Figure 1 to explain these design considerations. Figure 1 shows a generic multi-tiered application that is a good representation of the current generation of line-of-business (LOB) applications. In this scenario, a business application initiates an application request through a method in Web Service 1. Web Service 1 is a façade service that in turn calls another method in Web Service 2 to process the user request. The method in Web Service 2 implements internal business logic. Part of the business logic processing requires business data that must be fetched from a backend database. Before responding to the call from Web Service 1, the business logic implementation also writes the business event into an audit log for accounting purposes. The following access control and accounting requirements may arise from this scenario:
- How should we control access to computing resources that provide business logic computation services (such as Web Service 2) and the database that provides data management services? Web Service 2 implements important business logic that is critical for enforcing business policies and processes. Enterprises may want to restrict the ability to execute such mission critical code to a subset of identities. Similarly, the database is where the crown jewels of the business reside. The rights to connect to the database should be handed out judiciously.
- Who should be allowed to access the data? Data privacy requirements or business policies may limit the business information that can be viewed and manipulated by the business application user. For example, insurance agencies may restrict viewing of customer data to the assigned insurance agent. In this case, the business logic will need to make authorization decisions based on the identity of the application user (the insurance agent) and the customer data retrieved from the database. This enforcement is sometimes known as data entitlement.
- Who has already accessed the data? Regulatory requirements may mandate businesses to keep an audit trail of all data related activities, with regard to who accessed what data and when. In our scenario, the Web service will need to know the identity of the business application users to keep accurate records.
Currently, there are two prevalent models for fulfilling the needs previously described:
- Impersonation and Delegation
- Trusted Subsystem
We will describe the two models conceptually and mention how today's implementations of the models are used to solve the access control and auditing issues mentioned earlier. We will then detail some limitations with the current approaches and then apply a set of trusted subsystem design principles to derive an alternate solution.
Impersonation and Delegation
Delegation is the process of allowing another party to act on behalf of an identity. This process bestows upon a party the rights and privileges of another party to perform a set of tasks. Impersonation can be viewed as the most relaxed form of delegation, such that one identity is assigned the complete set of permissions of the impersonated identity. There are two common ways of implementing delegation:
- An identity creates a signed statement with a set of permissions that is assigned to the stated party for a specific duration of time, so that the stated party can present the signed statement and act on the identity's behalf.
- A trusted third party issues signed statements to stated parties enabling those stated parties to act on another identity's behalf for a certain amount of time.
The first model is easier to implement when the subject delegating the rights is aware of the parties that are performing tasks on its behalf. However, in the current multi-tiered distributed computing environment, this is not the common case. More often than not, an end user is not aware of the services that are interacting to complete the user's requests. In these cases, a more suitable form of delegation is used; a third party authorizes on-behalf-of requests. The Kerberos security protocol is a popular implementation of such a scheme. The Kerberos delegation model does not assume that the end user knows about all the cooperating services beforehand. With Kerberos, the Kerberos Distribution Center (KDC) issues "forwardable" tickets that allow services to act on each user's behalf.
Using the Windows impersonation and Kerberos delegation approach, a service wanting to propagate the caller identity will first make an application request to the Windows operating system to impersonate the user locally. Note that impersonation is considered a highly restricted function and the application process identity must possess the Trusted Computing Base (TCB) privilege to impersonate a user. This right can only be assigned by a system administrator on the local machine. When the application process impersonates a user, everything it does locally is authorized and audited using the impersonated user's identity. This means that an application process may also acquire user privileges that the application process identity would not normally have when not impersonating a user.
Kerberos delegation enables an application process to acquire a Kerberos service ticket on behalf of the impersonated user, and the impersonated user's identity is carried forward in the acquired service ticket. The application process can then invoke the remote service using the acquired Kerberos service ticket. The downstream service being invoked will process the request according to the identity in the Kerberos service ticket. Thus, through the delegation process, the (original) user's identity is propagated to downstream services.
In our previous scenario, using Windows impersonation and Kerberos delegation, it is possible to flow the original user's identity downstream, so that the business logic Web service can perform more granular authorization, such as data-level entitlement, as well as record the impersonated user's identity in the audit trail.
Other than enabling multi-tier applications to make application authorization decisions, using Windows impersonation and Kerberos delegation also enhances the security of the application environment through the following features:
- With Windows Kerberos-constrained delegation, administrators can further configure delegation policies so that services can be restricted to act on behalf of users for only a given set of services.
- The Kerberos protocol allows mutual authentication, which means that services can authenticate each other, thus reducing the risks of interacting with rogue services.
- Impersonation and Kerberos delegation are readily available capabilities that are built into the Windows operating systems. This means enterprises that have an Active Directory directory services infrastructure can reuse the same security infrastructure to enable application security.
Despite these benefits, there are also limitations with using the impersonation and delegation model:
- Impersonating users at the OS process level can elevate the process privilege, which may have unintended consequences as a result of elevation-of-privilege security attacks.
- Kerberos delegation requires the application process to contact the KDC to obtain a service ticket on behalf of the user before accessing and invoking downstream services. For applications that are accessing downstream resources on behalf of a large number of users, this security negotiation with the KDC introduces an extra communication latency which may not be acceptable. The obvious solution to cache such security contexts across multiple requests violates stateless recommendations for high-performance services.
- Some applications optimize their performance by sharing a pool of pre-created communication channels for connecting and communicating with downstream services. For example, many business logic tier services have a pool of database connections that the services reuse to communicate with the downstream database. To meet security requirements, each of these database connections requires authentication. When impersonation/delegation is used to propagate the security context of the original caller, an authenticated database connection is created for each impersonated user and the connection pooling technique cannot be used to optimize application performance.
- Access to services such as the business logic Web service must be secured using the impersonated user's identity. In other words, it is necessary to grant permissions to end users to call mission-critical code. In many cases, this is not an acceptable assumption, from the following perspectives:
- It violates the particular view of defense-in-depth which gradually reduces the number of identities that can access higher value assets. The fortress analogy is quite appropriate here. Layers of defensive walls protect the center core of command and control. Fewer trusted officials of higher ranks are allowed access as we move toward the inner core of the fortress. To abide by this principle means that the ability to invoke inner business logic should be restricted to a small set of application identities. When end users can also invoke these services, the security of these services is also dependent on (and at the mercy of) the efficiency of the end user de-provisioning process.
- Giving end users the ability to invoke business logic services also increases the complexity of managing access control for the service. Instead of only having to manage the access rights of a few application identities, we now have to deal with end user identities instead.
The limitations of the impersonation and delegation model provide the motivation for considering the trusted subsystem model.
By definition, the trusted subsystem model implies that application services are trusted to perform a specific set of application tasks, such as processing customer orders. Frequently, downstream services need to make application authorization decisions, such as approving an order submission before performing the business transaction. To do so, the service must know the identity of the end user submitting the order. While the ability to flow the identity of the end user is an inherent property of the delegation model, it is not so for the trusted subsystem model and special efforts must be made to include this feature.
The notion of "trusted" does not come for free. To support the notion of trust as defined by the model, the services must at least be able to:
- Authenticate and verify the identity of the upstream or downstream service they are communicating with.
- Decide if the identified service is a trusted subsystem for a specific set of application functions, including propagating identity claims.
- Protect the integrity of the data being communicated between trusted subsystem and downstream services. Besides application data and application plumbing data, such as the identity claims of the original user, must also be protected so that no man-in-the-middle can modify the identity information that is in transit.
However, many current implementations of alleged "trusted subsystems" do not meet these minimum safeguard requirements. We will substantiate this claim using some observations on how current trusted subsystems are propagating the original user's context.
A common practice today is to propagate the identity of the caller as a custom HTTP or SOAP header. The downstream service looks in the custom HTTP and SOAP header when it needs the original caller's identity. Since the identity propagation often occurs within the organization's network, many application administrators naively assume that it is safe to propagate the data unprotected. In actual fact, many, if not most, application security breaches occur within the organization's internal networks.
Adding transport layer protection, such as using SSL/TLS with client and server authentication, can reduce the security attack surface quite significantly. In Web services environments where Web services endpoints may span multiple transport hops, adding Web service layer security can reduce the chances of man-in-the-middle attacks. This is done by requiring the services to mutually authenticate each other and protect the data integrity of the custom SOAP header.
We can also potentially build on existing X509 public key infrastructure to help a downstream service decide if an upstream service is a trusted subsystem. For instance, a custom certificate usage object identifier (OID) can be defined for a trusted subsystem so that it is issued certificates that contain the trusted subsystem usage OID. The issued certificate may also contain client and server authentication OID, so that the same certificate can also be used for HTTPS or Web services authentication using the X509 Certificate token profile.
Up to this point, the proposed solutions are low-hanging fruit that existing trusted subsystem solutions can incorporate to add additional security protection.
In the next section, we will describe an infrastructure design that allows us to meet the trusted subsystem requirements previously stated. In addition, this trusted subsystem design also satisfies an additional set of security attributes for flowing identity claims. The design goals for this system are summarized here:
- Enable downstream services to authorize service invocations based on application identities instead of end user identities. This requirement helps simplify access management of the service interface.
- Enable a downstream service to positively identify an upstream caller and determine if the upstream caller is also a subsystem trusted for specific application functions. The design must not assume that all application services are trusted subsystems. Instead, it must use security policy mechanisms to specify and determine the kind of application functions that a service can perform.
- Enable an upstream service to protect its communication with downstream services so that the data can be guarded against tampering and other attacks.
- Enable an upstream service to propagate the identity of the original caller to downstream services. The identity context of the original caller is frequently used by application services to authorize business tasks and audit an individual's actions. The design should make this identity data available to the application.
- Unlike the impersonation and delegation model, the design must not operate under the premise of "acting on behalf" of the original user, therefore changing the identity of the application process or thread. The solution should allow trusted subsystems to function like airline service representatives performing the check-in procedure at ticketing counters for identified travelers. The service representatives are not impersonating or acting on behalf of the travelers. Instead, they are the persons that are authorized to perform check-in procedures for travelers at check-in counters. The trusted subsystem design must not require an application to assume another identity to perform its application function.
- In certain cases, a downstream service receiving a propagated identity from a trusted subsystem may also need additional evidence to accept the identity and proceed with the application requests. The process requirement here is akin to the U.S. green card application process. In many companies, corporate attorneys assist with initiating and preparing the green card application for foreign employees. After the initial preparation process is completed, the application document prepared by the corporate legal department is sent to the federal immigration office along with other official documents, such as the applicant's passport. The passport is the additional piece of information that the U.S. federal immigration office will use to prove the identity of the applicant. In the same way, downstream services may require additional evidence from a third party other than the trusted subsystem or user to support the identity claims received from trusted subsystems. For this requirement, our design takes into consideration the following specific evidences that may be required:
- It must be possible for a downstream service to verify that the owner of the propagated identity claim has been recently authenticated by a trusted third party. This reduces the window of time available for a compromised trusted service to propagate false identity claims.
- To further reduce the possibilities of false identity propagations, the service must be able to verify from material facts (for example, the original caller's signature) that a specific call originated from the identity previously identified through the set of propagated claims. This requirement builds on the previous one.
- Decouple the credentials that are used for authentication from the ones that are used to make trusted subsystem claims. This requirement facilitates security policy management. For example, authentication credentials such as X509 certificates usually have a longer lifespan, whereas a service's claim with respect to being a trusted subsystem may have a shorter lifespan that is dependent on the service location in the application environment.
There are two important requirements that must be met in the process of identifying a trusted subsystem:
- The services that are interacting with each other must know that they are communicating with the intended party.
- In situations where not all application services are considered as trusted subsystems, there must be a way for a service to further differentiate services that are trusted to propagate identities from those that are not trusted.
In the previous section, we have already described a few ways where services can mutually authenticate each other. It is certainly possible to leverage existing technologies to accomplish mutual authentication, such as using HTTPS with client and server side X509 certificates or the Kerberos protocol.
In addition to these solutions, it is also possible to use emerging Web service-based technology, such as a security token service that provides third-party brokered authentication to a group of Web service-based applications.
Beyond the authentication and single sign on (SSO) services that are provided by such brokered authentication services, we show here how it is possible to extend the infrastructure so that services can also ride on the authentication mechanism to authorize services as trusted subsystems.
Figure 2. A trusted subsystem design
Figure 2 shows a trusted subsystem design that is built on a security token service that provides authentication and SSO service. The underlying security protocols supporting such an infrastructure can be composed by using existing Web services security specifications such as WS-security, WS-trust and WS-secureconversation. This design demonstrates a multi-tiered application scenario where two users, Alice and Bob, are using two instances of Web service applications to access a front-end Web service. The front-end Web service communicates with a downstream Web service to complete the application request.
The next section provides background information detailing how a typical SSO infrastructure for Web services can be expected to function. The information is intended to provide the basic framework which we will extend to implement the trusted subsystem design.
Basic Web Service SSO Framework
Referring to the scenario shown in Figure 2, Alice and Bob authenticate with the security token service to acquire a session token from the STS as a proof of authentication. Subsequently, Alice and Bob can use their respective session tokens with the STS to request service access tokens to the front-end Web service without having to re-authenticate with their primary credentials (for example, password or certificates). The service access token is used to negotiate session keys and prove knowledge of secrets to establish mutual authentication.
The same SSO infrastructure used by Alice and Bob to authenticate and achieve SSO with the front-end Web service is also used by the Web services to mutually authenticate each other. For example, before the front-end Web service can communicate with the downstream Web service, it is required to authenticate with the STS to acquire an STS session token and a service access token to the downstream Web service. Both Web services then mutually authenticate and set up a secure session with each other. The secure session handshaking protocol can be set up by leveraging Web services protocol building blocks such as WS-secureconversation. This secure session negotiation process only has to be done once during the lifespan of the service access token. When the service access token is no longer valid, it may be renewed and the secure session must be renegotiated. Such an infrastructure proves to be very useful for large categories of distributed applications and services that are deployed in enterprises today. The mutually-authenticated security sessions improve security while minimizing performance overhead, since the initial security negotiation can be amortized over multiple application requests and responses transacted through the Web services.
It is also important to note that the concept of security sessions is orthogonal to the application communication paradigm. At first glance, it may appear that such SSO infrastructure is only useful for distributed applications that communicate synchronously. This is not true. The same infrastructure can also be used to secure distributed applications that service asynchronous long-running transactions. For instance, requests into a Web service that processes purchase orders may take a "long time" to complete. Normally, the Web service client will not get back a result indicating whether the business transaction has completed successfully, it only gets back an identifier for the pending order. Eventually, the client is notified of the outcome, commonly via an out-of-band call from the service side. In such application scenario, a security session can still be established and reused between the Web service and client.
Trusted Subsystem Process Extensions
Returning to the topic of a trusted subsystem, we now propose an extension to the plain-vanilla SSO infrastructure by introducing the notion of trusted subsystem policies. The exact trusted subsystem policy model and language may take many forms, and it is not the goal of this document to specify or limit the mechanisms that can be used with this infrastructure level design.
In Step 2 of the high level process shown in Figure 1, the STS checks a trusted subsystem policy store to find out if the front-end Web service requesting a service access token to the downstream Web service is a trusted subsystem for the downstream Web service. If it is, the STS includes the trusted subsystem claim in the access token issued to the front-end Web service. The trusted subsystem claim and the rest of the data in the token are signed by the STS so that the downstream Web service can verify the party (STS) authorizing the claim.
When the downstream Web service processes the access token sent by the front-end Web service in Step 3, it verifies the authenticity of the trusted subsystem claim and notes the fact that the front-end Web service is a trusted subsystem. Depending on the specific nature of the claim, the downstream Web service may accept propagated identities in subsequent application requests from the front-end Web service. Note that the downstream Web service may still enforce requirements for additional evidence supporting the propagated identities. We will discuss the enforcement of this requirement later.
Trusted Subsystem Policies
In addition to the issuance, processing, validation, and enforcement of trusted subsystem claims, there is also a management component for manipulating the trusted subsystem policies. Trusted subsystem policies may take many forms. Existing authorization models such as role-based authorization may also be used to specify trusted subsystem policies. The example shown in Figure 3 modeled different services (workflow services and data adapter services) as application resources. Each of the application resource services may permit the upstream service to perform certain actions according to the role that the accessing service is assigned to. For instance, the trusted subsystem role is defined for the workflow and data adapter services so that trusted services that belong to these roles are permitted to propagate identities to the application resource services. We can then assign individual services to their respective trusted subsystem roles defined for these application resource services.
Figure 3. An example of a trusted subsystem policy using role-based representation
When the STS receives a service access token request for a particular downstream service, it checks whether the requesting service belongs to the trusted subsystem role defined for the downstream service. Alternatively, the STS can also check if the requesting service is allowed to propagate identities to the downstream service. If the result of the policy check asserts that the requesting service is a trusted subsystem, the STS inserts the trusted subsystem claim in the issued access token. It is important for the issued token to have scoping elements defined such that the trusted subsystem claim applies only to the particular downstream service that the policy check has approved. There are many ways that the trusted subsystem claim may be transported inside the service access token. For example, if the service access token is a SAML 1.1 token, the trusted subsystem claim could be a SAML Authorization Decision Assertion inside the SAML token:
<saml:AuthorizationDecisionStatement Decision="Permit" Resource="http://downstreamservice.multitierwebservice.com"> <saml:Actions Namespace="http://..."> <saml:Action>PropagateIdentities</saml:Action> </saml:Actions> <saml:Subject> <saml:NameIdentifier Name="http://frontendservice.multitierwebservice.com" /> </saml:Subject> </saml:AuthorizationDecisionStatement>
In the example provided above, the upstream service identified by the URI http://frontendservice.multitierwebservice.com is a trusted subsystem permitted to propagate identities to the downstream service identified by the URI http://downstreamservice.multitierwebservice.com.
In the previous section, we illustrated how trusted subsystems may be permitted to propagate the original caller's identity claims to downstream services. At the beginning of the paper, we also mentioned the requirement that downstream services may require additional evidences to verify and support the genuineness of the flowed claims. The additional evidences are claims generated by parties other than the immediate upstream trusted subsystem, since different parties may be trusted to assert a limited set of claims. Such capabilities enable the downstream services to assemble additional evidence to securely process the request. For instance, for a downstream service to process a high value financial transaction, such as a $500,000 transfer, there is a need to know that the request in fact has been initiated by the subject identified in the flowed claim. We do not want compromised trusted subsystems to be able to generate such requests under the guise of any user.
In this section, we will show how trusted subsystems can support these requirements by describing the categories of propagated identity tokens.
Categories of Flowed Tokens
The following types of tokens may be propagated by the trusted subsystem:
- Trusted subsystem generated identity tokens
- Third party generated identity tokens
- User self-signed tokens
The first type of propagated identity tokens is generated and issued by the trusted subsystem flowing the identity claims. This token can be as simple as a WS-security username token without the password element, or as complicated as a custom identity token that contains non-standard claims inserted by the trusted subsystem. In all cases, the trusted subsystem signs the identity token before propagating the generated token to downstream services.
For the next few examples, we use the <OriginalCaller> XML element to contain the propagated identities.
In this specific example, the UsernameToken is used to propagate the context of the original caller.
<OriginalCaller> <UsernameToken> <Username>...</Username> </UsernameToken> </OriginalCaller>
A more complicated example of a custom token generated by a trusted subsystem may look like:
<OriginalCaller> <CustomUserContextToken Issuer="http://trustedsubsystem1.multitierwebservices.com"> <Username>...</Username> <Roles>...</Roles> </CustomUserContextToken> </OriginalCaller>
In addition to the name of the original caller, the issued custom token also contains application roles that the user belongs to. Such information may help downstream services make access decisions.
The second type of propagated token comes from a third party that is trusted to perform a set of specialized functions, such as a security token service that provides authentication and single sign-on services to Web services.
The following example shows a trusted subsystem propagating a signed SAML token issued by an STS that provides single sign-on services:
<OriginalCaller> <saml:Assertion AssertionId="SecurityToken-745d68f1-9c63-4216-9fd5-9ebd96fab986" MajorVersion="1" MinorVersion="1" Issuer="http://sso-sts.multitierwebservices.com" ...> ... <ds:signature>...</ds:signature> </saml:Assertion> </OriginalCaller>
The third category of propagated tokens is generated and signed by the user that originated the call. The signature in the token enables trusted subsystems and downstream services to verify the asserted claims in the token.
Here is an example of a user self-signed token that can be used to correlate an application request with the original caller.
<OriginalCaller> <CallerEvidenceToken> <Subject> <X509CertficateToken>...</X509CertificateToken> </Subject> <Timestamp>...</Timestamp> <MessageID>uuid: 5b19a5f5-426c-4cfa-b953-d5dc200e9508</MessageID> <Signature>...</Signature> </CallerEvidenceToken> </OriginalCaller>
The original caller has attached an X509 certificate so that the subject in the X509 certificate can be identified as the original caller. Within the signed evidence, a timestamp element denotes the time when the evidence is generated and a message identifier is used to identify the chain of application requests initiated by the original caller. The timestamp and message identifier are then signed using the private key associated with the X509 certificate.
It is also possible to identify the subject in the evidence via some other means of tokens. For instance, we can also use a username token (without password) with a signature generated using a derived key from the password and some other random data.
This table summarizes the conditions that may lead one to use one type of token over the other:
Table 1. Token type and usage conditions
|Token Type||Usage Conditions|
|Trusted Subsystem Generated Token||When downstream services trust the trusted subsystem to assert the original caller's identity, without requiring additional evidence from other parties.|
|Third Party Generated Token||When the downstream services trust the trusted subsystem to assert claims regarding the original caller in conjunction with third party evidence that satisfies an additional set of security requirements.
For instance, downstream services may want to know that the originating user was recently authenticated by a trusted third party. In this case, the propagated token could be a SAML token issued by an STS providing SSO service.
|User Self-Signed Token||When the trusted subsystem is authorized to perform a set of application functions and when there must be evidence from the original caller that the caller initiated the request.|
In Developing Identity-Aware ASP.NET Applications, Identity and Access Management Services, an approach called identity/credential mapping has been identified as a technique for flowing identities. With identity/credential mapping, a service takes a given identity, and with or without the help of a third party (such as a single sign-on service), maps the given identity into another related set of credentials. The set of mapped credentials may or may not contain authentication data, such as the logon password. The services then use this set of new credentials to gain access to downstream resources. We consider this to be a special function of the trusted subsystem role, where the goal is to transform an identity to another related identity (could be a change in type or namespace) for the purpose of gaining access to downstream resources that only recognize the transformed identity. It is important to note that the types of propagated identity tokens discussed above do not exclude token types that result from the process of identity or credential mapping.
In view of the application requirements that we have discussed, the new approach described in this document brings about the following benefits:
- It considers current application optimization techniques that focus on resource sharing, such as connection pooling, so that an application designer can minimize the tradeoff costs between security and performance. In our model, the trusted subsystem maintains a security session with downstream services. A security context is established for the trusted subsystem that allows the downstream services to exactly authorize and determine the scope of the trust. Subsequently, identity is flowed using one of the three token types mentioned. There is no need for services to establish per-user security context as required by the impersonation/delegation model.
- It cleanly separates out the security concepts and goals of "acting-on-behalf-of" versus "authorized-to-perform." Our trusted subsystem solution outlines the requirements and steps that are necessary to design "authorized-to-perform" systems, which is the model needed to secure a large number of the multi-tier applications currently deployed. Applications requiring delegation should continue to use existing protocols such as Kerberos.
- Our design addresses the frequent need of downstream systems to know the identity of the original caller by implementing secure propagation of the original caller's identity claims.
- Trusted subsystem behavior is managed and driven through policies, allowing for more flexibility in configuring and securing the tiers between applications. The same application service can be configured to be a trusted subsystem when communicating with a CRM service and not a trusted subsystem when communicating with a billing service. Such flexibility encourages reuse of loosely-coupled service components.
- The credentials to prove trusted subsystem claims are decoupled from those that are used to authenticate and identify the services. Authentication credentials are typically longer-lived while application service roles may be different depending on how the service is being used within the larger distributed application context. Our design allows more flexibility for changing service capabilities without introducing additional management overhead and the need for revoking and reissuing authentication credentials.
Design principles and infrastructure implementations to facilitate trusted subsystem communications and identity claims propagation are some of the most needed but also most under-investigated areas in application security.
This paper describes a core set of design principles and an approach for implementing multi-tiered applications that are restricted to only communicate with application components that meet certain quality or security levels. Our design is fully in tune with current service-oriented computing paradigm, where explicit service boundaries, loose–coupling, and policy-driven behavior are key design attributes. With our design approach, services do not make any assumptions about whether a service is a trusted service, services are not tightly bound to a specific set of trusted services or trust settings, and the scope of service trust can be adjusted through configurable run time policies.
At the beginning of this document, we showed how the combination of Windows OS–level impersonation and Kerberos delegation can be used to accomplish secure communications and identity flow between application tiers. We then described the limitations, such as access control management complexities and the restriction of not being able to use optimization techniques like database connection pooling, that led us to investigate the alternative trusted subsystem approach.
We then explored several important security requirements that are fundamental to trusted subsystem designs, which are:
- The ability for services to mutually and positively identify each other.
- The ability for services to determine if whether to trust the identity claims propagated from another service.
- The ability for a service to protect the integrity of application data and identity claims transacted through trusted subsystems.
We also noted existing security technologies that can help meet these requirements, most notably through the use of X509 PKI technologies. However, there is a significant problem with using the X509 infrastructure to perform authorization-related tasks, since X509 certificates typically have a longer lifespan geared towards authentication credentials. It is therefore desirable, from our perspective, to decouple the more transient authorization policies and credentials from those used for authentication.
We proposed an extension to a common authentication broker implemented as a Web service security token service, to issue security tokens with trusted subsystem claims according to configured trusted subsystem policies. The issued tokens enable communicating Web services to determine the services that are trusted for specific application functions, including propagating the original caller's identity information.
We also discussed additional criteria and measures that can be used to enhance security when propagating the original user context using the trusted subsystem model. Specifically, downstream services receiving identity information may require additional evidence from third parties or the original caller to substantiate the propagated identity claims.
We hope that enterprises that are security-minded and that appreciate the benefits of service orientation will find our identity claims-based design to be a novel way of controlling access and securing communications between application tiers.
- Jason Hogg, Dwayne Taylor, and Paul Slator for their input and questions that helped fine-tune the design approaches described in this paper.
- Joy Chong for editing the paper.
- "How To: Use Impersonation and Delegation in ASP.NET 2.0," August 2005, J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan, Patterns and Practices.
- "Authentication and Authorization," January 2004, Patterns and Practices.
- "Developing Identity-Aware ASP.NET Applications, Identity and Access Management Services," July 8th 2004.