1 / 7

Processing model ORCL/SAP Proposal Overview (1/3)

Processing model ORCL/SAP Proposal Overview (1/3). RMS. RMD. 1. Application. Application. 2. 6. RM Processor. RM Processor. RM CS. RM CS. 5. 3. 4. Security Processor. Security Processor. WSS. RM CS. WSS. RM CS. 1. Application. 2. RM Processor. or. 3a. 3b.

crwys
Download Presentation

Processing model ORCL/SAP Proposal Overview (1/3)

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. Processing model ORCL/SAP ProposalOverview (1/3) RMS RMD 1 Application Application 2 6 RM Processor RM Processor RM CS RM CS 5 3 4 Security Processor Security Processor WSS RM CS WSS RM CS

  2. 1 Application 2 RM Processor or 3a 3b Security Processor Processing model ORCL/SAP ProposalRM Source Processing (2/3) • Step 1: Application wants to use a secure reliable channel and signals this to the RM processor • Step 2: RM processor creates the CS message (without any additional WSS elements) with the wsrm:UsesSequenceSTR RM header and hands it over to the Security processor • Step 3: Security processor adds (several) signatures to the CS message. One signature is used to secure the CS element. This requires knowledge of which elements the Signature must refer to. The security processor then sets the @Usage attribute value of the STR used inside the CS Signature element to the specified URI value ../SequenceToken which is otherwise uninterpreted. For any subsequent messages of this sequence, the mapping table between the token and the sequence could be either managed by the security or the RM processor, based on the preferred architecture/design: • Managing abstract token handles in the RM layer: Long myUniqueSeqTokenHandle = SecProcessor.createSecureSequence(csMsg) • Delegation of the token/sequence mapping to the Security layer: Boolean sentSecSequence = SecProcessor.createSecureSequence(csMsg) In any case, the RM processor is not required to understand security artifacts since it may only work with abstract handles (3a).

  3. Application 6 RM Processor 5a 5b or 4 Security Processor Processing model ORCL/SAP ProposalRM Destination Processing (3/3) • Step 4: Security Processor receives CS message. All it could do at this point in time is simply verifying the signatures as with every other message it receives, leaving the “…/SequenceToken” URI uninterpreted. However – based on architectural preferences – the Security Processor could also verify the Token and Signature used to protect the Sequence by identifying the Token referenced in the STR with the @Usage URI value set to „…/SequenceToken“. In this case, Step 5a/b are obsolete. • Step 5: RM processor identifies the UsesSequenceSTR header. Based on architectural preferences, the RM/Security processor can interact via two ways: • Security Processor returns an abstract handle (NOT the WSS STR) for the Token used to secure the sequence. In this case, the RM layer keeps the knowledge / mapping table between token and sequence Long myAbstractTokenHandle = SecProcessor.getSeqTokenHandle(sequenceId) • Security Processor simply verifies if the Sequence has been signed by the right token. In this case, the Security layer keeps the mapping table. Boolean verifiedSecuredSeq = SecProcessor.verifySequence(sequenceId) • Step 6: Based on the result of the call in step 4/5a/5b, RM Processor does normal RM processing (establishing sequence etc.)

  4. Processing model IBM/MSFT ProposalOverview (1/3) RMS RMD 1 Application Application RM-Processor RM-Processor RM CS STR RM CS STR STR 2 7 4 3 STR 8 6 Security Processor Security Processor WSS RM CS STR WSS RM CS STR 5

  5. Processing model IBM/MSFT ProposalRM Source Processing (2/3) • Step 1: Application wants to use a secure reliable channel and signals this to the RM processor • Step 2: RM processor creates the CS message (with the the UsesSequenceSTR RM header). It therefore has to ask the Security Processor at this point in time: Please give me a valid STR that references the token used to secure the sequence. • Step 3: Security processor creates/fetches the token to secure the sequence and creates the wsse:STR for it. It then returns it to the RM processor. • WSSESecurityTokenReference sequenceSTR = SecurityProcessor.getSTRForSequence(csMsg) • Step 4: RM Processor adds the wsse:STR it received from Security Processor to the body of the message and updates the mapping table between the Token (referenced by the STR) and the Sequence. The RM processor therefore must at least • understand the WSS Schema for the Security Token Reference • understand the WSS Schema for embedded Tokens (as opposed to a pointer to a Token that resides elsewhere) • understand the XML Signature Schema if the STR is used to carry a ds:KeyInfo element • Step 5: Security Processor now adds (several) signatures to the final message. One signature is used to secure the CS element. This requires knowledge of which RM elements the Signature must refer to. The security processor must also remember which Token/STR it returned to the RM processor in the previous step.

  6. Processing model IBM/MSFT ProposalRM Destination Processing (3/3) • Step 6: Security Processor receives CS message. All it can do at this point in time is to verify the signatures of the messages as it would do with every other message it receives. • Step 7: RM processor identifies the UsesSequenceSTR header. Since only this layer has the required mapping information between Security/Token and the RM Sequence, it must call back to the Security Processor with the STR in order to verify if the Sequence is protected with the correct Token. Again, the RM processor therefore must at least • understand the WSS Schema for the Security Token Reference • understand the WSS Schema for embedded Tokens (as opposed to a pointer to a Token that resides elsewhere) • understand the XML Signature Schema if the STR is used to carry a ds:KeyInfo element Boolean verifiedSecuredSeq = SecProcessor.verifySequence(wsseSTR, sequenceId) • Step 8: Based on the result of the call in step 7, RM Processor does normal RM processing (establishing sequence etc.)

  7. Conclusion • Oracle‘s/SAP‘s proposal provides • more architectural flexibility (e.g. which layer will manage the token/sequence association) • a more decoupled composition of RM and Security layer  no ‚pollution‘ of RM messages with non-RM namespaces / elements • simplified processing model with fewer interactions between RM and Security layer • an application message / token referencing mechanism based on an approved OASIS standard (Web Services Security: SOAP Message Security 1.1, lines 870 – 874) • composability with any existing or upcoming security protocol (e.g. WS-SecureConversation)

More Related