7 ENGINEERING VIEWPOINT
7.5 O WNERSHIP PERSPECTIVE
Before a service network is set up for running, a series of requirements and responsibilities related to the governance of the network, as well as security and management challenges must be considered. Govern-ance is concerned with decision-making, security with access control, and management with the execu-tion of a Service Network.
This section addresses these three issues and relates them with operating policies for LifeWatch Service Networks. The components of a service network, e.g. the interacting services, may be under the control of different ownership domains. The operating policies ensure a standardisation across internal and external organizational boundaries.
7.5.1 Governance
According to the OASIS-SOA-RA, governance of a SOA based system must address the following ques-tions in order to achieve specific goals, add value, and reduce risk:
• What decisions must be made to ensure effective management and use?
• Who should make these decisions?
• How will these decisions be made and monitored?
One of the primary topics for governance is how to obtain acceptable terms and conditions in a service contract. Participants of a service interaction are not just the service consumer and provider, but also the owner of the underlying capabilities that the service access. A governance model must establish the rules and policies under which duties and responsibilities are defined and the expectations of the participants are grounded. Participants can express their expectations in terms of transparency, trust, and reliability.
Figure 27 describes governance elements and their roles in order to construct a governance model. The overall governance strategy should be consistent with the goals of the participants. Governance requires an appropriate structure and identification of an authority, which makes the decisions. The leadership represents this authority and is responsible for initiate and control governance, through generation of con-sistent policies, expressing the governance rules and regulations. The participants should recognize the authority of the Leadership, who typically has some control over the Participants. The Leadership pre-scribes or delegates a working group to define the Governance Framework that forms the structure for the Governance Processes. The Governance Framework should enable flexibility indicating a combination of strict control over a set of foundational aspects, as the definition of well-behaved services. To ensure well-behaved services sufficient metrics are needed to know how the service affects the infrastructure and whether it complies with the established policies. The Governance Processes define how governance is to be carried out by providing an unambiguous set of procedures, which are likely reviewed and agreed by the Participants.
Figure 27: Setting up a Governance Model according to OASIS-SOA -RA
LifeWatch Policy: (i) The LifeWatch Governance is expressed through policies and policy descriptions, accessible for all LifeWatch Participants, which are the LifeWatch Stakeholders. Ex-ample of Participants are the LifeWatch Service Centre, the LifeWatch Central Staff, service providers, data providers, tool providers, and related organizations (Networks of Excellences, Projects, Standardization Bodies).
(ii) The LifeWatch Infrastructure should support that Participants understand the intent and the structures of the governance model in order to make governance opera-tional. The LifeWatch Portal should provide access to the governance policies as text, e.g. as part of the LifeWatch Reference Model, the LifeWatch Construction Plan, as well as references to the Standard Specifications underlying the governance frame-work. It is recommended to provide a discovery mechanism, where Participants can search for policies that best meets particular criteria, and a mechanism to inform par-ticipants of significant governance events, e.g. though offering a syndication mecha-nism.
(iii) Service providers should have access to implementations of governance processes for including them into the services.
(iv) The rules and regulations that make governance policies operational should be unambiguously identifiable and version controlled.
(v) Governance relies on metrics to define and measure compliance. The LifeWatch infrastructure should provide automatic test mechanisms to facilitate the proof for compliance and interoperability. A compliance-testing program113 should be devel-oped during the construction phase. The LifeWatch compliance-testing program should develop tools to test general conformance policies like interoperability, usabil-ity, accessibilusabil-ity, and multilingualism, and support the conformance test to service specifications and standards.
All Abstract Service Specifications should be accomplished of a normative Abstract Test Suite, describing how to achieve syntactically, semantically and other conform-ances to the specification. Implementation Specifications of Core Services should be
113 As example can be see the OGC Compliance Testing Program (http://www.opengeospatial.org/compliance) and the Online testing site developed by the Compliance & Interoperability Testing & Evaluation (CITE) Initiative
(http://cite.opengeospatial.org/)
accomplished of automatic test suites and their descriptions to be included into an au-tomatic testing system.
7.5.2 Security
Security is one aspect of confidence in the internality, reliability, and confidentiality of a system. It focus-es on avoiding inappropriate accfocus-ess to rfocus-esourcfocus-es and on accidentally or intentionally misuse of the infra-structure. According to the OASIS-SOA-RA, security can be defined in terms of the “social structures that define the legitimate permissions, obligations, and roles of people in relation to the system, and mechanisms that must be put into place to realize a secure system”.
ISO/IEC 27002 characterizes the following key security concepts:
• Confidentiality: Protection of privacy of participants in their interactions: messages should not be readable to third parties, but the degree of visibility if messages are exchanged and of the partici-pant’s identity to third parties can be defined
• Integrity: Protection of altering exchanged information
• Availability: Concerns the reliability of a system, in other words, if the system offers the service for which it is designed, and the security concept needed to respond to active threats to the system
• Authentication: Concerns the means of identifying the participants in an interaction
• Authorisation: Concerns the means of legitimacy of the interaction, the exchanged actions must be explicitly or implicitly approved
• Non-repudiation: Concerns the accountability of participants: participants should not, at a later time, successfully deny having participated in the interactions.
Although a system will never be able to guaranty these security goals to 100%, a well-designed security model can ensure acceptance levels of security risks.
A security model can be described at three layers:
• At the Network Layer, security is expressed in terms of availability of the services and protection of Denial of Service attacks. On the network layer, general policies or Service Level Agreements (SLAs) about the quality of services can be defined. The Network Layer is beneath the scope of the Reference Model. All Service Networks are assumed to fulfil some general policies.
• At the Transport Layer, security is concerned with the establishment of secure communication channels between sender and receiver. It may include protocols like the HTTP over Transport Layer Security (TLS)114 or HTTP over Secure Sockets Layer (SSL). The security model for the Transport Layer is part of the platform level definition.
• At the Application Layer, security is applied to the messages exchanged between participants.
Web Service Standards addressing security concepts at this layer are WS-Security, XML Digital Signature, XML Encryption, and SAML. The security model of the application layer may be part of the description of the Service Network, but can be specialized for particular applications run-ning inside the Service Network.
The security model comprises three models:
114 TLS is a cryptographic protocol standardized by the IETF, last updated in RFC 5246 (http://tools.ietf.org/html/rfc5246) , that was based on the earlier SSL specifications (http://www.freesoft.org/CIE/Topics/ssl-draft/3-SPEC.HTM)
• The Trust Model ensures to identify and validate the participants and their interactions in the sys-tem. It is depicted in Figure 28 and contains the following concepts, which are related to the OR-CHESTRA UAA Concepts115 as follows:
o Participant: Represents a user or a software component involve in an interaction. The ORCHESTRA Reference Model represents participants as Subjects.
o Trust: Relationship perceived by a stakeholder between a participant and a set of actions and events, which concerns the legitimacy of the actions and events.
o Credentials: Roles and/or set of attributes a stakeholder uses to determine authorisation to actions of a participant.
o Identity: Identifies a participant. It is used together with credentials to provide suitable authorisation before continuing the interaction. The ORCHESTRA Reference Model rep-resents identities as Principals. Each subject may have more than one principal.
o Trust Domain: Abstract space of actions which all share a common trust requirement, i.e.
all participants must be in the same trust relationship. At an application level, a trust do-main may refer to a social structure, e.g. a user group. The ORCHESTRA Reference Model refers to the concept of Group, as a specialization of subject, which can have one or more principals (group principals) identifying the group. Different principals can be assigned to a group as member principals, which are the particular identities of all sub-jects belonging to the group.
Figure 28: OASIS-SOA-RA Trust Model
• The Threat Model can be used to define a list of common threats related to the core security con-cepts, e.g. for message alteration, message interceptions, denial of service attack, spoofing at-tacks, etc.
• The Security Response Model defines levels of risks based on threat assessments and the costs of mitigating those treats. Possible mechanisms are:
o Usage of information encryption to assure confidentiality o Usage of digital signatures to ensure integrity
o Inclusion of a message ID, timestamp, and destination to a message to ensure that each messages ever sent is unique, for protection against replay attacks
o Maintenance complete logs of interactions, usable for auditing purposes to avoid false re-pudiation
LifeWatch Policy: (i) Security policies require mechanisms to support security description administra-tion, storage, and distribution. These mechanisms shall be defined within LifeWatch.
(ii) Security policies should be able to express trust relationships and trust domains, providing the ability to update trust relationships without changes in the hard- and software.
115 See Section 7.5 User Management, Authentication, and Authorisation on the ORCHESTRA Reference Model, which is summarized on Appendix Fehler! Verweisquelle konnte nicht gefunden werden..
116
(iii) Standard Protocols should be used to provide confidentiality, integrity, authenti-cation, authorisation, non-repudiation, and availability.
(iv) Service Specifications and Service Descriptions should be able to reference one or more security policy artefacts.
(v) A Service Network should provide mechanisms for:
- protection of the confidentiality and integrity of messages exchange - policy based identification, authorisation, and authentication - ensuring service availability to the consumers
- ensuring security for a scalable network and between different platforms.
(vi) A Service Network should include instances of the following security services:
- Authentication Service - Authorisation Service - User Management Service
- Service Monitoring Service for Security including monitoring of intrusion detection and prevention, auditing and logging of interactions, security viola-tions, service availability, and support for quality of services.
(v) LifeWatch Services should use an Encryption Interface to abstract encryption techniques, allowing the use of different techniques.
(vi) There shall be an agreed-upon list of Security Policies, e.g. for the Network- and Transport-Layer to be supported by all LifeWatch Service Networks. These policies may also include generally valid aspects of the three security models (trust, treat mod-el, and security response).
(vii) A threat model shall be defined in form of a list of exceptions thrown by the Ser-vice Monitoring SerSer-vice.
7.5.3 Management
Management is concerned with controlling the use, configuration, and availability of resources in accord-ance with the policies of the stakeholders involved. This involves three aspects:
• Management of all resources involved in the Infrastructure/ Service Network.
• Publication and enforcement of the policies and contracts agreed to by the stakeholders.
• Management of the relationships of the participants.
Management may reflexively be considered as part of the service-oriented architecture in that a Manage-ment Service may support it. A manageManage-ment service is meant to manage all the resources of a service-oriented architecture. For being managed, a resource needs to expose its manageability capabilities to the management service. According to OASIS_SOA_RA, manageability capabilities include
1. Lifecycle Manageability – is typically concerned with creation and deletion of a resource and handles the relation to other resources that must coexist.
2. Configuration Manageability – for configuring a resource.
3. Event Monitoring Manageability – supports, for instance, reporting of tracing events and faults.
4. Accounting Manageability – for measuring and accounting for the use of resources by properly identified participants.
5. Quality of Service Manageability – for managing quality of service requirements for a resource, typically a service.
6. Business Performance Manageability – for monitoring and managing business agreements like SLAs (service level agreements).
7. Policy Manageability – for handling policies, e.g. promulgation and enforcement.
8. System Manageability – concerning the administration and maintenance of computing resources 9. Network Manageability - concerning the administration and maintenance of the network
re-sources
There may be different management services addressing different aspects. As other services, management services are subject to policies and contracts.
LifeWatch Policy: LifeWatch shall provide management services to support the elements of a basic man-agement service infrastructure as defined following OASIS-SOA-RA:
- Integration with existing security services - Monitoring
- Heartbeat and Ping - Alerting / Notification
- Pause/Restore/Restart Service Access - Logging, Auditing, Non-Repudiation - Runtime Version Management
- Complement other infrastructure services (discovery, messaging, mediation) - Message Routing and Redirection
- Failover - Load-balancing
- QoS, Management of Service Level Objects and Agreements - Availability
- Response Time - Throughput
- Fault and Exception Management