Securing Web Services Using Semantic Web Technologies

1
Securing Web Services Using Semantic Web
Technologies

• Brian Shields
• PhD Candidate,
• Department of Information Technology,
• National University of Ireland, Galway

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
Introduction to Security

• Confidentiality
• Integrity
• Non-Repudiation
• Authentication
• Authorisation
• Privacy
• Availability

4
Standards Landscape
SAML
XACML
XKMS
High-Level Security Features
Web Services Security (WS-Security)
SOAP
XML Signature XML Encryption
5
XML Signature

• Canonicalization C14N

ltDetailsgt ltNamegtJohn Smithlt/Namegt
lt/Detailsgt ltDetailsgtltNamegtJohn Smithlt/Namegtlt/Detai
lsgt
6
XML Encryption

• W3C Objectives
• Encrypted data can be expressed using XML
• Portions of an XML document can be selectively
  encrypted

ltPaymentInfogt ltNamegtJohn Smithlt/Namegt
ltCreditCard Limit3000gt
ltNumbergt1234 5678lt/Numbergt
lt/CreditCardgt lt/Paymentgt

• Types of Encryption

7
XML Encryption

• W3C Objectives
• Encrypted data can be expressed using XML
• Portions of an XML document can be selectively
  encrypted

ltPaymentInfogt ltNamegtJohn Smithlt/Namegt
ltCreditCard Limit3000gt
ltNumbergt1234 5678lt/Numbergt
lt/CreditCardgt lt/Paymentgt

• Types of Encryption

ltPaymentInfogt ltNamegtJohn Smithlt/Namegt
ltCreditCard Limit3000gt
ltNumbergt ltEncryptedDatagt
..
lt/EncryptedDatagt lt/Numbergt
lt/CreditCardgt lt/Paymentgt

• XML element and its contents

• Contents of an XML element

• Arbitrary data

• Super encryption

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
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
WS-Security
ltSEnvelopegt
ltSHeadergt
ltwsseSecuritygt
ltwsuTimestampgt
ltxencReferenceListgt ltxencEncryptedKeygt
ltwsseUsernameTokengt
ltwsseSecurityTokenReferencegt
XML-based token ltwsse-Referencegt
ltwsse-KeyIdentifiergt ltwsse-Embeddedgt
or
ltwsseBinarySecurityTokengt
ltdsSignaturegt
ltSBodygt
ltxencEncryptedDatagt
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
XACML Architecture
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
iWISE Security Architecture
Key Store
Key Generation
Framework Management Console
Key Request
Key Registration
Key Management
Subjects (OWL)
Resource Descriptions (OWL)
Encryption/ Decryption Engine
Policy Enforcement Point
Policy Decision Point
Policy Information Point
1st Tier Access Control
SOAP Message Interceptor
Policies (XACML OWL)
Policy Administration Point
2nd Tier Access Control
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 S
ubject Resource Action
Environment RuleCombiningAlgorithm Rule Condition
Effect Obligation
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
Restricted Document Access
Client
Web Service
Request Interceptor
Response Interceptor
Access Control
Access Restrictions
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

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

20
Conclusions

• Web Services
• Web Services Security
• Standards
• Implementations
• Proposed Architecture
• Policy Language
• Document Filtering
• Case Study Health Sector