1. Securing Web Services Using Semantic Web Technologies Brian Shields PhD Candidate, Department of Information Technology, National University of Ireland, Galway

2. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 2 Introduction Introduction to Security Web Services Security –Standards landscape Existing access control language for Web Services Proposed Security Architecture Proposed access control language Novel document filtering Case Study: Health Sector

3. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 3 Introduction to Security Confidentiality Integrity Non-Repudiation Authentication Authorisation Privacy Availability Digital Signatures Digital Certificates Username & Password Kerberos Tickets ACL RBAC Encryption

4. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 4 Standards Landscape High-Level Security Features Transmission Control Protocol (TCP/IP) Transport Layer (HTTP, FTP, SMTP, JMS, etc) Transmission Control Security (TLS/SSL) XML Signature XML Encryption SOAP Web Services Security (WS-Security) SAMLXACMLXKMS

5. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 5 –Enveloping Signature 100 1100010101 0101 1 1 001 1101 1101001 010101 010101 010 1011 0101 XML Signature Canonicalization C14N John Smith Location of XML Signature –Enveloped Signature 100 …… –Detached Signature URI Interne t

6. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 6 XML Encryption W3C Objectives –Encrypted data can be expressed using XML –Portions of an XML document can be selectively encrypted Types of Encryption John Smith 1234 5678 –XML element and its contents John Smith jklds0890sd

7. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 7 XML Encryption W3C Objectives –Encrypted data can be expressed using XML –Portions of an XML document can be selectively encrypted Types of Encryption –Contents of an XML element –XML element and its contents John Smith 1234 5678 John Smith …….. –Arbitrary data –Super encryption

8. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 8 XKMS XML Key Management Specification –XKISS –XKRSS XML Key Information Service Specification –Locate Service –Validate Service XML Key Registration Service Specification –Register Service –Recover Service –Reissue Service –Revoke Service

9. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 9 WS-Security Enhancements to SOAP messaging to provide end-to-end, and single message integrity, message authentication and message confidentiality Leverages XML Signature (multiple) + XML Encryption Mechanism for associating security tokens with message content Specifies how to encode binary security tokens, XML-based tokens, and how to include opaque encrypted keys Can support any kind of security token –Kerberos, X.509 certificates, Username & Password.

10. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 10 WS-Security XML-based token or

11. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 11 XACML eXtensible Access Control Markup Language Access granted based on characteristics –User – member of accounts group –Protocol – SSL –Authentication – digital certificate Policies are the foundation of XACML –A target –Rule combining algorithm –Set of rules Target –Resources, Subjects, Actions Effect –Permit/Deny Conditions

12. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 12 XACML Architecture PAP Policy administration point PIP Policy information point PRP Policy retrieval point PDP Policy decision point Policy Store (XACML) Web service PEP Policy enforcement point Client Web serviceClient

13. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 13 iWISE Security Architecture SOAP Message Interceptor Encryption/Decryption engine Key Management Access Control at two levels –Initial access control to verify requested endpoints and users –Fine grained, semantically aware access control model Management Console

14. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 14 iWISE Security Architecture 2 nd Tier Access Control Policy Enforcement Point Subjects (OWL) Resource Descriptions (OWL) Policies (XACML + OWL) Policy Administration Point Policy Decision Point Policy Information Point 1 st Tier Access Control Encryption/ Decryption Engine Key Store Key Request Key Generation Key Registration Key Management Framework Management Console SOAP Message Interceptor Key Inter package interaction Intra package interaction

15. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 15 iWISE Access Control Language Architecturally similar to that of XACML Language created in OWL-DL –Identified OWL-DL atomic classes Racer used as reasoning engine –Proven OWL reasoning engine PolicySet PolicyCombiningAlgorithm Policy Target Subject Resource Action Environment RuleCombiningAlgorithm Rule Condition Effect Obligation

16. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 16 Restricted Document Access Fine grained access control –An an XML element level Organisational level –Many people with access to same document –Should all people have the same authorisation? –Propose limited access Documents must be defined semantically at an element level All users are defined semantically iWISE access control language defines who can access what Semantic Reasoner will enforce these rules

17. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 17 Restricted Document Access Client Web Service Request Interceptor Response Interceptor Access Control Access Restrictions

18. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 18 Case Study: Health Sector Security and access control critical. Access control usually achieved by defining static rule sets. Poor adoption of standards. Health Level 7 – HL7 –Standard for information representation in health Patient Employee Practitioner Specimen …etc Organisation Person Material Place …etc Observation Procedure Referral Supply Act content …etc Performer Author Witness Subject Destination … Participation Type Code RoleLink Act Relationship 0..* 1111 ParticipationActEntity Plays Scopes 0..1 0..* 1 0..1 0..* Role

19. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 19 Case Study: Health Sector Member of hospital staff requests patient files. Staff member is first authenticated, then access rights are determined –Doctor on case gets full access –Admin staff get personal/billing information –Consulting doctor gets clinical data but not personal data iWISE Secure Client_1Client_2 Authentication Access Filtering SOAP Request abab a b

20. 26/06/2015IASW 2005, Jyväskylä, Finland. Brian Shields 20 Conclusions Web Services Web Services Security –Standards –Implementations Proposed Architecture –Policy Language –Document Filtering –Case Study: Health Sector