1 / 20

Securing Web Services Using Semantic Web Technologies

Securing Web Services Using Semantic Web Technologies. Brian Shields PhD Candidate, Department of Information Technology, National University of Ireland, Galway. Introduction. Introduction to Security Web Services Security Standards landscape

merton
Download Presentation

Securing Web Services Using Semantic Web Technologies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 IASW 2005, Jyväskylä, Finland. Brian Shields

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

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

  5. Location of XML Signature <PurchaseOrder> <Price>100</Price> <Signature> …… </Signature> </PurchaseOrder> • Enveloped Signature • Enveloping Signature • Detached Signature <Signature> <Signature> URI Internet 1100010101 0101 1 1 001 1101 1101001 010101 010101 010 1011 0101 <PurchaseOrder> <Price>100</Price> </PurchaseOrder> </Signature> </Signature> XML Signature • Canonicalization C14N <Details> <Name>John Smith</Name> </Details> <Details><Name>John Smith</Name></Details> IASW 2005, Jyväskylä, Finland. Brian Shields

  6. <PaymentInfo> <Name>John Smith</Name> <EncryptedData> <CytherData> <CypherValue> jklds0890sd </CypherData> </CypherData> </EncryptedData> </Payment> • XML element and its contents XML Encryption • W3C Objectives • Encrypted data can be expressed using XML • Portions of an XML document can be selectively encrypted <PaymentInfo> <Name>John Smith</Name> <CreditCard Limit=‘3000’> <Number>1234 5678</Number> </CreditCard> </Payment> • Types of Encryption IASW 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 <PaymentInfo> <Name>John Smith</Name> <CreditCard Limit=‘3000’> <Number>1234 5678</Number> </CreditCard> </Payment> • Types of Encryption <PaymentInfo> <Name>John Smith</Name> <CreditCard Limit=‘3000’> <Number> <EncryptedData> …….. </EncryptedData> </Number> </CreditCard> </Payment> • XML element and its contents • Contents of an XML element • Arbitrary data • Super encryption IASW 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 IASW 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. IASW 2005, Jyväskylä, Finland. Brian Shields

  10. WS-Security <S:Envelope> <S:Header> <wsse:Security> <wsu:Timestamp> <xenc:ReferenceList> <xenc:EncryptedKey> <wsse:UsernameToken> <wsse:SecurityTokenReference> XML-based token <wsse-Reference> <wsse-KeyIdentifier> <wsse-Embedded> or <wsse:BinarySecurityToken> <ds:Signature> <S:Body> <xenc:EncryptedData> IASW 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 IASW 2005, Jyväskylä, Finland. Brian Shields

  12. PEP Policy enforcement point Web service Client Web service Client PIP Policy information point PDP Policy decision point Policy Store (XACML) PRP Policy retrieval point PAP Policy administration point XACML Architecture IASW 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 IASW 2005, Jyväskylä, Finland. Brian Shields

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

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

  18. Act Relationship RoleLink 0..* 0..* 0..* 0..* Plays 1 1 1 1 0..* Entity Role 0..* Participation Act 0..* 0..1 0..* 1 0..1 0..1 Scopes Performer Author Witness Subject Destination … Observation Procedure Referral Supply Act content …etc Participation Type Code Organisation Person Material Place …etc Patient Employee Practitioner Specimen …etc 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 IASW 2005, Jyväskylä, Finland. Brian Shields

  19. Client_1 Client_2 SOAP Request SOAP Request a b a b Access Filtering Authentication iWISE Secure 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 IASW 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 IASW 2005, Jyväskylä, Finland. Brian Shields

More Related