Security as a service

In the first chapter, we discussed basic security issues. As shown in table 8.1, we’ve already addressed them except protection against attacks and privacy. Since we will refer to these technologies later in this chapter, let’s summarize.

If all you have are a few simple services, you can build one or more of these mecha- nisms into each of the service and service consumer implementations. Figure 8.1 depicts this approach.

This approach to securing services is simple to implement. The standard protocols and established practices in security are sufficient to deliver this solution. Conse- quently, it is easy to understand and develop. In fact, most enterprise applications are built this way even today.

But what if you need to secure a large number of services, as would be the case in any enterprise? Would you still use the same approach?

Consider what happens if you need to secure a large number of services. If we go by the approach shown in figure 8.1, we have to replicate the security enforcement machinery across all services and service consumers. Worse still, if security require- ments differ for each application (for example, some services may have stricter security controls than others) then the security machinery in each will end up looking similar with subtle differences, leading to high maintenance costs. In addition, this simple design approach does not lend itself to more advanced use cases. What if a service needs to contact other services when processing a message? It would need to transfer the entire security context to all the service providers, which can be complex.

If you are planning on building an enterprise-class framework for securing a large number of services, you will want to explore ways of shifting at least some of the secu- rity enforcement burden from services and service consumers to a shared security ser-

Table 8.1 Review of security technologies described in earlier chapters

Requirement Technology choices See chapter

Making and verifying identity claims

Username and password 4

Username and password digest 4

Kerberos 5

Digital signatures 7

Authentication using JAAS against a variety of repositories 4

Protecting data confidentiality

Point-to-point secure transport with SSL 6

Selective encryption with shared secrets, PKI, or Kerberos 5 and 6

Verifying data integrity and nonrepudiation

Point-to-point secure transport with SSL 6

149

Security as a service

vice. A shared security service will help you enforce security policies consistently across all services. Figure 8.2 illustrates this approach.

One may argue that separation of security as a shared service is not really neces- sary to ensure reuse of security machinery; one can always offer the security imple- mentations as libraries that all services and service consumers can reuse. Even though a security service does offer a superior reuse mechanism—one that is inde- pendent of programming languages and platforms—note that reuse is not the main reason why we are considering implementing security as a shared service. What we are really seeking to address is the challenge of deploying, managing, and evolving security enforcement mechanisms across a large number of services. A security service can be centrally managed and modified quickly to meet rapidly changing business needs. Security machinery reused via libraries cannot provide the same benefit.

Figure 8.1 Security implemented as part of each service and service consumer. Each service implements its own security, which is invoked as a part of service consumer and provider. For instance, the consumer may add username and password information and the provider may validate them and grant access

150 CHAPTER 8 Implementing security as a service

It’s one thing to make a case for a shared security service and another thing to implement it. We have to see how we can pull it off. For example, we need to fig- ure out how services and service consumers invoke the security service, how the credentials are communicated, and so on.

We’ll discuss the technical feasibility of a security service next. Before we do that, a note on terminology is in order. For reasons that will soon become obvious, we will hereafter stick to the terms source endpoint and destination endpoint instead of using terms such as service/service consumer, client/server, and sender/receiver.

Figure 8.2 Security implemented as a separate service to offload most of the security enforcement burden from services and service consumers. Note that services and service consumers may still handle some security tasks. For example, they may have to understand how to use the security service.

151

Security as a service

8.1.1 Is a security service technically feasible?

Implementing security as a service is a lot more technically challenging than enforc- ing security at the endpoints. For it to be technically feasible,1 _{we need to address the} following questions:

 Who invokes the security service? The issue of who invokes the security service seems simple: Whoever needs it will invoke it. What is not obvious is who is sup- posed to need it. We can say that the source endpoint needs to obtain a security clearance before contacting the destination endpoint. Or, we can say that the destination endpoint needs to validate the credentials submitted by the source endpoint. These choices mean that the security service needs to support differ- ent kinds of use cases. For example, a source may simply be interested in get- ting a service ticket or a destination endpoint may be interested in authenticating and authorizing a request.

 How is the security context communicated to the destination endpoint? Endpoints are often interested in the results of security enforcement. For example, a destina- tion endpoint might be interested in knowing the authenticated identity of the caller. Another endpoint might need more than just the identity; it might be interested in knowing the privileges granted to the caller. As you can see, the result of security enforcement is a context that needs to be communicated to the destination endpoint. What constitutes the context varies based on the needs of the endpoint.

 What is the interface for the security service? Given the diverse set of use cases and security technologies a security service should provide, it is not easy to come up with an interface that serves all needs. For example, a security service should be able to validate identity claims made using username tokens, X.509 certificates, and Kerberos tickets. Not only that, the interface should allow for securing the communication with the security service itself!

These issues are addressed by various standards, which we will introduce next. Once we understand these standards, it will become clear that a security service is indeed a technically feasible idea.

8.1.2 Standards for implementing security as a service

A number of standards and technologies need to be brought together when imple- menting security as a service. We have already introduced some of these technologies in previous chapters. We will introduce the rest here. Table 8.2 lists all of these stan- dards and technologies and provides a pointer to the chapter and section that describes each of them.

1 _{We are not discussing the practical issues in migrating from endpoint-enforced security to a security service.}

152 CHAPTER 8 Implementing security as a service

Before we look at SAML, WS-Trust, and the SAML protocol, it helps to look at the pos- sible use cases for a security service. The use case analysis in the next section will help you understand the technical issues in implementing security as a service. This under- standing will in turn help you appreciate the motivations behind each of the stan- dards and technologies we listed in table 8.2.