www oasisopen org Securing Queued Messages Click to
- Slides: 15
www. oasis-open. org Securing Queued Messages Click to edit Master title for style Web Services n Hal Lockhart, BEA Systems
www. oasis-open. org Topics n n Introduction Benefits of queued messaging Queued Messaging Authorization Model Delayed Messages l l l Web Services Usecases A modest proposal Using delay information
Queued Messaging n n n Messages not sent directly from Initiator to Ultimate Receiver Store and forward intermediary Enabled by Callback MEP May be transparent Persistent delivery effort
Benefits of Queuing n n n Sender does not have to handle Receiver unavailability Smoothes out burstiness of traffic Can add value, e. g. management, tracking, differential Qo. S, SLA measurement
Adding Security n More moving parts l n More potential points for Authorization l n More points of attack Authorization Model Messages don’t change l l l Message protection largely the same Except for time-based mechanisms The timeout problem
Internet Authorization Model WS Consumer A Queuing Node C Queuing Node D B Web Service
Time. Stamps in WS-Security n n n Signature freshness With a Nonce Token validity
The Timeout Problem n n Normally queue forwards messages in seconds or minutes Rarely the Web Service is down for an extended period (disk rebuild) Queued messages will all timeout Sender will have to deal with failure after all
Undesirable Cures n Error handling in Sender l n Long timeout values on all messages l n What we were trying to avoid Eliminates protection Manual recovery l Labor intensive and expensive
Proposed Solution n n Queuing system to add delay information to messages Threshold delay time No extra overhead in normal case Delay information digitally signed Need efficient way to learn when service is restored
Proposal for WS-Security /ws: Delay This is the element for indicating message delays. /ws: Delay/ws: Duration This element represents the time interval that the message was delayed. It is defined as the difference between the datetime the message was received by the Asserting Party and the datetime it was sent. /ws: Delay/ws: Received This element represents the datetime at which the message was received by the Asserting party. When this element is present, the <ws: Duration> or <ws: Sent> element MUST also be present. /ws: Delay/ws: Sent This element represents the datetime at which the message was sent by the Asserting party. When this element is present, the <ws: Received> element MUST also be present.
Sample Message <Envelope. . . > <Header> <Security Must. Understand=“ 1”> <Signature>. . . </Signature> <Delay> <Duration>P 0 DT 16 H 12 M 22 S<Duration/> <Received>2006 -08 -12 T 18: 27: 41 Z<Received/> </Delay>. . . </Security> </Header> <Body>. . . </Body> </Envelope>
Receiver Processing n Must trust delay information l n Signature freshness l l n Subtract delay if during transmission (Trivial in XACML) With a Nonce l n Already trusted to deliver messages Delay information doesn’t help Token validity l May or may not help
Summary n n n Use of queuing is beneficial Can use existing security mechanisms Additional risks More Authorization points Need to deal with the Timeout problem
www. oasis-open. org Click to edit Master title style Questions?
Queued spi
Failed command: write fpdma queued
Safety click
Click clever click safe campaign
Clever click
Click clever click safe
Https://media.hhmi.org/biointeractive/click/cellcycle/
The most common form of securing channel is through
Securing windows 7
Securing network devices
Chapter 8 securing information systems
Chapter 8 securing information systems
Securing information systems
How to drape a client for a shampoo
Securing frame communication in browsers
An information systems examines a firm's overall security
