-
Key: DDSSEC_-27
-
Legacy Issue Number: 19792
-
Status: closed
-
Source: ZettaScale Technology ( Mr. Julien Enoch)
-
Summary:
In §8.4.2.7.1 the PermissionsCredential parameter passed to the validate_local_permissions operation is described as following:
"The nature of the credential is specific to each AccessControl plugin implementation."In §8.4.2.1:
"The specific content of the PermissionsCredential shall be defined by each AccessControl plugin specialization and it may not be used by some AccessControl plugin specializations. The interpretation of the contents as well as the mechanism used to pass it to the AccessControl plugin shall be specified by each plugin implementation."In §9.4.2.1:
"The DDS:Access:PKI-Signed-XML-Permissions plugin shall set the attributes of the PermissionsCredential objects as specified in the table below"So it seems it's up to the AccessControl plugin to create the PermissionsCredential (it's the only one to know how to set/interprate the attributes).
Nevertheless, the middleware is supposed to pass the PermissionsCredential to the validate_local_permissions operation. But it has no way to create or get this PermissionsCredential object.
We suggest to replace this PermissionsCredential parameter with the DomainId and the QoS Policies of the DomainParticipant to validate. Thus, the AccessControl plugin has a way to make distinction between 2 local DomainParticipant to validate their permissions, and can internally create different credentials.
-
Reported: DDS-Security 1.0b1 — Tue, 24 Nov 2009 05:00 GMT
-
Disposition: Duplicate or Merged — DDS-Security 1.0
-
Disposition Summary:
Merged into
DDSSEC_-14This issue was resolved by DDSSEC_14
-
Updated: Tue, 12 Jul 2016 14:45 GMT
DDSSEC_ — PermissionsCredential in validate_local_permissions
- Key: DDSSEC_-27
- OMG Task Force: DDS Security 1.0 FTF 2