Web Services and the Semantic Web: Open Discussion Session - PowerPoint PPT Presentation

1 / 28
About This Presentation
Title:

Web Services and the Semantic Web: Open Discussion Session

Description:

End-to-end message content security and not just transport-level security. OASIS. Concepts ... R: Yes. ... R: If security semantics are 'old', they might be ... – PowerPoint PPT presentation

Number of Views:68
Avg rating:3.0/5.0
Slides: 29
Provided by: ryanla
Category:

less

Transcript and Presenter's Notes

Title: Web Services and the Semantic Web: Open Discussion Session


1
Web Services and the Semantic WebOpen
Discussion Session
  • Diana Geangalau
  • Ryan Layfield

2
OASIS
  • http//www.oasis-open.org/home/index.php
  • Web Services are a way of implementing
    service-orientation architecture
  • Supposed to be Internet-based
  • XML-oriented
  • More than just connecting web pages
  • Must be structure behind them
  • Self-contained (i.e. self-describing)
  • What was the original intention of it?
  • How do they treat the security issues in
    service-oriented architecture?
  • Helps to resolve contradicting standards among
    multiple needs

3
OASIS
4
OASIS
  • WS security as enhancements to SOAP messaging to
    provide message integrity and confidentiality.
  • Requirements
  • Multiple security token formats
  • Multiple trust domains
  • Multiple signature formats
  • Multiple encryption technologies
  • End-to-end message content security and not just
    transport-level security

5
OASIS
  • Concepts
  • Security Tokens
  • Signatures
  • Security Concerns
  • Confidentiality Encryption
  • Integrity Signature
  • Policy Definition Location

6
OASIS
  • Signatures
  • Provide a way for the recipients to verify the
    integrity of the message
  • Sign the important parts of the message
  • To verify if the policies of a security token
    apply to the sender

7
OASIS
  • Is the security policy specified only once?
  • R No. Security policy can be targeted for the
    destination as well as for any intermediary
    therefore can be present a number of times in the
    SOAP message once for each target (multiple
    headers).

8
OASIS
  • Can you have multiple signatures attached to a
    message?
  • R Yes. Multiple signatures can reference
    different or overlapping parts of the message,
    reason being in distributed applications messages
    usually go through multiple processing stages
    (workflow).

9
OASIS
  • Can you see the issues involved with multiple
    processing stages?
  • R There are issues with the signatures for
    important parts of the message that need to be
    legitimately altered during the various stages of
    processing.

10
OASIS
  • Encryption
  • Can encrypt header blocks, body blocks, or part
    of them
  • Common symmetric key shared by the sender and the
    receiver
  • Encrypted symmetric key inside the message

11
OASIS
  • Can you have overlapping encryption for parts of
    message? Why? In which order should they be
    encrypted?
  • R Yes. Because the decryption might be done in
    the different stages of processing. The order has
    to be predefined by prior agreement.

12
OASIS
  • Can you think what freshness of security
    semantics means?
  • R If security semantics are old, they might be
    ignored by the receiver. Need to specify time
    references but the specification does not provide
    a mechanism for synchronizing time.

13
OASIS
  • Where would you specify the time references?
  • R XML Schema (web services are XML based).

14
SAML
  • Security Assertion Markup Language
  • Designed to provide a single point of
    authorization
  • Aims to solve the web single sign-on problem
  • One identity provider in group allows access
  • Public/Private Key Foundation
  • Competitors
  • Microsoft Passport
  • OpenID (VeriSign)
  • Global Login System (Open Source)

15
SAML
  • Three main components (from http//searchwebservic
    es.techtarget.com/ tip/1,289483,sid26_gci818643,00
    .html )
  • Assertions SAML has three kinds of assertions.
    Authentication assertions are those in which the
    user has proven his identity. Attribute
    assertions contain specific information about the
    user, such as his spending limits. Authorization
    decision assertions identify what the user can
    do, for example, whether he can buy an item.
  • Protocol This defines the way that SAML asks for
    and gets assertions, for example, using SOAP over
    HTTP for now, although using other methods in the
    future.
  • Binding This details exactly how SAML message
    exchanges are mapped into SOAP exchanges.

16
SAML
  • Do you think SOAP is an efficient platform for
    security?

17
SAML
  • Are you comfortable knowing that part of your
    security implementation was written by the
    community? (Open-source)

18
SAML
  • How do you think we should handle multiple system
    types across a network? Do you think we need a
    new protocol to address this, or should SAML be
    expanded? (Federations)

19
SAML
  • How do we deal with older systems that dont
    support this protocol with those that do?

20
SAML
  • Outstanding Issues
  • Performance
  • No Caching
  • Text-based transfer
  • Does not specify encryption (policies may be
    compromisable)
  • Binary must be encoded in Base64
  • Must be implemented over HTTP protocol via SOAP
  • Ownership
  • Sun developed large amount of it (via OpenSAML)
  • Claims it will not assert ownership
  • What happens if they do?
  • Federations
  • Authentication protcols not specified
  • Multiple domains are an issue
  • SAML 2.0 supposed to address this will it be at
    the cost of becoming monolithic?
  • Legacy Applications
  • Very expensive to retro-fit

21
XACML
  • eXtensible Access Control Markup Language
  • Highlights (from OASIS)
  • Combines multiple rules into a single policy
  • Permit multiple users to have different roles
  • Provide separation between policy writing and
    application environment
  • Ultimately standardizes access control languages

22
XACML
  • Users interact with resources
  • Every resource is protected by an entity known as
    a Policy Enforcement Point (PEP)
  • This is where the language is actually used
  • Does not actually determine access
  • PEP sends its request to a Policy Decision Point
    (PDP)
  • Policies may or may not be actually stored here
  • Makes the final say on access
  • Decision is relayed to PEP, which then grants or
    denies access

23
XACML
  • Do you think a system is more secure or less
    secure when it is distributed across multiple
    computers? What about a single system
    responsible for all?

24
XACML
  • How would you feel if you were using work that a
    corporation gave on its word on alone that it
    would never assert the rights to it?

25
XACML
  • Should policies be self-contained, or is it OK
    for them to reference each other? Is cross-PDP
    communication safe?

26
XACML
  • Outstanding Issues
  • Distributed Responsibility
  • What happens when the PEP is responsible for
    multiple objects?
  • What happens when we can compromise the PDP or
    spoof its communication?
  • How do we guarantee that we reference the right
    object?
  • While the system is distributed, a policy is
    still in only one location
  • Ownership
  • Contributors like Sun have again done work in
    this area
  • Same as with SAML
  • Policy Cross-Referencing
  • One policy may access another
  • Typical issues arrise as with inheritance and
    unions/intersections of related work
  • How do we deal with conflicts?

27
References
  • Suns XACML Documentation http//sunxacml.sourcef
    orge.net/guide.html
  • OpenSAML http//www.opensaml.org/
  • OASIS http//www.oasis-open.org/home/index.php
  • Wikipedias Entry on SAML http//en.wikipedia.org
    /wiki/SAML

28
Questions
  • ?
Write a Comment
User Comments (0)
About PowerShow.com