Gaps in Testing

The tool is currently aligned with version 1.22.1 of the Redfish Specification. The following sections are not covered by testing with this tool.

• 6 Protocol details

  • A Redfish interface shall be exposed through a web service endpoint implemented by using HTTP version 1.1.

• 6.1 Universal Resource Identifiers

  • A URI shall identify each unique instance of a resource.
    • Not sure how to test this. This may be covered just by running the service validator.
  • The resource path component part shall be unique.
    • Not sure how to test this. This may be covered just by running the service validator.

• 6.5 ETags

  • The @odata.etag property of each resource in the $expand response shall contain the ETag of the resource as if it were not expanded.

• 6.6 Protocol version

  • Any resource that a client discovers through hyperlinks that the service root or any service root-referenced service or resource returns shall conform to the same protocol version that the service root supports.
    • May not be testable or really relevant.

• 7.2.1 GET (read requests) overview

  • The service shall return the resource representation using one of the media types listed in the Accept header, subject to the requirements of the media types.
    • This might be covered by other tests around usage of Content-Type.
  • The HTTP GET operation shall retrieve a resource without causing any side effects.
    • Not sure how to test this.
  • The GET operation shall be idempotent in the absence of outside changes to the resource.
    • Not sure how to test this.

• 7.2.2 Resource collection requests

  • If a service pages a response to a resource collection request, the following rules shall apply: (list of rules)

• 7.3.1 Query parameter overview

  • Shall only support query parameters on GET operations.
  • Shall use the & operator to separate multiple query parameters in a single request.
  • Services shall process query parameters in this order: (list of query parameters)
  • OEM-defined query parameter names shall not contain characters that conflict with syntax for query parameter parsing, such as &.
    • Not sure how to discover and enforce OEM naming.
  • OEM-defined query parameters shall be in the form OEM--
    • Not sure how to discover and enforce OEM naming.

• 7.3.2 The $expand query parameter

  • Entire section not tested.

• 7.3.3 The $select query parameter

  • Entire section not tested.

• 7.3.4 The $filter query parameter

  • Entire section not tested.

• 7.4 HEAD

  • Services shall not support any other use of the HEAD method.
    • Not sure how to test this.
  • The HEAD method shall be idempotent in the absence of outside changes to the resource.
    • Not sure how to test this.
  • Services shall reject HEAD requests that contain query parameters.

• 7.6 PATCH (update)

  • To update a resource's properties, the service shall support the PATCH method.
    • This may be implicitly tested with other tests.
  • The service shall ignore OData annotations in the request body, such as the resource identifier, type, and ETag properties, except for the conditions listed below.

• 7.11 POST (action)

  • Entire section not tested.

• 7.12 Operation apply time

  • Entire section not tested.

• 7.13 Deep operations

  • Entire section not tested.

• 8.1 Response headers

  • If a service does not support Transfer-Encoding and needs Content-Length instead, the service shall respond with the HTTP 411 Length Required status code.
  • Services shall specify a Content-Type of application/yaml or application/vnd.oai.openapi when returning OpenAPI schema as YAML.
  • ;charset=utf-8 shall be appended to the Content-Type if specified in the chosen media-type in the Accept header for the request.

• 9 Data model

  • Deeper review needed.
  • Mostly covered by the service validator, but there might be some functional things to test like the settings resource.

• 12.1 Eventing

  • Might be better for a use case checker.
  • May want to review some the existing tests.

• 12.2 Asynchronous operations

  • Entire section not tested.

• 12.3 Resource tree stability

  • Entire section not tested.
  • Might not be practical.

• 12.5 Server-sent events

  • Might be better for a use case checker.
  • May want to review some the existing tests.

• 12.6 Update service

  • Entire section not tested.
  • Might be better for a use case checker.

• 12.7 Outbound connections

  • Entire section not tested.

• 13.1.2 Cipher suites

  • Implementations shall only support cipher suites listed as "Recommended" in the TLS Cipher Suites table defined by the IANA TLS Parameters registry.
  • Cipher suites that are listed as mandatory in various RFCs, but are not "Recommended" in the TLS Cipher Suites table defined by the IANA TLS Parameters registry, shall not be supported.

• 13.3.1 Authentication overview

  • Shall use only connections that conform to TLS to transport the data between any third-party authentication service and clients.

• 13.3.3 HTTP Basic authentication

  • When multi-factor authentication is enabled, services shall reject HTTP Basic authentication for accounts that are not configured to bypass multi-factor authentication.
  • When a multi-factor authentication type that requires tokens is enabled, services shall require the Token property in the POST request to the SessionCollection resource for accounts that are not configured to bypass multi-factor authentication.
  • The service shall verify the provided token in addition to verifying the username and password.
  • If the Token property is required and not provided by the client, but the client provided a valid UserName and Password combination, the service shall return the HTTP 401 Unauthorized status code with the AuthenticationTokenRequired message from the Base Message Registry.
  • In addition, if the multi-factor authentication type uses a service-generated one-time passcode, the service shall also return the OneTimePasscodeSent message from the Base Message Registry, and send a one-time passcode to the configured delivery address for that account.

• 13.3.5 Client certificate authentication

  • Entire section not tested.

• 13.4 Authorization

  • Mostly untested.
  • Some role tests exist.

• 13.5.5 Time-based One-Time Password secret key handling

  • Entire section not tested.

• 13.6.3 Atomic password changes

  • If the RequireChangePasswordAction property in the AccountService resource contains true , services shall reject modifications to the Password property in ManagerAccount resources in PATCH or PUT operations.
  • If a user is changing their own password, the SessionAccountPassword parameter shall contain the current password of the account.
  • If an administrator is performing the password change for a different user, the SessionAccountPassword parameter shall contain the administrator's password.

• 13.6.4 Password change required handling

  • Resources that have the property set to true shall require the user to change the write-only Password property in that resource before access is granted. • A POST operation on the ChangePassword action on the ManagerAccount resource associated with the account to update the Password property. If the value of Password is changed, the service shall also set the PasswordChangeRequired property to false.
  • A DELETE operation on Session resources representing open sessions associated with the account.

• 13.7 Asynchronous tasks

  • Entire section not tested.

• 13.8 Event subscriptions

  • Entire section not tested.

• 14 Redfish host interface

  • Entire section not tested.

• 15 Redfish composability

  • Entire section not tested.

• 16 Aggregation

  • Entire section not tested.

• To remove/update

  • SEC_TLS_1_1 (1.1 deprecated; need to follow newer requirements for TLS 1.2)
  • SEC_PWD_CHANGE_REQ_ALLOW_PATCH_PASSWORD (need to test in conjunction with RequireChangePasswordAction)