LSDIS > Projects > METEOR-S > Authorization

METEOR-S: Semantic Web Services and Processes

Applying Semantics in Annotation, Quality of Service, Discovery, Composition, Execution

Motivation for a Semantic Approach    Implementation     Example     Use Case     Additional Resources    

Authorization in Semantic Web Services, WS-Authorization

This work is a component of the Meteor-S project which deals with all aspects of a Semantic Web Service and Process lifecycle.



There has been little work in the area of WS-Authorization and even less regarding the semantics of authorizaiton. To take the development of semantic Web applications a step further, we have proposed a framework for the annotation of Web service policy files to incorporate authorization information in an effort to aid in the semantic discovery of authorized services. So far researchers have concentrated their attention on annotating Web services’ inputs, outputs, pre-conditions and post-conditions with semantics. While the effort improves the efficiency and precision of Web service discovery, it may not be sufficiently useful if clients or service requesters are not authorized to invoke the retrieved services. As an important addition to previous work, we extend accepted policy standards by adding semantic annotations. The use of standards is indispensable to guarantee a future adoption of new technologies by the industry.



The WS-Policy specification is a model and syntax for describing the policies of a Web services. It relies on its follow-on specifications, such as WS-Trust, WS-Agreement, WS-Security, and WS-Utility, which make within WS-Policy. The assertions are based on an XML based domain vocabulary. A client and service provider can make assertions in WS-Policy from any domain using the specifications which describe the vocabulary. When matching policies, if the policy matching mechanism is unaware of the domain context then it would be limited to using syntactical matching. Consider the following example where a client and a service provider have included authorization assertions from the Health Care domain.


Service Provider:

  • Must be a Physician working in Emergency Service of the Health Services Industry


  • Is an Emergency Room Physician working at a Hospital in the Emergency Room


These assertions are equivalent. The domain knowledge needed to determine that these assertions are equivalent are absent in a purely syntactic matching mechanism. Therefore, using a string matching algorithm would result in the denial of authorization for the client, which is a false negative result. These assertions can easily be determined to be equivalent by using domain information along with semantic reasoning. From our example, it can be determined that

A matching mechanism which uses domain knowledge captured in an ontology can improve the results over traditional purely syntactic matching mechanisms.


WS-Authorization and Extention Elements

Coming Soon


Coming Soon

Coming Soon



In the scenario that follows, the text that appears in caption (i.e., <<Pyy-nnn abstract permission name>>) indicates a reference to the abstract permission name and its unique identifier as described in the tables of the HL7 RBAC Healthcare Permission Catalog. In order to make this scenario more applicable to Web services we will assume that patient medical records are updated and accessed through a Electronic Health Record (EHR) Archive which has been implemented using Web services. To further extend this example to the “real world” we assume that there are several EHR Archives, each containing similar data. This is equivalent to consumer credit reporting. The discovery of the EHR which the physician will use is dependant on the permissions the physician has with each EHR as it pertains to this particular patient. This is practical since not every physician is the primary physician. Physicians who are specialist further demonstrate that granular permissions to a patient’s medical record are a reasonable assumption. Therefore, when discovering the appropriate Web service to invoke, the physicians’ authorization to access the medical record will be analyzed.

“Mr. Patient was placed in a clinic examination room for a Diabetic Consultation. The Physician greeted Mr. Patient and accessed Mr. Patient’s medical records <<PRD-006 Patient Identification and Lookup>> from an EHR. After briefly reviewing Mr. Patient’s recent pertinent medical history <<PRD-003 Review Medical History>>, problem lists <<PRD-016 Review Problem Lists>>, health status data <<PRD-014 Health Status Data>>, existing order(s) <<PRD-004 Review Existing Order(s)>>, medications <<PRD-010 Review Patient Medications>>, allergies <<PRD-011 Review Patient Allergies or Adverse Reactions>>, test results/reports (evaluating high and low values) <<PRD-001 Review Patient Testing Reports>>, immunizations <<PRD-013 Review Immunizations>>, and visits <<PRD-012 Review Past Visits>> within the EHR, the Physician next reviewed Mr. Patient’s vital signs, patient measurements <<PRD-005 Review Vital Signs/Patient Measurements>>(e.g., height and weight), and the chief complaint(s) <<PRD-002 Review Chief Complaint>>that were entered for this encounter.” [HL7 Security Technical Committee, 2005]


We will use three aspects of this scenario to compose a Web services process for our evaluation and testing. The three aspects we will focus on are ‘Patient Identification and Lookup’, ‘Review Medical History’, and ‘Review Problem Lists’. All the accesses in the scenario that the physician makes to the patients record can be implemented. However, implementing the entire scenario would not add to the validity of our system. In our implementation it is assumed that ‘Patient Identification and Lookup’ must be preformed at least once prior to either of the other operations.


As a running example we now describe a detailed ‘instance of’ use case. We have created three companies to act as Electronic Health Record repositories. Each repository has a Web service implemented for each of the operations from the scenario. The Client is an ‘Emergency Room Physician and works for a St. Francis Hospital . The services of Company1 had been annotated such that authorization is to be granted to a client that has the role ‘Physician’ working in ‘Health Services’, subjectCategory. The services of Company2 had been annotated such that authorization is to be granted to a client that has the role ‘Nurse’ working in ‘Health Services’. The services of Company3 had authorization information which was a combination of the previous companies in which one service grants and two deny authorization. As we will show in section 5, St. Francis is a ‘Hospital’ is an instance of an ‘Organization’ involved in ‘Health Services’. The details of the process will be further discussed in Section 6.4, Evaluation of Techniques.

Additional Resources