• A. Each record in Database A is classified as either private or public. After Service A is invoked by a service consumer (1), it authenticates the request message using an identity store and retrieves the corresponding authorization (2, 3). Once authorized, the service consumer's request is submitted to Database A (4), which then returns the requested data (5) If the service consumer has private access permissions, all of the returned data is included in Service A's response message (6). If the service consumer has public access permissions, then Service A first filters the data in order to remove all unauthorized private data records before sending to the response message to the service consumer (6).
  
  In addition to retrieving data, Service A's data access capability can be used to update database records. An investigation recently revealed an information leakage problem that can occur when service consumers with public access permissions attempt to update the ID value of a database record The ID values of all database records (private or public) must be unique. When a service consumer with public access permissions updates a public database record with an ID value that is already assigned to a private database record, the database returns an error message describing this conflict. This error text reveals confidential information by stating that the ID value submitted by the service consumer with public access permissions already exists within a private database record.
  What steps can be taken to avoid this problem while preserving the requirement that all database records (private and public) have unique ID values?
• B. The service consumer's request message containing the ID value can be encrypted by inserting the private key of the service consumer into the data. Because all service consumers have different private keys, this approach will lead to different encrypted values, even if the plain text ID values are the same. As a result, two data items with the same encrypted unique identifier cannot exist.
• C. The Exception Shielding pattern is applied to replace the error description text before a response message is returned to the service consumer. Furthermore, the ID value of all database records is appended with a code indicating whether the database record is private or public
• D. When Service A detects that a service consumer with public access permissions has submitted an ID value that already exists within a private database record, it stores the service consumer's ID value in a temporary database and returns a response message indicating that the update was successful. A notification message is then sent to a human database administrator who manually contacts the owner of the service consumer in order to explain that the ID value submitted cannot be accepted because it already exists within a private database record.
• E. The database rules are changed so that the ID value of database records no longer needs to be unique. As a further precaution, the Service A logic is changed to disallow the update of private database records by service consumers with only public access permissions.

Service A provides a customized report generating capability. Due to infrastructure limitations, the number of service consumers permitted to access Service A concurrently is strictly controlled. Service A validates request messages based on the supplied credentials (1). If the authentication of the request message is successful, Service A sends a message to Service B (2) to retrieve the required data from Database A (3). Service A stores the response from Service B (4) in memory and then issues a request message to Service C (5). Service C retrieves a different set of data from Database A (6) and sends the result back to Service A (7). Service A consolidates the data received from Services B and C and sends the generated report in the response message to the service consumer (8).

It has been discovered that attackers have been gaining access to confidential data exchanged between Service A and Service B, and between Service A and its service consumers. What changes can be made to this service composition architecture in order to counter this threat?

• A. None of the above
• B. Apply the Service Perimeter Guard pattern in order to protect message exchanges between Service A and its service consumers. Apply the Direct Authentication pattern in order to protect message exchanges between Service A and Service B.
• C. Apply the Direct Authentication pattern in order to protect message exchanges between Service A and its service consumers and between Service A and Service B.
  This approach will establish a password-based authentication mechanism that relies on a local identity store and will therefore prevent access by attackers.
• D. Apply the Data Origin Authentication pattern to protect the final report sent by Service A to its service consumer. Service A can generate a message digest of the final report, after which it can sign the digest with its own private key. It then can send both the final report and the signed message digest to its service consumer. This service consumer can generate its own message digest, decrypt the signed digest using the public key of Service A (which proves that Service A sent the message), and then compare the two digests. If the digests match, it guarantees that the final report was not tampered with during transmission.

Service Consumer A sends a request message with a Username token to Service A (1).
Service B authenticates the request by verifying the security credentials from the Username token with a shared identity store (2), To process Service Consumer A's request message. Service A must use Services B, C, and D.
Each of these three services also requires the Username token (3. 6, 9) in order to authenticate Service Consumer A by using the same shared identity store (4, 7, 10). Upon each successful authentication, each of the three services (B, C, and D) issues a response message back to Service A (5, 8, 11).
Upon receiving and processing the data in all three response messages, Service A sends its own response message to Service Consumer A (12).

There are plans implement a single sign-on security mechanism in this service composition architecture. The service contracts for Services A, C, and D can be modified with minimal impact in order to provide support for the additional messaging requirements of the single sign-on mechanism. However, Service B's service contract is tightly coupled to its implementation and, as a result, this type of change to its service contract is not possible as it would require too many modifications to the underlying service implementation.
Given the fact that Service B's service contract cannot be changed to support single sign- on, how can a single sign-on mechanism still be implemented across all services?

• A. Apply the Brokered Authentication pattern to establish Service A as an authentication broker that issues a SAML token for Service Consumer A and forwards Service Consumer A's token to other services. Apply the Trusted Subsystem pattern to create a utility service that acts as a trusted subsystem for Service B.
  This utility service is able to perform authentication using the SAML token from Service A and can then generate a Username token by embedding its own credentials when accessing Service B.
  This way, Service B can perform authentication of request messages as it does now, but it can still participate in the single sign-on message exchanges without requiring changes to its service contract.
• B. Apply the Brokered Authentication pattern so that Service A acts as an authentication broker that issues a SAML token on behalf of Service Consumer A, and forwards this token to Services C and D.
  Create a new utility service is positioned between Service A and Service B.
  This utility service perform a conversion of the SAML token to a Username token, and then forwards the Username token to Service B so that Service B can still perform authentication of incoming requests using its own security mechanism.
• C. Replace the Username tokens with X.509 digital certificates. This allows for the single sign-on mechanism to be implemented without requiring changes to any of the service contracts.
• D. Apply the Brokered Authentication pattern so that Service A acts as an authentication broker that issues a SAML token for Service Consumer A and forwards Service Consumer A's token to Services C and D.
  Create a second service contract for Service B that supports single sign-on. This way, Service B can still perform authentication of incoming requests using the old service contract while allowing for the processing of SAML tokens using the new service contract.