Download
building trustworthy semantic webs lecture n.
Skip this Video
Loading SlideShow in 5 Seconds..
Dr. Bhavani Thuraisingham PowerPoint Presentation
Download Presentation
Dr. Bhavani Thuraisingham

Dr. Bhavani Thuraisingham

1 Views Download Presentation
Download Presentation

Dr. Bhavani Thuraisingham

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Building Trustworthy Semantic Webs Lecture #14 : OWL (Web Ontology Language) and Security Dr. Bhavani Thuraisingham February 2010

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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>

  10. 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>

  11. 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.

  12. 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#">

  13. 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">

  14. 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>

  15. 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>

  16. 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>

  17. 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"/>

  18. 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>

  19. 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>

  20. 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>

  21. 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”/>

  22. 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>

  23. 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>

  24. 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?

  25. 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

  26. 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?

  27. System Architecture for Access Control User Pull/Query Push/result RDF- Access RDF-Admin Admin Tools Credential base Policy base OWL Documents

  28. 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

  29. 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

  30. Semantic Access Control Ashraful Alam Dr. Bhavani Thuraisingham

  31. Semantic Access Control (SAC) Traditional Access Control Semantic Web Semantic Access Control

  32. 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

  33. Modularity Problem People this policy applies to Resources this policy applies to Target Box Actions allowed for this policy

  34. SAC Ontology • Written in OWL (Web Ontology Language) • User-centric • Modular • Easily extensible • Available at : http://utd61105.campus.ad.utdallas.edu/geo/voc/newaccessonto

  35. 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

  36. 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.

  37. 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

  38. 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)

  39. Secure Inferencing Semantic-enabled Policy DB Obvious facts Deduced facts Inferencing Module Geospatial Data Store

  40. 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

  41. 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

  42. 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

  43. 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!

  44. Distributed Access Control Client Query Interface Middleware Travel Site Reimbursement Site Bank Site Travel Data & Ontology Reimbursement Data Bank Site & Ontology

  45. 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

  46. 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

  47. 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.

  48. 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

  49. Manual Construction of Ontologies • Determine Scope • Consider Reuse • Enumerate Terms • Define Taxonomy • Define Properties • Define facets • Define Instances • Check for Anomalies

  50. 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