S90.20 SOA Security Lab

Loading demo links...

Showing 4–5 of 5 questions

Question 4

Service Consumer A sends a request message to Service A (1), after which Service A sends a request message to Service B (2). Service B forwards the message to have its contents calculated by Service C (3). After receiving the results of the calculations via a response message from Service C (4), Service B then requests additional data by sending a request message to Service D (5). Service D retrieves the necessary data from Database A (6), formats it into an XML document, and sends the response message containing the XML-formatted data to Service B (7).

Service B appends this XML document with the calculation results received from Service C, and then records the entire contents of the XML document into Database B (8). Finally, Service B sends a response message to Service A (9) and Service A sends a response message to Service Consumer A (10).

C:\Documents and Settings\user-nwz\Desktop\1.JPG

Services A, B and D are agnostic services that belong to Organization A and are also being reused in other service compositions. Service C is a publicly accessible calculation service that resides outside of the organizational boundary. Database A is a shared database used by other systems within Organization A and Database B is dedicated to exclusive access by Service B.

Service B has recently been experiencing a large increase in the volume of incoming request messages. It has been determined that most of these request messages were auto-generated and not legitimate. As a result, there is a strong suspicion that the request messages originated from an attacker attempting to carry out denial-of-service attacks on Service B. Additionally, several of the response messages that have been sent to Service A from Service B contained URI references to external XML schemas that would need to be downloaded in order to parse the message data. It has been confirmed that these external URI references originated with data sent to Service B by Service C. The XML parser currently being used by Service A is configured to download any required XML schemas by default. This configuration cannot be changed.

What steps can be taken to improve the service composition architecture in order to avoid future denial-of-service attacks against Service B and to further protect Service A from data access-oriented attacks?

Select an option, then click Submit answer.

  • Apply the Data Origin Authentication pattern so that Service B can verify that request messages that claim to have been sent by Service A actually did originate from Service Apply the Message Screening pattern to add logic to Service A so that it can verify that external URIs in response messages from Service B refer to trusted sources.

  • Apply the Service Perimeter Guard pattern to establish a perimeter service between Service B and Service C. Apply the Brokered Authentication pattern by turning the perimeter service into an authentication broker that is capable of ensuring that only legitimate response messages are being sent to Service C from Service B Further apply the Data Origin Authentication pattern to enable the perimeter service to verify that messages that claim to have been sent by Service C actually originated from Service C. Apply the Message Screening pattern to add logic to the perimeter service to also verify that URIs in request messages are validated against a list of permitted URIs from where XML schema downloads have been pre-approved.

  • Apply the Service Perimeter Guard pattern and the Message Screening pattern together to establish a service perimeter guard that can filter response messages from Service C before they reach Services A and B. The filtering rules are based on the IP address of Service If a request message originates from an IP address not listed as one of the IP addresses associated with Service then the response message is rejected.

  • Apply the Direct Authentication pattern so that Service C is required to provide security credentials, such as Username tokens, with any response messages it sends to Service B. Furthermore, add logic to Service A so that it can validate security credentials passed to it via response messages from Service B. by using an identity store that is shared by Services A and B.

Question 5

Services A, B, and C reside in Service Inventory A and Services D, E, and F reside in Service Inventory B. Service B is an authentication broker that issues WS-Trust based SAML tokens to Services A and C upon receiving security credentials from Services A and C. Service E is an authentication broker that issues WS-Trust based SAML tokens to Services D and F upon receiving security credentials from Services D and E. Service B uses the Service Inventory A identify store to validate the security credentials of Services A and C. Service E uses the Service Inventory B identity store to validate the security credentials of Services D and F.

C:\Documents and Settings\user-nwz\Desktop\1.JPG

To date, the two service inventories have existed independently from each other. However, a requirement has emerged that the services in Service Inventory A need to be able to use the services in Service Inventory B, and vice versa.

How can cross-service inventory message exchanges be enabled with minimal changes to the existing service inventory architectures and without introducing new security mechanisms?

Select an option, then click Submit answer.

  • Because SAML tokens cannot be used across multiple security domains, authentication brokers C and E need to be replaced with one single authentication broker so that one token issuer is used for all services across both of the service inventories.

  • The current security mechanism already fulfills the requirement because SAML tokens can be used across multiple security domains. The only change required is for each authentication broker to be configured so that it issues service inventory-specific assertions for SAML tokens originating from other service inventories.

  • The individual domain service inventories need to be combined into one enterprise service inventory. The Service Perimeter Guard pattern can be applied to establish a contact point for request messages originating from outside the service inventory. Within the service inventory, services no longer need to be authenticated because they are all part of the same trust boundary.

  • The Trusted Subsystem pattern is applied to encapsulate Services B and E using a central utility service that balances request and response messages exchanged between Services B and E, depending on which service inventory the messages originate from. The utility service also contains transformation logic to ensure that the SAML tokens issued by Services B and E are compatible. This guarantees that an issued SAML token can be used across Service Inventories A and B without further need for runtime conversion.