Exploitation & Impact
8.2 ASSERT Management Tool
Figure 8.4: Comparing the certified security properties of results step), the score is also visualized by a gauge, indicating in a intuitive way whether the corresponding candidate is a perfect match, a weak match, or a partial match (see the figure, from left to right). Intuitively, a weak match is a candidate that is certified for all the security properties required by the active policies, but that achieves at least one of them using a mechanism other (weaker) than the one specified in the policy. A partial match is a candidate that achieves (perfectly or weakly) at least one of the properties required by the active policies while missing at least one of the other re-quired properties. Services can also have additionalASSERTS, which are not required to meet the security requirements; those ASSERTSare mentioned separately (not shown in Figure 8.4), below the comparison score.
Thus, the AESM prototype showcases the benefits of consumption of Digital Security Certificates in service scenarios such as discovery, selection and comparison. A similar approach for certified service discovery, selec-tion and comparison is presented in [147], but it is more oriented towards the developers of service based applications.
8.2 ASSERT Management Tool
In this section, we present a research prototype that is based on the ASSERT language presented in Section 6.4, to generate the Digital Security Certificates (DSCs) and to check the conformance of a certificate against a Digital Security Certificate Profile. We have contributed to the development 139
of this prototype within the context of the EU funded project ASSERT4SOA.
While the AESM prototype showcases the ease of consumption of Digital Security Certificates, the ASSERT Management Tool (AMT) illustrates the ease of generation of Digital Security Certificates.
We need tool support for the core profile-based certificate management operations:
• standalone generationof DSCs
• profile-based generationof DSCs
• profile conformance verificationof DSCs.
These are the most relevant DSC management operations a DSC issuer would need to perform when issuing DSCs.
8.2.1 Standalone generation of Digital Security Certificates
Standalone generation of Digital Security Certificates is the most sim-plest way to generate a certificate, where the Certification Authority cap-tures the information from the certification process and represents in the DSC instance conforming to theASSERTlanguage schema. However, certifi-cates produced without conforming to any DSC profiles increase the com-plexity in comparing different certified services.
The process of generation of a standalone-ASSERT is straightforward through our prototype, wherein the various fields can be filled using dif-ferent ontologies that are integrated within the tool.
8.2.2 Profile-based Generation of Digital Security Certifi-cate
Figure 8.5 shows the process for profile- based generation of DSCs.
When a DSC profile is selected and loaded, there is a pre-processing step for all dynamic vocabulary specifications. If some dynamic vocabulary speci-fications depend on other artefacts and values in order to be processed, these vocabularies are processed at the time when the issuer creates the corresponding artefacts.
• Step 1: Initialize DSC content. Once the profile is processed, first du-plicate the certificate template and create an bare-bones certificate instance with an initial structure and content of the duplicated tem-plate data.
8.2. ASSERT MANAGEMENT TOOL
Figure 8.5: Profile-based Generation of Digital Security Certificate
• Step 2: Edit DSC content. Next step is the actual process of editing the certificate artefacts and creation of new artefacts as needed by the issuer. This step heavily relies on the use of certificate vocabulary defined in the profile. When an artefact’s vocabulary is specified as mandatory, the tool will enforce the choice of the vocabulary terms.
Otherwise, if optional, the tool will recommend/ suggest a choice of terms but leaving the issuer to specify own terms when as found necessary.
• Step 3: Profile Conformance Verification. The final certificate instance is verified for conformance to the profile (presented in the next sub-section). Any violations of the DSC instance against the DSC profile including the used artefacts and corresponding vocabularies are re-ported to the Certificate Issuer. Moreover, it reverts back to the DSC edit mode (Step 2) until no further violations are found.
8.2.3 Profile Conformance Verification of DSC
A prerequisite to conformance verification is to ensure whether the cer-tificate instance conforms to the syntax of a given cercer-tificate model, that is, verification of the syntactic correctness of the certificate instance. Other-wise, the verifier should not proceed with the verification process.
Figure 8.6 shows the three main steps of conformance verification pro-cess.
• Step 1: Structure validation. DSC structure is validated if it contains all required elements and values as declared in the profile template.
• Step 2: Vocabulary Validation. DSC vocabulary is validated for com-pliance with the vocabulary defined in the profile. Prerequisite to this step is to first process all dynamic vocabularies. That is, retriev-ing all certificate artefacts’ vocabulary terms from the correspondretriev-ing 141
DSC Profile
DSC Instance 1) Structure
validation 2) Vocabulary
conformance verification 3) Rules
conformance verification
Template Semantic Rules Vocabulary
Figure 8.6: Profile Conformance Verification of DSC
ontologies by executing the queries. Once dynamic vocabularies are instantiated, all certificate artefacts’ vocabulary terms within the vo-cabulary part are checked against the corresponding artefacts’ content in the certificate instance. All certificate artefacts defined to have an optional (non-mandatory) vocabulary will not be verified for confor-mance.
• Step 3: Semantic Validation. DSC structure and vocabulary is vali-dated for compliance with the profile rules, that is, if all constraints are satisfied. All semantic rules are processed, checked if satisfied by the certificate structure and content. Since the semantic rules of the profile may depend on the actual content ( vocabulary) of a cer-tificate artefacts in order to determine the semantic integrity of the certificate content, it is important to verify vocabulary conformance first, and then the semantic rules conformance.
8.2.4 DSC Management Tool Realization
A DSC management tool has been developed to support the manage-ment ofASSERTSfrom the perspective ofASSERT issuers. The tool is called ASSERTManagement Tool (AMT) [15]. The AMT is designed to provide an intuitive GUI for standardASSERT management operations including com-plete support ofmulti-profile based ASSERT management. We will present the GUI of the AMT for the case of profile-based creation ofASSERTS.
Figure 8.7 shows the AMT designer view. The designer view provides content-centric ASSERT management: abstracting issuers from underlying XML representation. All mandatoryASSERTlanguage elements are coloured in red for convenience of issuers. A help icon is shown to each element name describing the rationale of the selected element. The AMT has the ASSERTlanguage schema built-in. A designer pane shows all language ele-ments as buttons. Upon pressing a button, the corresponding data element
8.2. ASSERT MANAGEMENT TOOL
Figure 8.7: AMT Designer View
is created.
As we can see in Figure 8.7, theASSERTprofile has been already loaded and the corresponding profile vocabulary processed showing the vocabu-lary terms defined for thePropertyContext element of theSecurityProperty
Figure 8.8 shows the ASSERT XML view. The upper part of the XML Output shows a non-editable XML view of the current ASSERT structure.
The bottom part shows the result of ASSERT validation against the ASSERT language, and the results of profile conformance verification against the selected ASSERT profile. The messages of profile conformance verification are grouped into the corresponding verification steps as described earlier (ref. Figure 8.6). Grouping messages greatly facilitates issuers especially when dealing with creation ofASSERTSbased on multiple profiles.
Figure 8.9 shows the AMT profile view. The upper part of the profile view shows the content of the selected profile, while the bottom part of the view shows messages of the profile validation process. The profile val-idation process ensures the issue that the selected profile has well-formed vocabulary section and semantic rules sections, in our case syntactically correct Schematron rules.
We note that in case of multiple profiles, the AMT loads each profile in a separate profile view (tab) so that the issuer can at any moment check if any of the profiles is well-formed and what messages are shown.
Thus, we show the ease with Digital Security Certificates can be gen-erated and can be validated for consistency and conformance against DSC Profiles using tool support, that exploits the machine processability of the 143
Figure 8.8: AMT XML Output View
ASSERTartefacts.