Given what we know about the possible security solutions, we need to understand some key characteristics of our system.
What authentication is already performed and can the results be used for Web Services?
Most applications require some kind of authentication. Since Web Services require cooperation between multiple components across multiple domains, life would be much simpler if the authentication system that came with the application were flexible enough to accept authentication information from the previous application and to pass it on to the next application. This is seldom done now, although this is changing.
A key aspect of using authentication or other assertions from another source is whether we trust the other source to have done its work correctly and whether we trust the information to be delivered securely. Making these decisions requires detailed knowledge of the operation of the other site and legal agreements defining liabilities. For our Web Services scenario, we will assume that ePortal uses a Web SSO system to
authenticate Joe. This system uses Liberty and creates a SAML assertion that can be embedded in the SOAP message to indicate the initiator of the transaction.
Is the entity being authenticated directly connected to the authenticator?
As described earlier, many authentication systems require that the participants be directly connected to each other and able to interact on a real-time basis. For instance, the client may need to respond to a challenge in order to be authenticated. On the other hand, some authentication systems require a token or a password to be passed on as proof of identity. This information could be passed through intermediate relay points so long as the information is protected or the relay is trusted.
There are times when ePortal is directly connected to eBusiness, and there are times when it isn’t. When requesting product or pricing information, ePortal connects to eBusiness directly. However, when an order is sent to eBusiness, ePortal’s accounting system becomes a SOAP intermediary so that billing and payment information can be recorded.
Is software to support the authentication process acceptable at the client?
This is a big factor in deciding what authentication method to use. Since the client workstations are not generally administered by the same organization as the server, it is common for application developers to be told that no additional software can be installed on the initiator’s workstation. With Internet applications, the initiator’s ties to the server’s organization are loose at best. Requiring the initiator to load more software on her workstation, when there is nothing to enforce compliance, is problematic. Addi- tional software requirements at the client may turn customers away.
Additional software at Joe’s browser, in any form, is not acceptable. This is usually the case with users connected to servers with browsers over the Internet. Additional software at ePortal and eBusiness is acceptable. Both entities had software developed for this application. Security should be part of the requirements.
Must authentication be performed transparently to the application? Or, can the application be modified to add authentication?
Some applications provide interception points. These are predefined points during program execution, including one for authentication, which can be used to insert code to customize the application. Other applications that don’t have these intercept points require access to source code in order to support additional security measures. Adding authentication systems to such applications cannot be done transparently to the appli- cation. Adding security to such applications requires access to source code. In such cases, the application can be responsible for authentication.
Can the application be front-ended or wrapped with code that can support the needed authentication?
When the answer to previous questions is no, this is the solution of last resort. For our example, only the Web server has interception points that are available. This allows a Web SSO system to authenticate Joe. SSL authentication is a candidate for use to meet some of our other authentication requirements. Many applications come SSL enabled, so SSL authentication would not require significant work to implement.
Finally, message-based techniques will generally require additional application code to implement.
Must the authentication system support subsequent impersonation?
In some multitiered applications, it is desirable for the user’s authenticated identity at one tier to be useable for requesting processing at the next tier. The current tier impersonates the user to the next tier to get work done securely under the identity of the user. This topic will be covered in greater detail in Chapters 7, “Security of Infra- structures for Web Services,” 8, “Securing .NET Web Services,” and 10, “Interoperabil- ity of Web Services Security Technologies,” with a discussion of the several possibilities for supporting impersonation.
The authentication system can provide a token for use in establishing the authenti- cated identity at the next tier. The token securely represents a previously completed successful authentication. A forwarded Kerberos ticket is such a token. Another approach is to pass on the actual authenticating information so that the current tier can authenticate itself to the next, thereby establishing its identity. While this approach works, it leads to potential security and administrative problems and isn’t generally recommended. Authentication techniques that rely on passing around authenticating information, such as passwords, are able to support impersonation. Authentication systems that keep the information at the client, such as challenge-response systems, do not. In our example, there is no requirement for impersonation.