Given that we have a "not" operator and also a DenyOverrides combining algorithm, we have to be VERY careful about simply converting Indeterminate results to False. The rule of thumb in the security community is that "lack of information should NEVER result in increased privileges." This means that we can't just convert "indeterminate" to false if the result would have been different were the value not "indeterminate". Example 1: <rule Effect="Deny"> <condition> <or> Request/Subject/SubjectId = "A. Bad Hacker" Request/Subject/Attribute/Role = "KnownBadHacker" </or> </condition> </rule> Assume the Request SubjectId is "Another Bad Hacker", and this requester has been issued a Role attribute with the value "KnownBadHacker". Assume this nefarious character causes a temporary network outage, resulting in temporary unavailability of the Role attribute. If we return FALSE from <or> of a FALSE and an INDETERMINATE, then the rule will return "notApplicable". If the Role attribute had been available, however, the result would have been Deny. This represents an increased privilege due to lack of information. Example 2: <rule Effect="Permit"> <condition> <not> <or> Request/Subject/SubjectId = "A. Bad Hacker" Request/Subject/Attribute/Role = "KnownBadHacker" </or> </not> </condition> </rule> Once again, assume the Request SubjectId is "Another Bad Hacker", and this requester has been issued a Role attribute with the value "KnownBadHacker". Assume this nefarious character causes a temporary network outage, resulting in temporary unavailability of the Role attribute. If we return FALSE from <or> of a FALSE and an INDETERMINATE, then the rule will return "Permit". If the Role attribute had been available, however, the result would have been "not applicable". This represents an increased privilege due to lack of information. Anne -- Anne H. Anderson Email:
Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692