Securing Web Services Using Semantic Web Technologies Brian

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

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 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 2

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

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

XML Signature • Canonicalization C 14 N • Location of XML Signature <Details> <Name>John Smith</Name> </Details> <Details><Name>John Smith</Name></Details> <Signature> 1100010101 1 1 001 <Purchase. Order> 1101001 010101 <Price>100</Price> 010101 010 1011 0101 </Purchase. Order> – Enveloped Signature – Enveloping Signature – Detached Signature <Purchase. Order> <Price>100</Price> <Signature> …… </Signature> <Signature> URI Internet </Purchase. Order> </Signature> 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 5

XML Encryption • W 3 C Objectives – Encrypted data can be expressed using XML – Portions of an XML document can be selectively encrypted • Types of Encryption – XML element and its contents 09/03/2021 <Payment. Info> <Name>John Smith</Name> <Credit. Card Limit=‘ 3000’> <Number>1234 5678</Number> </Credit. Card> </Payment> <Payment. Info> <Name>John Smith</Name> <Encrypted. Data> <Cyther. Data> <Cypher. Value> jklds 0890 sd </Cypher. Data> </Encrypted. Data> </Payment> IASW 2005, Jyväskylä, Finland. Brian Shields 6

XML Encryption • W 3 C Objectives – Encrypted data can be expressed using XML – Portions of an XML document can be selectively encrypted • Types of Encryption – XML element and its contents – Contents of an XML element – Arbitrary data – Super encryption 09/03/2021 <Payment. Info> <Name>John Smith</Name> <Credit. Card Limit=‘ 3000’> <Number>1234 5678</Number> </Credit. Card> </Payment> <Payment. Info> <Name>John Smith</Name> <Credit. Card Limit=‘ 3000’> <Number> <Encrypted. Data> ……. . </Encrypted. Data> </Number> </Credit. Card> </Payment> IASW 2005, Jyväskylä, Finland. Brian Shields 7

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 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 8

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. 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 9

WS-Security <S: Envelope> <S: Header> <wsse: Security> <wsu: Timestamp> <xenc: Reference. List> <xenc: Encrypted. Key> <wsse: Username. Token> <wsse: Security. Token. Reference> or <wsse: Binary. Security. Token> XML-based token <wsse-Reference> <wsse-Key. Identifier> <wsse-Embedded> <ds: Signature> <S: Body> <xenc: Encrypted. Data> 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 10

XACML • e. Xtensible 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 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 11

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

i. WISE 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 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 13

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

i. WISE Access Control Language • Architecturally similar to that of XACML • Language created in OWL-DL – Identified OWL-DL atomic classes Policy. Set Policy. Combining. Algorithm Policy Target Subject Resource Action Environment Rule. Combining. Algorithm Rule Condition Effect Obligation • Racer used as reasoning engine – Proven OWL reasoning engine 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 15

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 • i. WISE access control language defines who can access what • Semantic Reasoner will enforce these rules 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 16

Restricted Document Access Web Service Client 09/03/2021 Request Interceptor Response Interceptor Access Control Access Restrictions IASW 2005, Jyväskylä, Finland. Brian Shields 17

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 – HL 7 – Standard for information representation in health Act Relationship Role. Link 0. . * Plays 1 1 1 0. . * Entity 0. . 1 0. . * Role 0. . 1 0. . * 1 Participation 0. . * 0. . 1 1 Act Scopes Organisation Person Material Place …etc 09/03/2021 Patient Employee Practitioner Specimen …etc Performer Author Witness Subject Destination … Participation Type Code IASW 2005, Jyväskylä, Finland. Brian Shields Observation Procedure Referral Supply Act content …etc 18

Case Study: Health Sector Client_2 est a b AP equ SO ues Req t 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 Client_1 PR • Member of hospital staff requests patient files. a b SOA • Access Filtering Authentication i. WISE Secure 09/03/2021 IASW 2005, Jyväskylä, Finland. Brian Shields 19

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