[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] URN changes for DLP-NAC
Hi John, On 27/06/2014 7:15 AM, Tolbert, John W wrote:
Hello, Please ignore the incorrect numbering. Based on Hal’s discussion today about the DLP-NAC profile, I changed the urn’s to be consistent with the list of identifiers in the core. Please let me know if this is better, and we’ll incorporate it into WD-08 (still looking for help generating sample policies for section 4.2). Thanks ** *1.**Recipient-Subject-ID*** This identifier indicates the entity that will receive the results of the request, which may include user identifiers, machine identifiers, and/or application identifiers. Subject-ID classification values shall be designated with the following attribute identifier: urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject:recipient-subject-id The DataType of this attribute is http://www.w3.org/2001/XMLSchema#string.
I take it that it is still the intention that this attribute is an attribute of the access-subject. I would have used the recipient-subject category instead to hold attributes pertaining to the recipient. It saves defining new attributes that just duplicate attributes already available to the recipient-subject category. For instance, this attribute is just the subject-id of the recipient-subject. Within a policy it is just as easy to designate the subject-id attribute in the recipient-subject category as it is to designate the recipient-subject-id attribute in the access-subject category. Users of the profile could also make use of other attributes in the recipient-subject category that are already defined in the core or other profiles without first needing to (or thinking they need to) define private access-subject versions of them. Similar considerations apply to the remaining attributes.
*1.1.1 **Recipient-Subject-ID-Qualifier*** This identifier indicates the security domain of the recipient subject. It identifies the administrator and */policy /*that manages the name-space in which the */recipient-subject /*id is administered. Subject-ID-Qualifier classification values shall be designated with the following attribute identifier: urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject:recipient-subject-id-qualifier The DataType of this attribute is http://www.w3.org/2001/XMLSchema#string.
I'd define this as a new recipient-subject attribute under a different name, since it doesn't appear to serve the same purpose as the subject-id-qualifier in the core.
*1.1.2 **Requesting-Machine*** This identifier indicates the address of the machine from which the access request originated. Requesting-machine classification values shall be designated with the following attribute identifier. urn:oasis:names:tc:xacml:1.0:subject:requesting-machine The following DataTypes can be used with this attribute: urn:oasis:names:tc:xacml:3.0:data-type:ipAddress-value and urn:oasis:names:tc:xacml:3.0:data-type:dnsName-value. For Media Access Control (MAC) addresses, use http://www.w3.org/2001/XMLSchema#string.
It seems like you could use the subject-id attribute in the requesting-machine category in place of this attribute.
*1.1.3 **Recipient-Machine*** This identifier indicates the address of the machine(s) to which the access will be granted. Recipient-machine classification values shall be designated with the following attribute identifier. urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine:recipient-machine The following DataTypes can be used with this attribute: urn:oasis:names:tc:xacml:3.0:data-type:ipAddress-value and urn:oasis:names:tc:xacml:3.0:data-type:dnsName-value. The attribute value may include full paths including volume names, where applicable. For Media Access Control (MAC) addresses, use http://www.w3.org/2001/XMLSchema#string. The attribute may take multiple values.
I'd either use a related entity to represent a recipient machine or define a new category for recipient machine and let it have all the same attributes as a requesting-machine. This attribute would be the subject-id of the recipient-machine entity/category.
*1.1.4 **Recipient-removable-media*** This identifier indicates whether or not the destination of the action is a removable media device. Recipient-removable-media classification values shall be designated with the following attribute identifier. urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine:recipient-removable-media The DataType of this attribute is http://www.w3.org/2001/XMLSchema#boolean.
I'd make this an attribute of the recipient-machine entity/category. From the perspective of the entities profile, the above attributes are examples of attribute flattening.
*1.2 **Codebase Attributes*** *2.4.1 Authorized-Application*** This identifier indicates whether or not the requesting application is approved for the actions requested. urn:oasis:names:tc:xacml:3.0:subject-category:codebase:authorized-application The DataType of this attribute is http://www.w3.org/2001/XMLSchema#boolean.
This attribute is in the right place. Regards, Steven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]