CNET también está disponible en español.

Ir a español

Don't show this again


Commentary: Keeping developers out of security

Companies selling XML security gateways are spreading some misinformation about the layers--and the labor--needed to keep applications safe and secure.

Commentary: Keeping developers out of security
By Forrester Research
Special to CNET
March 29, 2004, 11:15AM PT

By Randy Heffner, vice president

A recent example of application security misinformation comes from XML security gateway vendors that say companies must have a separate XML security layer to keep application developers out of security.

It is the right idea to keep developers out of security, but you can do this without a separate, disconnected security layer. Besides, a separate security layer presents numerous challenges for consistent enforcement of security policy. The right strategic answer is to integrate security for XML (Extensible Markup Language) and other access channels with the security of the underlying application platform. A practical implementation strategy will start with unified identity and proceed in stages from there.

There are several good reasons to buy an XML security gateway. But vendors of those gateways aren't really on base when they say you must have a separate security layer in front of your Java or Microsoft application platform.

Get Up to Speed on...
Web services
Get the latest headlines and
company-specific news in our
expanded GUTS section.

That's because you don't want to have your application developers writing security code. Vendors are quite right that you should keep developers away from coding for security, but even without an XML security gateway, this can be accomplished, if you do the following:

• Use an application platform's declarative security. What the gateway vendors want you to forget is that application platforms can handle security declaratively and that doing so does not require application developers to write security code. Early support for declarative security with Web services is in place now. For example, with BEA WebLogic Platform 8.1, a Web services handler can consume a WS-Security: SOAP Message Security (WSS-SMS) header and populate a native Java 2 Enterprise Edition security context.

• Encapsulate security code in frameworks. There may be times when security needs to get very close to application code. In such cases, highly skilled architects can write security frameworks for use by the masses of developers. For example, in a highly sensitive application scenario, one may desire to ensure data confidentiality and integrity all the way from the requester's application memory space to that of the application service. This will require encryption and signature processing by the application--not by the infrastructure in front of the application. Sometimes, complex authorization rules also require application code. An application framework can simplify and standardize the handling of such security code.

The need for application security
There is an even bigger problem implicit in the assumption that it is OK to have a separate security layer for XML and Web services: the need to avoid a fragmented security infrastructure.

A major reason to pursue service orientation is to enable the same underlying services to be accessible through multiple channels (portals, Web applications, Web services, interactive voice response and so on). Some, but not necessarily all, of these channels will use Web services, especially while Web services are still maturing.

Related story

XML and Web services are
becoming widely used,
creating a fresh target
for malicious attacks.

If XML has its own separate, stand-alone security stack, by implication, so do other access channels. This causes problems, because you must figure out how:

• To avoid duplicate and inconsistent specification of access policy. It is burdensome to separately specify the same security policy for each channel as opposed to specifying it once in the application platform. But worse, you must ensure that the same policy is specified in multiple places, because the same users will access the same services through a variety of channels.

• To have confidence in consistent access policy enforcement. The more security architecture you have, the higher the risk you have of inconsistent enforcement. A major U.K. financial services firm was concerned enough about this issue to package services as network-accessible Enterprise Java Beans, primarily to increase its confidence that it could enforce security at a single place (as opposed to any other benefits EJBs might provide).

• To ensure that application security is not bypassed. If one protects a service with a separate security layer in front of the application platform, the question becomes, "What if an intruder gets around the separate security layer?" There is not an answer unless the application platform's own security mechanisms are operative.

With multiple access channels to a service, the only place you can guarantee to have consistent security is in the application platform on which the service runs.

The integration game
The notion of separate security layers is workable only for simple applications and small user communities. In general, eschew this notion in favor of the security integration features of XML security gateways.

An integrated approach is more expensive, but better security is the benefit. Even if current implementation budgets do not allow full implementation of these features, planning for them will position your application security architecture for long-term effectiveness and efficiency. The three core design points for security integration are:

• Create a unified user repository. XML security gateways can work with existing user, group and role definitions in Lightweight Directory Access Protocol directories, including Active Directory. If you already have a directory strategy--and many information technology shops do--this will be a comparatively low-cost task. You must still consider security issues, however, like whether to segregate external users in a separate repository or how to ensure that you open no new paths of vulnerability to the unified repository.

• Propagate identity to the application platform. For the application platform's security to be in play, it must know the user, which in turn requires propagation of user identity. Web services standards and product features are not mature enough to make this simple--you will likely have integration work to do. The two parts to the solution are, first, the token format for carrying user identity--such as a Security Assertion Markup Language token or a proprietary Web single sign-on (SSO) token--and second, token conversion mechanisms. You can get these by combining features from XML security gateways, application platforms and your own custom frameworks.

• Create unified authorization services. Unified access policy is best achieved if access policy is specified once in one place. This implies a unified authorization service to enforce the policy across multiple technologies. XML security gateways integrate with Web SSO authorization engines to achieve this. BEA's WebLogic Enterprise Security and Quadrasis' EASI Security Unifier have generalized architectures for such unified authorization services.

© 2004, Forrester Research, Inc. All rights reserved. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.