Web Services and the Semantic Web: Open Discussion Session Diana Geangalau Ryan Layfield

OASIS   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

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

OASIS  Concepts  Security Tokens  Signatures  Security Concerns  Confidentiality: Encryption  Integrity: Signature  Policy Definition Location

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

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).

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).

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.

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

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.

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.

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

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)

SAML  Three main components (from tip/1,289483,sid26_gci818643,00.html ) 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.

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

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

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)

SAML  How do we deal with older systems that don’t support this protocol with those that do?

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

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

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 it’s 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

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?

XACML  How would you feel if you were using work that a corporation gave on it’s word on alone that it would never assert the rights to it?

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

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 it’s 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?

References  Sun’s XACML Documentation:  OpenSAML:  OASIS:  Wikipedia’s Entry on SAML:

Questions ?