Direct vs. Brokered Authentication

The authentication pattern map identifies two architectural approaches for implementing authentication: Direct and Brokered. These patterns focus on the relationships that exist between a requestor and service who participate in a Web service interaction. When both the Requestor and Service participate in a trust relationship that allows them to share and validate credentials, then Direct authentication can be performed as shown below:

Examples where this is appropriate would be an Intranet application where all of the users belong to the same Active Directory domain. Another example would be a custom authentication implementation that requires a username and password to authenticate the requestor using information from a database.

In a situation where the Requestor and Service do not share a direct trust relationship, you can use a broker to perform authentication as shown below:

It is important to note that this diagram represents a high-level view of Brokered authentication. For instance, while the security token is always verified, the service typically does not need to interact with the broker to perform the verification. The reason for this is that the token itself can contain proof of a relationship with the broker, which can be used by the service to verify the token.

In addition to the different relationships, there are other factors that may support one approach over the other. For instance, message protection requirements may dictate the use of Brokered authentication when Direct authentication is available. The support for different security infrastructures also has an influence on the authentication method used. Table 1 represents a decision matrix that provides a list of factors to consider and how those factors are supported by different authentication methods.

Table 1: Authentication Decision Matrix

Factor to Consider	Direct	Brokered
What will the Service require to prove the requestor’s identity for authentication? Passwords, certificates, or something else?	Direct authentication requires the presentation of credentials, which are typically a username and password. Service uses these credentials to authenticate the request.	Credentials are used to authenticate with the broker, which issues a security token. The security token is then used to authenticate with services.
Will the Web service be able to communicate with the identity provider that can validate the subject's credentials for authentication?	Since authentication is performed, direct access to the identity provider is required.	Most implementations of Brokered authentication do not require direct access to the Identity Provider.
Existing infrastructure to leverage?	Direct authentication works with any infrastructure used to provide credential management.	Brokered authentication requires an infrastructure in place that supports the type of security token that is used.
Is single sign on (SSO) support required?	Requires authentication for every call. The process of authenticating the user on every call can have a negative impact on performance when multiple services are involved.	Uses a Security Token that allows access to services after authentication has been performed. This same token could be used to access all services within an organization.
Will your application need to make multiple calls to the same Service? In other words, should a security session be established?	It would be possible to cache the credentials, however, that is not a recommended procedure.	Security tokens can be used to establish a security session. Most tokens have a short lifetime and can safely be cached for multiple calls.
Is Windows Impersonation or Delegation required?	If a username and password were sent with the message it would be possible to impersonate the user. This would only work if the user had a Windows User Account.	Kerberos provides the ability to implement delegation.

One thing to keep in mind is that these are just some of the factors that need to be considered. Other factors related to security policies and threats identified during a security analysis should also be considered.

Implementation patterns have been created to provide examples of Direct and Brokered authentication. The pattern map in Figure 1 shows the implementation patterns and pattlets related to Direct authentication.

Figure 1

Direct Authentication Pattern Map

As you can see from this diagram, message layer implementations of Direct authentication use the UsernameToken security token in Microsoft Web Services Enhancements (WSE). When it comes to Brokered authentication, you can use message layer tokens supported by WSE or transport layer versions that use the same security infrastructure that WSE uses for some of its security tokens.