530 likes | 543 Vues
This lecture explores the use of OWL (Web Ontology Language) in building secure semantic webs. It covers the limitations of RDF, security issues for ontologies, and the syntax and semantics of OWL. Examples of semantic access control and ontology engineering are also discussed.
E N D
Building Trustworthy Semantic Webs Lecture #14 : OWL (Web Ontology Language) and Security Dr. Bhavani Thuraisingham February 2010
Outline of the Unit • What are ontologies • Why is RDF not sufficient? • What are the security issues for ontologies • What is OWL? • OWL Syntax and Semantics • Security Issues with Examples • Example: Semantic Access Control • Ontology Engineering • Summary and Directions
Ontology • Common definitions for any entity, person or thing • Several ontologies have been defined and available for use • Defining common ontology for an entity is a challenge • Mappings have to be developed for multiple ontologies • Specific languages have been developed for ontologies
Why RDF is not sufficient? • RDF was developed as XML is not sufficient to specify semantics • E.g., class/subclass relationship • RDF has issues also • Cannot express several other properties such as Union, Interaction, relationships, etc • Need a richer language • Ontology languages were developed by the semantic web community for this purpose • Essentially RDF is not sufficient to specify ontologies
Security and Ontology • Ontologies used to specify security policies • Example: OWL to specify security policies • Choice between XML, RDF, OWL, Rules ML, etc. • Security for Ontologies • Access control on Ontologies • Give access to certain parts of the Ontology
OWL: Background • It’s a language for ontologies and relies on RDF • DARPA (Defense Advanced Research Projects Agency) developed early language DAML (DARPA Agent Markup Language) • Europeans developed OIL (Ontology Interface Language) • DAML+OIL combines both and was the starting point for OWL • OWL was developed by W3C
OWL Features • Subclass relationship • Class membership • Equivalence of classes • Classification • Consistency (e.g., x is an instance of A, A is a subclass of B, x is not an instance of B) • Three types of OWL: OWL-Full, OWL-DL, OWL-Lite • Automated tools for managing ontologies • Ontology engineering
OWL Specification (e.g., Classes) < owl: Class rdf: about = “#associateProfessor”> <owl: disjointWith rdf: resource “#professor”/> <owl: disjointWith rdf: resource = #assistantProfessor”/> </owl:Class> <owl: Class rdf: ID = “faculty”> <owl: equivalentClass rdf: resource = “academicStaffMember”/> </owl: Class> Faculty and Academic Staff Member are the same Associate Professor is not a professor Associate professor is not an Assistant professor
OWL Specification (e.g., Property) Courses are taught by Academic staff members < owl: ObjectProperty rdf: about = “#isTaughtby”> <rdfs domain rdf: resource = “#course”/> <rdfs: range rdf: resource = “#academicStaffMember”/> <rdfs: subPropertyOf rdf: resource = #involves”/> </owl: ObjectProperty>
OWL Specification (e.g., Property Restriction) All first year courses are taught only by professors < owl: Class rdf: about = “#”firstyearCourse”> <rdfs: subClassOf> <owl: Restriction> <owl: onProperty rdf: resource = “#isTaughtBy”> <owl: allValuesFrom rdf: resource = #Professor”/> </rdfs: subClassOf> </owl: Class>
Example • Before we discuss security for OWL and specify policies in OWL, we need to provide an example of an OWL ontology. • The following example describes the University Ontology. The different properties shown are DatatypeProperty (hasCredits) and ObjectProperty (hasTaught, isTaughtBy etc). Sub properties are also shown (‘hasCompleted’ is a sub property of ‘hasRegistered’). The ‘disjointWith’ property ensures that two classes do not have any individuals in common. For example, an individual from the ‘Faculty’ class cannot be an individual of the ‘Student’ class. Using sub properties, policies can be specified. In the following example, a faculty member can access the ‘AnnualReports’ only is she/he is the Dean. • Note that OWL uses RDF and hence XML syntax. Furthermore, OWL has more powerful reasoning capabilities. • The following example and subsequent security examples will make this clear.
Example • <?xml version="1.0"?> • <!DOCTYPE rdf:RDF [ • <!ENTITY owl "http://www.w3.org/2002/07/owl#" > • <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" > • <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" > • <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" > • ]> • <rdf:RDF xmlns="http://www.owl-ontologies.com/Ontology1178660130.owl#" • xml:base="http://www.owl-ontologies.com/Ontology1178660130.owl" • xmlns:xsd="http://www.w3.org/2001/XMLSchema#" • xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" • xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" • xmlns:owl="http://www.w3.org/2002/07/owl#">
Example • <owl:Ontology rdf:about=""/> • <owl:Class rdf:ID="AnnualReports"> • <rdfs:subClassOf rdf:resource="#Department"/> • </owl:Class> • <owl:ObjectProperty rdf:ID="canAccess"> • <rdfs:domain rdf:resource="#Faculty"/> • <rdfs:range rdf:resource="#AnnualReports"/> • <rdfs:subPropertyOf rdf:resource="#isDean"/> • </owl:ObjectProperty> • <owl:Class rdf:ID="Course"> • <rdfs:subClassOf rdf:resource="#Department"/> • </owl:Class> • <owl:Class rdf:ID="Department"/> • <owl:Class rdf:ID="Faculty">
Example • <rdfs:subClassOf rdf:resource="#Department"/> • <owl:disjointWith rdf:resource="#Student"/> • <owl:disjointWith rdf:resource="#Staff"/> • </owl:Class> • <owl:ObjectProperty rdf:ID="hasCompleted"> • <rdfs:subPropertyOf rdf:resource="#hasRegistered"/> • </owl:ObjectProperty> • <owl:DatatypeProperty rdf:ID="hasCredits"> • <rdfs:domain rdf:resource="#Course"/> • <rdfs:range rdf:resource="&xsd;int"/> • </owl:DatatypeProperty> • <owl:ObjectProperty rdf:ID="hasDean"> • <rdfs:domain> • <owl:Class>
Example • <owl:unionOf rdf:parseType="Collection"> • <owl:Class rdf:about="#Course"/> • <owl:Class rdf:about="#Department"/> • <owl:Class rdf:about="#Faculty"/> • <owl:Class rdf:about="#Staff"/> • <owl:Class rdf:about="#Student"/> • </owl:unionOf> • </owl:Class> • </rdfs:domain> • <rdfs:range rdf:resource="#Faculty"/> • </owl:ObjectProperty> • <owl:DatatypeProperty rdf:ID="hasName"> • <rdfs:domain> • <owl:Class>
Example • <rdfs:range rdf:resource="#Faculty"/> • </owl:ObjectProperty> • <owl:DatatypeProperty rdf:ID="hasName"> • <rdfs:domain> • <owl:Class> • <owl:unionOf rdf:parseType="Collection"> • <owl:Class rdf:about="#Department"/> • <owl:Class rdf:about="#Faculty"/> • <owl:Class rdf:about="#Staff"/> • <owl:Class rdf:about="#Student"/> • </owl:unionOf> • </owl:Class> • </rdfs:domain>
Example • <rdfs:range rdf:resource="&xsd;string"/> • </owl:DatatypeProperty> • <owl:ObjectProperty rdf:ID="hasPrerequisite"> • <rdf:type rdf:resource="&owl;TransitiveProperty"/> • <owl:inverseOf rdf:resource="#isPrerequisiteOf"/> • </owl:ObjectProperty> • <owl:ObjectProperty rdf:ID="hasRegistered"> • <rdfs:domain rdf:resource="#Student"/> • <rdfs:range rdf:resource="#Course"/> • </owl:ObjectProperty> • <owl:ObjectProperty rdf:ID="isDean"> • <rdfs:domain rdf:resource="#Faculty"/> • <rdfs:range rdf:resource="&xsd;boolean"/>
Example • </owl:ObjectProperty> • <owl:ObjectProperty rdf:ID="isPrerequisiteOf"> • <rdf:type rdf:resource="&owl;TransitiveProperty"/> • <owl:inverseOf rdf:resource="#hasPrerequisite"/> • </owl:ObjectProperty> • <owl:Class rdf:ID="Staff"> • <rdfs:subClassOf rdf:resource="#Department"/> • <owl:disjointWith rdf:resource="#Student"/> • <owl:disjointWith rdf:resource="#Faculty"/> • <rdfs:comment rdf:datatype="&xsd;string" • >This class represents the non-teaching, non-student members of the • department</rdfs:comment> • </owl:Class>
Example • <owl:Class rdf:ID="Student"> • <rdfs:subClassOf rdf:resource="#Department"/> • <owl:disjointWith rdf:resource="#Staff"/> • <owl:disjointWith rdf:resource="#Faculty"/> • </owl:Class> • <owl:ObjectProperty rdf:ID="taughtBy"> • <rdfs:domain rdf:resource="#Course"/> • <rdfs:range rdf:resource="#Faculty"/> • <owl:inverseOf rdf:resource="#teachesCourse"/> • </owl:ObjectProperty>
Example • <owl:ObjectProperty rdf:ID="teachesCourse"> • <rdf:type rdf:resource="&owl;InverseFunctionalProperty"/> • <rdfs:domain rdf:resource="#Faculty"/> • <rdfs:range rdf:resource="#Course"/> • <owl:inverseOf rdf:resource="#taughtBy"/> • </owl:ObjectProperty> • </rdf:RDF>
Policies in OWL • How can policies be specified? • Should policies be specified as shown in the examples, extensions to OWL syntax? • Should policies be specified as OWL documents? • Is there an analogy to XPath expressions for OWL policies? • <policy-spec cred-expr = “//Professor[department = ‘CS’]” target = “annual_ report.xml” path = “//Patent[@Dept = ‘CS’]//Node()” priv = “VIEW”/>
Policies in OWL: Example < owl: Class rdf: about = “#associateProfessor”> <owl: disjointWith rdf: resource “#professor”/> <owl: disjointWith rdf: resource = #assistantProfessor”/> Level = L1 </owl:Class> <owl: Class rdf: ID = “faculty”> <owl: equivalentClass rdf: resource = “academicStaffMember”/> Level = L2 </owl: Class>
Example • “Only those attending a class from a professor has read access to the lecture notes of the professor” • Below we specify this policy in OWL. • <owl:Class rdf:ID="BhavaniLectureNotesCS609"> • <rdfs:subClassOf rdf:resource="http://localhost/unionto#LectureNotes"/> • </owl:Class> • <owl:Class rdf:ID="CS609Students"> • <rdfs:subClassOf rdf:resource="http://localhost/unionto#Students"/> • </owl:Class> • <owl:ObjectProperty rdf:ID="canAccess"> • <rdfs:domain rdf:resource="#CS609Students"/> • <rdfs:range rdf:resource=" http://localhost/unionto# BhavaniLectureNotesCS609"/> • </owl:ObjectProperty>
Example Policies • Temporal Access Control • After 1/1/05, only doctors have access to medical records • Role-based Access Control • Manager has access to salary information • Project leader has access to project budgets, but he does not have access to salary information • What happens is the manager is also the project leader? • Positive and Negative Authorizations • John has write access to EMP • John does not have read access to DEPT • John does not have write access to Salary attribute in EMP • How are conflicts resolved?
Privacy Policies • Privacy constraints processing • Simple Constraint: an attribute of a document is private • Content-based constraint: If document contains information about X, then it is private • Association-based Constraint: Two or more documents taken together is private; individually each document is public • Release constraint: After X is released Y becomes private • Augment a database system with a privacy controller for constraint processing
Access Control Strategy • Subjects request access to OWL documents under two modes: Browsing and authoring • With browsing access subject can read/navigate documents • Authoring access is needed to modify, delete, append documents • Access control module checks the policy based and applies policy specs • Views of the document are created based on credentials and policy specs • In case of conflict, least access privilege rule is enforced • Works for Push/Pull modes • Query Modification?
System Architecture for Access Control User Pull/Query Push/result RDF- Access RDF-Admin Admin Tools Credential base Policy base OWL Documents
OWL Databases • Data is presented as OWL documents • Query language? OWL=QL? • Query optimization (depends on query language) • Managing transactions on OWL documents • Metadata management: OWL schemas? • Access methods and index strategies • OWL security and integrity management
Inference/Privacy Control Interface to the Semantic Web Technology By UTD Inference Engine/ Rules Processor (Reasoning in OWL?) Policies Ontologies Rules OWL Documents Web Pages, Databases OWL Data Management
Semantic Access Control Ashraful Alam Dr. Bhavani Thuraisingham
Semantic Access Control (SAC) Traditional Access Control Semantic Web Semantic Access Control
Motivation • Shortcomings of Traditional Access Control • Proprietary systems • Lack of modularity • Changes in access control schemas break the system • Changes in data schemas break the system • Path to resources (e.g., XPATH) is clumsy //school/department/professor/personal/ssn – LONG! • Non-optimal for distributed/federation environment
Modularity Problem People this policy applies to Resources this policy applies to Target Box Actions allowed for this policy
SAC Ontology • Written in OWL (Web Ontology Language) • User-centric • Modular • Easily extensible • Available at : http://utd61105.campus.ad.utdallas.edu/geo/voc/newaccessonto
SAC Components • Subjects: Software Agents or Human clients • Resources: Assets exposed through WS • Actions: Read, Write, Execute • Conditions: Additional constraints (e.g., geospatial parameters) on policy enforcement Policy Set Subjects Condition Resources Actions
Application: Geo-WS Security • Data providers (e.g., geospatial clearinghouses, research centers) need access control on serviceable resources. • Access policies have geospatial dimension • Bob has access on Building A • Bob does NOT have access on Building B • Building A and B have overlapping area • Current access control mechanisms are static and non-modular.
Geo-WS Security: Architecture D A G I S Geospatial Semantic WS Provider Client Enforcement Module Decision Module Authorization Module Semantic-enabled Policy DB Web Service Client Side Web Service Provider Side
Geo-WS Security: Semantics • Policy rules are based on description logic (DL). • DL allows machine-processed deductions on policy base. • Example 1: • DL Rule: ‘Stores’ Inverse ‘Is Stored In’ • Fact: Airplane_Hanger(X) ‘stores’ Airplane(Y) • Example 2: • DL Rule: ‘Is Located In’ is Transitive. • Fact: Polygon(S) ‘Is Located In’ Polygon(V) Polygon(V) ‘Is Located In’ Polygon(T)
Secure Inferencing Semantic-enabled Policy DB Obvious facts Deduced facts Inferencing Module Geospatial Data Store
Geo-WS Security: Example • Resource := Washington, Oregon, California, West Coast • Rule:= West Coast = WA Union OR Union CA • Policy:= • Subject:= Bob • Resources:= WA, OR, CA • Action:=Read • Query: Retrieve Interstate Highway topology of West Coast
SAC in Action • Environment: University Campus • Campus Ontology http://utd61105.campus.ad.utdallas.edu/geo/voc/campusonto • Main Resources • Computer Science Building • Pharmacy Building • Electric Generator in each Building
SAC in Action • User Access: • Bob has ‘execute’ access to all Building Resources • Bob doesn’t have any access to CS Building • Bob has ‘modify’ access to Building resources within a certain geographic extent • Policy File located at http://utd61105.campus.ad.utdallas.edu/geo/voc/policyfile1
SAC Improvements • Subjects, Resources, Actions and Conditions are defined independently • Reduced policy look-up cost -- only policies related to the requester is processed • No long path name!
Distributed Access Control Client Query Interface Middleware Travel Site Reimbursement Site Bank Site Travel Data & Ontology Reimbursement Data Bank Site & Ontology
Semantic web technologies discussed so far • XML, XML Schema • RDF, RDF Schema • Ontology, OWL • Logic, Rules, Inference • Some discussion of security issues for each technology • Policy specification, Securing documents
Types of Application • Horizontal Information Products at Elsevier: Integration • Data integration at Audi: Integration • Skill finding at Swiss Life: Search • Think Tank Portal at EnterSearch: Knowledge man agent • E-Learning: Knowledge management • Web Services: Web services (for any of the other applications discussed) • Multimedia Collection at Scotland Yard: Searching • Online Procurement at Daimler Chrysler: E-Business • Device Interoperability at Nokia: Interoperability
Revisiting Ontology • Common definitions for any entity, person or thing • Several ontologies have been defined and available for use • Defining common ontology for an entity is a challenge • Mappings have to be developed for multiple ontologies • Specific languages have been developed for ontologies • RDF, OWL, DAML+OIL, etc.
What is Ontology Engineering? • Tools and Techniques to • Create Ontologies • Specify Ontologies • Maintain Ontologies • Query Ontologies • Evolve Ontologies • Reuse Ontologies • Incorporate features such as security, data quality, integrity
Manual Construction of Ontologies • Determine Scope • Consider Reuse • Enumerate Terms • Define Taxonomy • Define Properties • Define facets • Define Instances • Check for Anomalies
Reusing Existing Ontologies • The goal is not to reinvent the wheel • Several ontologies have been developed for different domains • Codieid Bodies of Expert Knowledge • Integrated Vocabularies • Upper Level Ontologies • Topic Hierarchies • Linguistic Resources • Ontology Libraries