This section addresses Reqs. D1.2-3.2-ModelDrivenCfg, D1.2-3.12-SPManifest, D1.2-6.3-WhatHowWhyWho, and D1.2-6.4-Min.
The TAS3 architecture covers a lot of functionality and some of this functionality needs to be configured carefully to match each other to ensure smooth operation from the perspective of the users, such smooth operation is perceived by users as dependability and trustworthiness, so it is a prerequisite for good public image of a Trust Network.
Correct configuration will also be essential for ensuring that services function securely. Given that most security technology is quite brittle and even minute misconfigurations lead to failure, there will be operational and commercial pressure to turn off those nonfunctional, but essential features that appear to be "causing trouble". This is an extremely dangerous slippery slope that any Trust Network MUST avoid. Liberty Alliance and SAML Interoperability and Certification programmes have clearly demonstrated this to be a real peril. Therefore it is necessary that it is possible to correctly configure the trust network such that it will work right on the first try.
Complexity of a typical Trust Network, along with all of its member systems, is of such a high degree that it is infeasible to configure it sufficiently correctly by a manual approach. Humans make mistakes. An automated, model driven configuration is the only way to create accurate and correct configuration.
The corner stone is Business Process Modelling. From this model, which exists both at the top Trust Network level and at the organizational level, it should be possible to derive the following outputs:
Circle of Trust parameters to facilitate federation and SSO configuration
Declarative Statements about attribute needs of the Clients as well as policies under which providers are willing to release attributes. This output will come in the form of [CARML] and [AAPML] files, see further [IGF], that can be used to automatically configure IGF enabled layers of Client Request PEP and Provider Request PEP.
Some of the top level policies that apply to the Trust Network and its members. This should facilitate configuration of the PDPs.
Policies, Business Process Models, and Interface Descriptions (e.g. WSDL) that are needed as input for the Automated Compliance Validation.
Business Process Models that are needed as input for Business Process Visualization at the Dashboard.
Policy and business process model descriptions needed by the Configuration and IT infrastructure management, e.g. CMDB, ITIL, etc.
Contractual information behind a business process will influence the business process model itself and has an impact on the security rules, roles, and policies related to the business process.
Security rules that guide selection of web services and use of secure entities (data), i.e. influence the discovery service.
Security exceptions during business processes will raise an exception. Unhandled exceptions will block or break the process (go to an operator or help desk). The challenge is to handle the exceptions by explicit routines in the business process modelled routines or in some cases by using alternative paths (i.e. subprocesses) to allow the process to complete or even to look ahead and avoid exceptions before they occur by such means.
Business processes can have more complex topology than just trees.
There is no centralized log, just references to local logs are passed out.