[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Issue #54 policy issue instant - was: One more commenton thedelegation/administration profile
I'm not sure that the SAML condition elements directly apply to this use case as I understand it. Assuming you're referring to the "NotBefore" and "NotOnOrAfter" conditions, these seem to be specific to the SAML assertion, and not to the XACML policy payload. I would imagine implementations could be built to extract the SAML timing conditions so as to be utilized in the XACML policy, but without some guidance in the XACML core and perhaps an addition of elements to the SAML-XACML profile, this might lead to inconsistencies. Also, <IssueInstant> could be useful for policy versioning in federated authorization schemes. If in order to settle this issue we decide to use the SAML condition mechanisms, I think the use of SAML as a "transport" should be recommended in the Security and Privacy Considerations | Safeguards section of the core. -----Original Message----- From: Harold Lockhart [mailto:hal.lockhart@oracle.com] Sent: Monday, October 19, 2009 7:24 PM To: Erik Rissanen; XACML TC Subject: [xacml] Issue #54 policy issue instant - was: One more comment on thedelegation/administration profile I held up this issue on the last call because I believe that if we are going to adopt this, we need to first consider several other related points. These are in no particular order: * Presumably what Erik is proposing is that during reduction the PDP would require that the issue instant of an authorized policy fall within the validity interval of the authorizing policy. If this is correct, we need a validity interval for policies (or at least Admin policies). Currently there is no validity interval in policies. If the SAML wrapper is used, it can contain a validity interval. In 2.0, to simplify processing, this is simply checked against the current date/time and the policy included or excluded from the set of policies currently in effect. It seems to me that either a) both validity interval and issue instant should appear in the policy (as well as the SAML wrapper) or b) neither should and use of the SAML wrapper be required to achieve this functionality. * If these values can appear in either the SAML wrapper or the policy itself, we need to deal with the possibility that the values might be different. This is analogous to Issue #86 which dealt with the same problem for Issuer. It that case we agreed that if you used the wrapper, only the value in the wrapper would appear and that the value in the policy can be derived from it. * My biggest concern is that this represents an alteration to the fundamental delagation model agreed to several years ago. When perfoming reduction, there are two sets of properties to be considered: properites pertaining to the content of any policies to be created and properties pertaining to the act of policy creation. When I first considered the model, I initially thought that we would need to duplicate all the existing categories: Subject, Env, Action & Resource to represent the two sets of properties. However on a little reflection I realized that as far as policy creation properties, the Resource would always be the authorized policy the contents of which be completely controled by the sum of the properties pertaining to policy content. Further, it seemed reasonable that the model would assume that all Actions perfoming any sort of write operation (create, modify, delete) would be equally constrained by reduction and that read operations could be neglected (i.e. handled in a different way). Further, there seemed little utility to considering anything other that the Access Subject (issuer) in the context of policy creation peoperties. I did actually contemplate the idea of including Environment Attributes as a part of the properties pertaining to the act of policy creation, but decided the added complexity was not worth the benefits gained. Thus I went along with the consensus that Issuer (policy creation Access Subject) was the only thin we needed to add. In effect Erik has reopened this decision. I believe if we are willing to add in the issue instant, we should logically consider other Environment Attributes. For example, I can easily imagine a user organization wishing to constrain the creation of policies to say, secure terminals located inside a physically secure building. This would mean specifying network location (as in SAML). Perhaps there are other useful Environmental properties as well. If the TC feels that only validity interval checking should be added, so be it, but I think the range of possibilities should be considered. * It seems to me that there is an aspect to this which is similar to Issue #35 - attribute timing. Although the PDP can easily check if currently valid Admin policies have validity intervals which permit a policy to have been created a a point int he past, but it is probalby not possible to determine if the valid policies AT THAT TIME permitted it. * While we are at it, should we consider constraining the validity interval of authorized policies to fall within the validity interval of their quthorizing policies? I am not certain if this is a good idea. I need to think about use case where people change jobs, leave the company, etc. I am not opposed to Erik's suggestion, but I want all the related questions considered. Hal -----Original Message----- From: Erik Rissanen [mailto:erik@axiomatics.com] Sent: Thursday, September 17, 2009 4:55 AM To: XACML TC Subject: [xacml] One more comment on the delegation/administration profile All, I just realized that it would be useful to define an attribute identifier for the issue instant of a policy, so it would be possible to put time constraints on the right to delegate. For instance, let us say that Alice wants to grant a right for Bob to issue policies, but that right should be valid only until the end of 2009. Currently there is no standard attribute identifier for this purpose. I propose that we add the following attribute identifier to the administration profile: --8<-- urn:oasis:names:tc:xacml:3.0:delegate:issue-instant This attribute identifier is used to indicate the moment in time when a policy was issued. It MAY appear in a <PolicyIssuer> element, in which case it MUST be of data type http://www.w3.org/2001/XMLSchema#dateTime. --8<-- Best regards, Erik --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]