Project ICHIGAN is a voluntary-based attempt to build a reference IT architecture for local governments that can withstand large-scale natural disasters. This architecture is unique in that 1) it has the concept of {em phases} of the situation for which different priorities on non-functional requirements are applied, and 2) the functionalities and services provided by the IT systems in the suffered area will be taken over by those of the ``coupled'' local government. These features pose specific challenges on the information security policy, especially because different policies need to be applied for the different modes. This paper describes two key elements to enable the policy, policy templates and deferred authentication.

WS-I's basic security profile (BSP) defines best practice guidelines for secure Web services communications, enabling interoperability between vendors. However it is difficult for developers to know if their SOA solutions are in fact compliant to these guidelines. In this paper, we discuss methods to assess compliance against BSP. We have implemented runtime validation of SOAP messages to check for compliance against BSP, a method implied by the BSP definition itself. Additionally, we have implemented a novel approach to statically validate WS security policies against BSP using Schematron. From our experiments dynamic validation for BSP compliance offers greater coverage but results in a significant overhead, while static validation is limited in its scope but extremely valuable since under reasonable assumptions it provides assurances about compliance prior to deployment. We conclude with a summation of our results and lessons for SOA practitioners.

Even with a support tool, setting up a Web services security (WS-Security) configuration can be difficult for people who are not familiar with WS-Security. Some of the reasons are that the WS-Security is a very rich specification with many options and often the processing is complicated. This paper introduces an application programming model (WSSAPI) to simplify the programming experience for end users. It was designed by looking at WS-Security processing from an abstract level. Also, it is designed to consider correctness, efficiency, usability, flexibility, portability, and extensibility. End users just follow the six-step programming model provided in WSSAPI to configure WS-Security. The comparison of WSSAPI to others, like WSS4J, WSE, and JSR-105 shows that it is much easier for end users to use WSSAPI. In this paper, existing APIs for WS-Security are reviewed and compared with WSSAPI to evaluate the ease of use and utility.