xacml — archive

[System]

Hi, below is my view on some points (negative auths and null subjects) that have been discussed (i may have lost some comments, there were few msgs going around). for negative authorizations, Hal while i see your concerns i also believe that some of them are due to the fact that you always assume negative authorizations to go with open policy (which was true when negative authorizations were introduced long time ago). this is only one possible policy (that has pros and cons). you want to rule out negative authorizations completely because of some drawbacks they have or that they have in given cases (throwing the baby with the water). best -p HAL: This may be true, but "identity" is an invisible abstraction. What we have to work with is user attributes. Some attributes, such as username or Social Security Number may be assumed to be unique for a certain security domain (or more widely) but that does not eliminate the problem that the attributes may have been suppressed for reasons of policy or that the proper authority was not consulted. If it matters in the access decision, you can distinguish the cases where some values is not known vs the cases where it is known and does not satisfy given conditions (reminds me of the treatment of nulls in databases) BILL: > 2. from a practical standpoint, having 1 identity in 10,000 > be prevented from having access to a resource > requires one negative policy or 9,999 > postive policies. true, also if the negation is to specify some exception, the attribute on which the negation is based may assumed to be known. An example is the case where you give all employees BUT to tempoorary_employees (subset of employees) some access. you can grant the positive authorization to employee and the negative authorization to temporary_employee. If i am a temporary_employee you will know it so if the positive authorization applies to me (because of indirect membership) so does the negative HAL: I always assume a deterministic evaluation algorithm. I think we all agree on this, where by deterministic i consider something that given same input and same status produces same output HAL: Now somebody adds a new operation, say AUDIT, which should logically be treated like READ. Unless somebody adds a new policy it will be allowed. You assume that negative authorizations imply an open world assumption (=traditional open policy). This is not necessarily the case (and it hasd not been in many of the recent work on access control models/systems combining negative and positive authorizations). Also, as another example, the work I presented at the meeting (EU-funded project for protecting european data archive) supported restrictions (which were essentially like negatione) whose semantics was to specify conditions necessary for an access (while positive authorizations are traditionally sufficient conditions for an access). While restrictions reminds of negative authorizations, in no way was the policy of the system ever open. Negations provided in the context more protection. 4. Such and such a policy does not apply to http://www.example.com/my/files/* i will look into it and responde. HAL: > > Later I realized the answer. Positive policies fail closed, negative > > policies fail open. again, not necessarily. It depends on the semantics that you give to negative and positive authorizations. For instance, if your mechanism says that access is allowed if 1) you have positive authorizations and 2) in addition you do not have negation; negative authroizations operate CLOSED in the domain stated by your positive authorizations. HAL: > > If new resources are added (for example) and > > ...... Yes, this is the usual drawback about open policies. POLAR: I think policies such as this should never be formulated without expilicitly defined defaults. Such as: Agree, this is the semantics that you associate with the rules, again, while Hal seems to always consider an open policy when negative authorizations are applied, it need not to be the case. HAL: There is a somewhat arbitrary choice of which inputs to apply to each phase. However, since resources are distributed and control is federated it makes sense to organize them by the resources they apply to, so that they can be located physically close to the resources and their administrators. This suggests that resource and closely related items such as action must always be specified, so it is possible to determine which policies apply. Privilege is something I consider to be completely synthetic and may not necessarily even be present in a policy model at all. For example, the AssureAccess policy model does not currently contain the notion. We map to resources and actions. Privilege, as it is typically used, is actually a target aggregator, in the same way group is a subject aggregator. A priviledge is a shorthand name for some collection of resources and methods that are considered to be similar from an access control perspective. I am not sure i understand these couple of paragraphs. HAL: policy did not consider any information about a subject, there was no need for a subject in the policy. For example, if the policy says the resource can be accessed between 24:00 and 6:00, there is no need to specify a subject. I now believe that this is illogical. I assume that policies can take as inputs items such as the date and time, network location, method of authentication and so on. Therefore, if a policy that does not consider subject information must contain "all subjects" then logically a policy that does not consider time must contain "all times", a policy that does not consider location must contain "all locations" and so on. i think i can agree with you on this. although it seems that whether you call it null or * it's more a matter of terminology. I would be careful with calling it null (null, database field teaches us, may have different semantics and brings consequent confusion). It is true that you can treat that field as ``i do not care'' (which i believe people will not call null), meaning whatever value it has my constraint applies'' (note that this may not be true in case of null value - again, look at the database management field and the treatment of null values). TIM: If a parameter is not included in the policy statement, then it does not have to be considered in the policy evaluation. i can go with that (see my comment above), it's the use of use of the term/value ''null'' that worried me. Hal has specified the semantics in this context only now and it has the semantics of ANY VALUE.