Online Access Free S90.20 Practice Test

Service A provides a data retrieval capability that can be used by a range of service consumers, including Service Consumer A.
In order to retrieve the necessary data, Service Consumer A first sends a request message to Service A (1). Service A then exchanges request and response messages with Service B (2, 3), Service C (4, 5), and Service D (6.
7). After receiving all three response messages from Services B.
C. and D, Service A assembles the collected data into a response message that it returns to Service Consumer A (8).

The owner of Service A charges service consumers for each usage of the data retrieval capability. Recently, the owner of Service Consumer A has complained that the data returned by Service A is incorrect, incomplete, and from invalid sources. As evidence, the Service Consumer A owner has presented the owner of Service A with sample messages containing the incorrect and incomplete contents. As a result, the Service Consumer A owner has refused to pay the usage fees. Subsequent to an internal investigation, the owner of Service A determines that the data returned by Service A is consistently correct and complete. There are suspicions that the Service Consumer A owner is altering the original messages and issuing these complaints fraudulently in order to avoid paying the usage fees.
How can the owner of Service A prove that Service A is returning correct and complete data and that this data originated from the correct sources?

• A.The service contract of Service A can be extended with an ignorable WS-Policy assertion that states that all request and response messages are logged by Service A and that false complaints will be prosecuted.
• B.Apply the Data Origin Authentication pattern to verily that request and response messages exchanged by Service Consumer A and Service A and exchanged by Service A and Services B, C, and D originated from the claimed sources and have not been altered prior to transmission. Also, enhance the Service A architecture so that all messages sent to its service consumers are logged.
• C.Apply the Data Origin Authentication and the Data Confidentiality patterns to ensure that request and response messages exchanged between Service A and Services B.
  C, and D are digitally signed and encrypted. This guarantees message integrity and confidentiality.
• D.Apply the Brokered Authentication pattern to send the security credentials of Service Consumer A to Services B, C, and D.
  Service A can carry out the brokered authentication logic and therefore act as the intermediary security broker. Upon receiving Service Consumer A's request message, Service A can further verify the credentials against an external certificate authority, if the request is authenticated. Service A can create a signed SAML assertion containing Service Consumer A's credentials and the authorization information. Service A then forwards the original request message and the signed SAML assertion to Services B, C, and D.

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 its service consumer (8).

This service composition was recently shut down after it was discovered that Database A had been successfully attacked twice in a row. The first type of attack consisted of a series of coordinated request messages sent by the same malicious service consumer, with the intention of triggering a range of exception conditions within the database in order to generate various error messages. The second type of attack consisted of a service consumer sending request messages with malicious input with the intention of gaining control over the database server. This attack resulted in the deletion of database records and tables. An investigation revealed that both attacks were carried out by malicious service consumers that were authorized.
How can the service composition security architecture be improved to prevent these types of attacks?

• A.Apply the Trusted Subsystem pattern to protect Database A from data-driven attacks and to evaluate whether database responses contain inappropriate data. The trusted subsystem maintains a snapshot of Database A and executes the original service consumer's request message against the snapshot. The processing logic that accesses the snapshot has limited privileges in order to prevent malicious attacks from overtaking the database. If no security violation is detected during the processing of the snapshot, then the original service consumer's request is forwarded to Database A.
  If an error message is generated during the processing of the snapshot, then it is returned to the original service consumer and the request is not forwarded to Database A.
  Because the error message was generated on the snapshot, it cannot contain unsafe information about Database A.
• B.Apply the Exception Shielding pattern together with the Message Screening pattern.
  This establishes new logic within Service A that screens incoming request messages for data-driven attacks (such as SQL injection and XPath injection attacks), and also evaluates whether exception details returned by Database A contains potentially confidential or unsafe information. Any inappropriate exception information is replaced with sanitized content.
• C.Apply the Data Confidentiality pattern together with the Data Origin Authentication pattern. This establishes message-level security so that all messages are encrypted and digitally signed. Secondly, the Service A logic must be enhanced so that it can keep track of the trustworthiness of its service consumers If a request message originated from a trustworthy service consumer, then the request message is processed as normal. If the request message originates from a non-trustworthy service consumer, then the request message is rejected and an error message is returned to the service consumer.
• D.Apply the Service Perimeter Guard pattern together with the Trusted Subsystem pattern.
  This establishes a perimeter service between Database A and any service that requires access to it (including Services B and C). The perimeter service evaluates incoming data requests and filters out those that can introduce a security risk. Only request messages issued by authorized services and service consumers are forwarded to Database A.
  Responses originating from Database A are further evaluated by the trusted subsystem to remove any unauthorized data. The two patterns together ensure that only authorized data is returned to the service consumer and that no request messages present a security threat to Database A.

Service Consumer A sends a request message with an authentication token to Service A, but before the message reaches Service A, it is intercepted by Service Agent A (1). Service Agent A validates the security credentials and also validates whether the message is compliant with Security Policy A.
If either validation fails, Service Agent A rejects the request message and writes an error log to Database A (2A). If both validations succeed, the request message is sent to Service A (2B).
Service A retrieves additional data from a legacy system (3) and then submits a request message to Service B Before arriving at Service B, the request message is intercepted by Service Agent B (4) which validates its compliance with Security Policy SIB then Service Agent C (5) which validates its compliance with Security Policy B.
If either of these validations fails, an error message is sent back to Service A.
that then forwards it to Service Agent A so that it the error can be logged in Database A (2A). If both validations succeed, the request message is sent to Service B (6). Service B subsequently stores the data from the message in Database B (7).
Service A and Service Agent A reside in Service Inventory A.
Service B and Service Agents B and C reside in Service Inventory B.
Security Policy SIB is used by all services that reside in Service Inventory B.
Service B can also be invoked by other service consumers from Service Inventory B.
Request messages sent by these service consumers must also be compliant with Security Policies SIB and B.

Access to the legacy system in Service Inventory A is currently only possible via Service A, which means messages must be validated for compliance with Security Policy A.
A new requirement has emerged to allow services from Service Inventory B to access the legacy system via a new perimeter service that will be dedicated to processing request messages from services residing in Service Inventory B.
Because the legacy system has no security features, all security processing will need to be carried out by the perimeter service.
However, there are parts of Security Policy A that are specific to Service A and do not apply to the legacy system or the perimeter service. Furthermore, response messages sent by the perimeter service to services from Service Inventory B will still need to be validated for compliance to Security Policy B and Security Policy SIB.
How can the Policy Centralization pattern be correctly applied without compromising the policy compliance requirements of services in both service inventories?

• A.Due to the amount of overlap among Security Policy A, Security Policy B, and Security Policy SIB, the Policy Centralization pattern cannot be correctly applied to enable the described message exchange between the perimeter service in Service Inventory A and services in Service Inventory B.
• B.A single centralized security policy can be created by combining Security Policy A, Security Policy B.
  and Security Policy SIB into a single security policy that is shared by services in both Service Inventory A and Service Inventory B.
  This means that the new perimeter service can share the same new security policy with Service A.
  This further simplifies message exchange processing because request messages sent by services in Service Inventory B to the new perimeter service need to comply to the same security policy as the response messages sent back by the perimeter service to the services in Service Inventory B.
• C.In order for Security Policy A to be centralized so that it can be shared by Service A and the new perimeter service, messages sent to the perimeter service from services in Service Inventory B will need to continue complying with Security Policy A, even if it requires that the messages contain content that does not relate to accessing the legacy system. In order to centralize Security Policy B it will need to be combined with Security Policy SIB, which means that the functionality within Service Agents B and C can be combined into a single service agent.
• D.The parts of Security Policy A that are required for access to the new perimeter service need to be removed and placed into a new security policy that is shared by Service A and the perimeter service. Messages sent by services accessing the perimeter service from Service Inventory B will need to be compliant with the new security policy. Because the perimeter service is dedicated to message exchange with services from Service Inventory B, response messages sent by the perimeter service can be designed for compliance to Security Policy B and Security Policy SIB.

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.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.
• D.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.