1. Dr. Bhavani Thuraisingham The University of Texas at Dallas Trustworthy Semantic Webs October 2013 Data and Applications Security

2. Outline l Semantic web l XML and XML security l RDF and RDF security l Ontologies l Rules l Applications l Reference: - Building trustworthy semantic web, Thuraisingham, CRC Press, 2007

3. Layered Approach: Tim Berners Lee’s Vision www.w3c.org

4. What is XML all about? l XML is needed due to the limitations of HTML and complexities of SGML l It is an extensible markup language specified by the W3C (World Wide Web Consortium) l Designed to make the interchange of structured documents over the Internet easier l Key to XML used to be Document Type Definitions (DTDs) - Defines the role of each element of text in a formal model l XML schemas have now become critical to specify the structure - XML schemas are also XML documents

5. XML Elements XML Statement John Smith is a Professor in Texas This can be expressed as follows: John Smith Texas

6. XML Elements Now suppose this data can be read by anyone then we can augment the XML statement by an additional element called access as follows. John Smith Texas All, Read

7. XML Elements If only HR can update this XML statement, then we have the following: John Smith Texas HR department, Write

8. XML Elements We may not wish for everyone to know that John Smith is a professor, but we can give out the information that this professor is in Texas. This can be expressed as: John Smith, Govt-official, Read Texas, All, Read HR department, Write

9. XML Attributes Suppose we want to specify to access based on attribute values. One way to specify such access is given below. <Professor Name = “John Smith”, Access = All, Read Salary = “60K”, Access = Administrator, Read, Write Department = “Security” Access = All, Read </Professor Here we assume that everyone can read the name John Smith and Department Security. But only the administrator can read and write the salary attribute.

10. XML DTD DTDs essentially specify the structure of XML documents. Consider the following DTD for Professor with elements Name and State. This will be specified as:

11. XML Schema While DTDs were the early attempts to specify structure for XML documents, XML schemas are far more elegant to specify structures. Unlike DTDs XML schemas essentially use the XML syntax for specification. Consider the following example:

12. XML Namespaces Namespaces are used for DISAMBIGUATION <CountryX: Academic-Institution Xmlns: CountryX = http://www.CountryX.edu/Instution DTD” Xmlns: USA = “http://www.USA.edu/Instution DTD” Xmlns: UK = “http://www.UK.edu/Instution DTD” <USA: Title = College USA: Name = “University of Texas at Dallas” USA: State = Texas” <UK: Title = University UK: Name = “Cambridge University” UK: State = Cambs

13. XML Namespaces <Country: Academic-Institution Xmlns: CountryX = http://www.CountryX.edu/Instution DTD” Xmlns: USA = “http://www.USA.edu/Instution DTD” Xmlns: UK = “http://www.UK.edu/Instution DTD” <USA: Title = College USA: Name = “University of Texas at Dallas” USA: State = Texas” <UK: Title = University UK: Name = “Cambridge University” UK: State = Cambs

14. Federations/Distribution Site 1 document: 111 John Smith Texas Site 2 document: 111 60K

15. Credentials in XML Alice Brown University of X CS Security John James University of X CS Senior Note: This is SAML-Like, but it is not SAML. SAML is now a stan dard way to represent credentials

16. Policies in XML (we are using Xpath to represent policies, Xpath is outside of XML) <policy-spec cred-expr = “//Professor[department = ‘CS’]” target = “annual_ report.xml” path = “//Patent[@Dept = ‘CS’]//Node()” priv = “VIEW”/> <policy-spec cred-expr = “//Professor[department = ‘CS’]” target = “annual_ report.xml” path = “//Patent[@Dept = ‘EE’] /Short-descr/Node() and //Patent [@Dept = ‘EE’]/authors” priv = “VIEW”/> <policy-spec cred-expr = - - - - Explantaion: CS professors are entitled to access all the patents of their department. They are entitled to see only the short descriptions and authors of patents of the EE department Note: XACML is now a standrad way to represent access control policies

17. Access Control Strategy l Subjects request access to XML documents under two modes: Browsing and authoring - With browsing access subject can read/navigate documents - Authoring access is needed to modify, delete, append documents l Access control module checks the policy based and applies policy specs l Views of the document are created based on credentials and policy specs l In case of conflict, least access privilege rule is enforced l Works for Push/Pull modes

18. System Architecture for Access Control User Pull/Query Push/result XML Documents X-AccessX-Admin Admin Tools Policy base Credential base

19. Third-Party Architecture Credential base policy base XML Source User/Subject Owner Publisher Query Reply document SE-XML credentials l The Owner is the producer of information It specifies access control policies l The Publisher is responsible for managing (a portion of) the Owner information and answering subject queries l Goal: Untrusted Publisher with respect to Authenticity and Completeness checking

20. XML Databases l Data is presented as XML documents l Query language: XML-QL, Xquery l Query optimization l Managing transactions on XML documents l Metadata management: XML schemas/DTDs l Access methods and index strategies l XML security and integrity management

21. Inference/Privacy Control Policies Ontologies Rules XML Database XML Documents Web Pages, Databases Inference Engine/ Rules Processor Interface to the Semantic Web Technology By UTD

22. Why RDF? l XML cannot be used to specify semantics l Example: - Professor is a subclass of Academic Staff - Professor inherits all properties of Academic Staff l RDF was specified so that the inadequacies of XML could be handled l RDF uses XML Syntax l Additional constructs are needed for RDF

23. RDF l Resource Description Framework is the essence of the semantic web l Adds semantics with the use of ontologies, XML syntax l RDF Concepts - Basic Model l Resources, Properties and Statements - Container Model l Bag, Sequence and Alternative

24. RDF Basics l Resource: Everything is a resource - Person, Vehicle, etc. l Property: properties describe relationships between resources - E.g., Invented l Statement: (Object, Property, Value) Triple - Berners Lee invented the Semantic Web

25. RDF Container Model l Bag: Unordered container, may contain multiple occurrences - Rdf: Bag l Seq: Ordered container, may contain multiple occurrences - Rdf: Seq l Alt: a set of alternatives - Rdf: Alt

26. RDF Specification <rdf: RDF xmlns: rdf = “http://w3c.org/1999/02-22-rdf-syntax-ns#” xmlns: xsd = “http:// - - - xmlns: uni = “http:// - - - - <rdf: Description: rdf: about = “949352” Professor <rdf: Description rdf: about: “ZZZ” semantic web

27. RDF Specification l RDF specifications have been given for Attributes, Types Nesting, Containers, etc. l How can security policies be included in the specification l Example: consider the statement “Berners Les is the Author of the book Semantic Web” l Do we allow access to the connection between author and book? Do we allow access to the connection but not to the author name and book name?

28. RDF Policy Specification < rdf: RDF xmlns: rdf = “http://w3c.org/1999/02-22-rdf-syntax-ns#” xmlns: xsd = “http:// - - - xmlns: uni = “http:// - - - - <rdf: Description: rdf: about = “949352” Professor Level = L1 <rdf: Description rdf: about: “ZZZ” semantic web Level = L2

29. RDF Schema l Need RDF Schema to specify statements such as professor is a subclass of academic staff <rdfs: Class rdf: ID = “professor” The class of Professors All professors are Academic Staff Members.

30. RDF Schema: Security Policies l How can security policies be specified? <rdfs: Class rdf: ID = “professor” The class of Professors All professors are Academic Staff Members. Level = L

31. RDF Axiomatic Semantics l First order logic to specify formulas and inferencing - Built in functions (First) and predicates (Type) - Modus Ponens - From A and If A then B, deduce B l Example: All containers are Resources - Type(?C, Container)  Type(?c, Resource) - If we have Type(A, Container) then we can infer (Type A, Resource)

32. RDF Inferencing l While first order logic provides a proof system, it will be computationally infeasible l As a result horn clause logic was developed for logic programming; this is still computationally expensive l RDF uses If then Rules l IF E contains the triples (?u, rdfs: subClassof, ?v) and (?v, rdfs: subClassof ?w) THEN E also contains the triple (?u, rdfs: subClassOf, ?w) That is, if u is a subclass of v, and v is a subclass of w, then u is a subclass of w

33. RDF Query l One can query RDF using XML, but this will be very difficult as RDF is much richer than XML l Is there an analogy between say XQuery and a query language for RDF? l RQL – an SQL-like language has been developed for RDF l Select from “RDF document” where some “condition” l SPARQL is now a standard query language for RDF l SPARQL is a combination of SWRL (Semantic Web Rules Language) and OWL

34. Policies in RDF l How can policies be specified? l Should policies be specified as shown in the examples, extensions to RDF syntax? l Should policies be specified as RDF documents? l Is there an analogy to XPath expressions for RDF policies? -

35. Inference/Privacy Control Policies Ontologies Rules RDF Data Manager Jena RDF Documents Web Pages, Databases Inference Engine/ RDF Reasoner Pellet SPARQL: Interface to the Semantic Web Technology By UTD

36. Ontology l Common definitions for any entity, person or thing l Several ontologies have been defined and available for use l Defining common ontology for an entity is a challenge l Mappings have to be developed for multiple ontologies l Specific languages have been developed for ontologies

37. Why RDF is not sufficient? l RDF was developed as XML is not sufficient to specify semantics - E.g., class/subclass relationship l RDF has issues also - Cannot express several other properties such as Union, Interaction, relationships, etc l Need a richer language l Ontology languages were developed by the semantic web community for this purpose l Essentially RDF is not sufficient to specify ontologies

38. Security and Ontology l Ontologies used to specify security policies - Example: OWL to specify security policies - Choice between XML, RDF, OWL, Rules ML, etc. l Security for Ontologies - Access control on Ontologies l Give access to certain parts of the Ontology

39. OWL: Background l It’s a language for ontologies and relies on RDF l DARPA (Defense Advanced Research Projects Agency) developed early language DAML (DARPA Agent Markup Language) l Europeans developed OIL (Ontology Interface Language) l DAML+OIL combines both and was the starting point for OWL l OWL was developed by W3C

40. OWL Features l Subclass relationship l Class membership l Equivalence of classes l Classification l Consistency (e.g., x is an instance of A, A is a subclass of B, x is not an instance of B) l Three types of OWL: OWL-Full, OWL-DL, OWL-Lite l Automated tools for managing ontologies - Ontology engineering

41. OWL Specification (e.g., Classes) Faculty and Academic Staff Member are the same Associate Professor is not a professor Associate professor is not an Assistant professor

42. OWL Specification (e.g., Property) Courses are taught by Academic staff members

43. OWL Specification (e.g., Property Restriction) All first year courses are taught only by professors

44. Policies in OWL l How can policies be specified? l Should policies be specified as shown in the examples, extensions to OWL syntax? l Should policies be specified as OWL documents? l Is there an analogy to XPath expressions for OWL policies? -

45. Policies in OWL: Example Level = L1 Level = L2

46. Logic and Inference l First order predicate logic l High level language to express knowledge l Well understood semantics l Logical consequence - inference l Proof systems exist l Sound and complete l OWL is based on a subset of logic – descriptive logic

47. Why Rules? l RDF is built on XML and OWL is built on RDF l We can express subclass relationships in RDF; additional relationships can be expressed in OWL l However reasoning power is still limited in OWL l Therefore the need for rules and subsequently a markup language for rules so that machines can understand

48. Example Rules l Studies(X,Y), Lives(X,Z), Loc(Y,U), Loc(Z,U)  HomeStudent(X) l i.e. if John Studies at UTDallas and John is lives on Campbell Road and the location of Campbell Road and UTDallas are Richardson then John is a Home student l Note that Person (X)  Man(X) or Woman(X) is not a rule in predicate logic That is if X is a person then X is either a man of a woman. This can be expressed in OWL However we can have a rule of the form Person(X) and Not Man(X)  Woman(X)

49. Monotonic Rules l  Mother(X,Y) l Mother(X,Y)  Parent(X,Y) If Mary is the mother of John, then Mary is the parent of John Syntax: Facts and Rules Rule is of the form: B1, B2, ---- Bn  A That is, if B1, B2, ---Bn hold then A holds

50. Logic Programming l Deductive logic programming is in general based on deduction - i.e., Deduce data from existing data and rules - e.g., Father of a father is a grandfather, John is the father of Peter and Peter is the father of James and therefore John is the grandfather of James l Inductive logic programming deduces rules from the data - e.g., John is the father of Peter, Peter is the father of James, John is the grandfather of James, James is the father of Robert, Peter is the grandfather of Robert - From the above data, deduce that the father of a father is a grandfather l Popular in Europe and Japan

51. Nonmonotonic Rules l If we have X and NOT X, we do not treat them as inconsistent as in the case of monotonic reasoning. l For example, consider the example of an apartment that is acceptable to John. That is, in general John is prepared to rent an apartment unless the apartment ahs less than two bedrooms, is does not allow pets etc. This can be expressed as follows: l  Acceptable(X) l Bedroom(X,Y), Y<2  NOT Acceptable(X) l NOT Pets(X)  NOT Acceptable(X) l Note that there could be a contradiction. But with nonmotonic reasoning this is allowed.

52. Rule Markup l The various components of logic are expressed in the Rule Markup Language – RuleML l Both monotonic and nonmonotnic rules can be represented l Example representation of Fact P(a) - a is a parent p a

53. Policies in RuleML p a Level = L

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

55. Motivation l 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

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

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

58. SAC Components l Subjects: Software Agents or Human clients l Resources: Assets exposed through WS l Actions: Read, Write, Execute l Conditions: Additional constraints (e.g., geospatial parameters) on policy enforcement Resources Subjects Actions Condition Policy Set

59. Application: Geo-WS Security l Data providers (e.g., geospatial clearinghouses, research centers) need access control on serviceable resources. l 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 l Current access control mechanisms are static and non-modular.

60. Geo-WS Security: Architecture Client DAGISDAGIS DAGISDAGIS Geospatial Semantic WS Provider Enforcement Module Decision Module Authorization Module Semantic-enabled Policy DB Web Service Client SideWeb Service Provider Side

61. Geo-WS Security: Semantics l Policy rules are based on description logic (DL). l DL allows machine-processed deductions on policy base. l Example 1: - DL Rule: ‘Stores’ Inverse ‘Is Stored In’ - Fact: Airplane_Hanger(X) ‘stores’ Airplane(Y) l Example 2: - DL Rule: ‘Is Located In’ is Transitive. - Fact: Polygon(S) ‘Is Located In’ Polygon(V) Polygon(V) ‘Is Located In’ Polygon(T)

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

63. Geo-WS Security: Example l Resource := Washington, Oregon, California, West Coast l Rule:= West Coast = WA Union OR Union CA l Policy:= - Subject:= Bob - Resources:= WA, OR, CA - Action:=Read l Query: Retrieve Interstate Highway topology of West Coast

64. SAC in Action l Environment: University Campus l Campus Ontology http://utd61105.campus.ad.utdallas.edu/geo/voc/campusonto l Main Resources - Computer Science Building - Pharmacy Building - Electric Generator in each Building

65. SAC in Action l 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 l Policy File located at http://utd61105.campus.ad.utdallas.edu/geo/voc/policyfile1

66. SAC Improvements l Subjects, Resources, Actions and Conditions are defined independently l Reduced policy look-up cost -- only policies related to the requester is processed l No long path name!

67. Distributed Access Control Travel SiteReimbursement SiteBank Site Travel Data & Ontology Reimbursement Data Bank Site & Ontology Client Query Interface Middleware

68. Common Threads and Challenges l Common Threads - Building Ontologies for Semantics - XML for Syntax l Challenges - Scalability, Resolvability - Security policy specification, Securing the documents and ontologies - Developing applications for secure semantic web technologies - Automated tools for ontology management l Creating, maintaining, evolving and querying ontologies