DDS-SECURITY 1.3b1 RTF Avatar
  1. OMG Issue

DDSSEC13 — Builtin Auth dependency on Access Control details

  • Key: DDSSEC13-72
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    (This may be a moot point depending on the resolution of DDSSEC12-13.)

    The row of Table 52 that describes validate_local_identity states that the QoS it receives must contain the properties defined in section 9.3.1. These properties are the ones starting with dds.sec.auth.

    The problem is that for begin_handshake_* (either variant) to work, validate_local_identity must also receive the property dds.sec.access.permissions. This should be noted in the requirements for validate_local_identity: it must store the QoS, or at least this property, in a location that can be looked up by IdentityHandle so that handshake tokens can be created. Alternatively, the begin_handshake_* operations could be extended to receive this info separately.

    Another connection between the two plugins is made by the PermissionsCredentialToken. If the intent is to use this data when generating handshake handles, that should be noted in tables 49-50 (c.perm) instead of referencing QoS policies there.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 23 Jul 2018 16:19 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT