Policy level security refers to design-time policies and procedures. The policy-level approach typically doesn’t deal with the underlying technology, nor security tools and technology, but addresses security threats through rules, governance, procedures, and education. There are legal issues here as well: Sarbanes-Oxley compliance, for example, or the use of published polices that could protect corporate assets and provide a means to fire employees who violate those policies.

To create a security policy for mashups, you need to run through the use cases and examine how the information and behavior of the underlying corporate systems should be protected. Most enterprises have existing guidelines for security, including policies that may state that data can’t be transmitted outside the firewall without encryption, or that all use of information within a mashup needs to be reported to IT -- or, in some instances, that mashups are not allowed at all.

Indeed, the knee-jerk reaction to mashups has been to not allow mashups before the security organization can wrap its arms around the risks – in much the same way that the Web was initially branded a liability and temporarily banned in many large corporations a dozen years ago. In hindsight, they were right. But just as the obvious value of the Web overcame worry about risks, so will the value of mashups as balanced security polices emerge.

Data-access level security controls access to underlying databases and data stores, ensuring that information leveraged by mashups won’t be compromised. While policy applies here as well, this is mostly a matter of technology to provide the protection, or layers of security between the data and the mashup.

Security at the data-access level is pretty traditional, including password protection at the database, table, and record levels. The mashup must provide credentials in order to consume the data from the data store, but what the mashup does with that information is out of the control of the data-access level security mechanism. That’s where published policies take over…we hope.

Service-access level security is similar to that of security at the data level. Services may exist as part of ERP or CRM applications, for instance, or as new services built in support of an SOA. Typically, but not always, services are accessed via Web service protocols. Services can be mashed up with either presentation- or data-centric mashups -- and therefore must be treated as services that can produce both information and/or behavior. Either way, they must be protected.

Security at the services level depends upon the system in which the services reside. SAP, for instance, employs its own security subsystem to validate access to its APIs or Web services. The mashup must provide the proper credentials in order to access the service or API, but after that, it’s still available for access within the mashup and perhaps to external Web applications as well. So as with data-access level security, a lot depends on the care of the mashup builder.

Screen-access level security provides user ID and password gatekeeping for information transmitted to a user interface. So-called “mash-at-the-glass,” presentation-centric mashups deal with information sent to one screen (the enterprise application) and can be mashed together with information from other screens (Web applications).