WP6: The ASSERT4SOA Framework

WP Leader: SAP

The objectives of this work package is to provide a service–oriented architecture to support ASSERT lifecycle including their issuing, binding to service instances, update, revocation, negotiation and protection. In order to promote a rapid adoption of ASSERT within the WS community, our approach will be to build upon existing solutions for SOA functional components like UDDI,WS–Discovery, etc for discovery or PKI , Liberty alliance, SAML, etc for identity management. Complementary, new dedicated components will also be specified and developed. To insure the communication between the different components extension to standard WS–protocols will be provided and new dedicated protocols will be developed. In order to handle the ASSERT versatility, the framework will provide an abstract definition of mechanisms to match, compare and check ASSERTs. These mechanisms will be reused across software components, while their implementation will be provided by the dedicated work packages (e.g. property–based algorithms will be developed in WP4).

ASSERT4SOA Service Inception
The Inception of an ASSERT4SOA Service will rely on a new component: the ASSERT Accredited Authority (AAA). The AAA will be responsible to deliver ASSERT linked to existing schemes’ certification processes (SAS70, CC, ITSEC,…) passed by the service (cf. b. in Figure 7). From a pure technical standpoint, the AAA can be easily compared to a SPKI alike Attribute Authority, the format of ASSERTs, defined in WP1, however will enable to capture ‘standardized’ security properties referring to certification artifacts by using WP3 ASSERT Ontology. Therefore, it is also likely that the evidences collected during the completion of a specific certification
(test results, models, etc) would have to be store on dedicated repositories, referenced by the ASSERT and accessible at run–time.

ASSERT4SOA Service Discovery
The registration stage is very similar to the registration of services in today SOA. Beside the WSDL description of the service, ASSERTs should however be embedded and will be used as metadata by the Service Discovery. Symmetrically, the lookup phase will bind the request for service with the requested assurance properties. The Discovery Service will then match not only services providing the desired functions but also pertinent ASSERTs to provide a list of relevant services. The underlying technology may build upon existing Semantic Discovery to enable efficient and pertinent matchmaking. The advanced mechanisms (matchmaking, interrogation language, etc) will be defined within WP2.

ASSERT4SOA Assurance level Compliance Check
Before establishing the connection between the consumer and the service, the consumer’s Certificate Decision Point (CDP) would check that the service is compliant with the requested assurance level. This extra service is provided by a dedicated component, the Certificate Evaluation Point, that should be able to handle the different types of ASSERT to compare the requested assurance level and the properties certified by the ASSERT. This comparison may be contextual since the consumer may define a policy expressing its preferences– as defined by WP2 – or localized perceptions for matching its desiderata and the service certified claims.

ASSERT to Service binding
Finally, an ASSERT should play for a single service a similar role that an X.509 certificate play for the identity of the server engine: it should enable to provide a trustworthy binding between the service functional andsecurity properties and its consumer. More precisely it should provide a mean for the consumer to be sure that the interactions will respect the assurance level captured by the associated ASSERT. This will require the application server to provide a way to install ASSERT(s) and to enable to securely establish the binding. We imagine than this binding will require introducing an extra challenge response step in the establishment of the session. It will be under the responsibility of the Certificate Administrative Point (CAP) to enable this feature. In order to support developers of applications that use certified services to manage the ASSERT certificates. The WP7 will also define an API and produce a library to parse and manage ASSERTs. Complementary, we will provide example applications illustrating the use of the library in different contexts.

We will embrace an Iterative and Incremental development as software development process. This approach will enable to take advantage of what will be developed on other activities and to quickly provide initial release of the software. At each iteration, design modifications and prioritisations will be made and new functional capabilities will be added. The duration of the life cycle analysis–design–implementation will be initially based on 4 months starting at M12 with 2 major milestones at M24 and M36.

Task 6.1: Detailed Design and Architecture (Leader: SAP, M1-M24):
The design activity will mainly provide a detailed software architecture to be used as a basis for the development in Task 6.2. This architecture will explicit the technologies used, will describe the existing components that will be reused, and will provide an abstract representation of the critical software classes/functions. The initial focus will be the definition of APIs and protocol extensions. A particular attention will be dedicated to the security of the architectural design to address our concerns with respect of the potential threats to the ASSERT4SOA framework.

Task 6.2: Development (Leader: SAP, M13-M36):
The work on task will start as soon as a first release of the design document based on WP1 results and refined in Task 6.1 will become available. It is foreseen that the development will start with the production of a mockup, in order to verify the interfaces and the general architecture of the system. We will then produce a sequence of releases of the tool, which will progressively cover larger portions of the ASSERTs lifecycle. The development effort will follow the principles of modern software engineering methodologies, taking into account the advantages deriving from a development cycle producing a continuous sequence of releases, supported by the use of modern configuration management and versioning tools. The development activity will be documented and the partners will insure that coding best practices will be used to minimize the vulnerabilities of the ASSERT4SOA framework.

Task 6.3: Integration of modules (Leader: Eng, M19-M36):
The work on this task will mainly consist in providing support to WP3,4 and 5 to implement the abstract definition of mechanisms to match, compare and check ASSERTs and to achieve the integration of the dedicated mechanisms in the generic framework.

template joomla