[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] Issue 57 - proposed text changes
Hi Dave, I hadn't seen this email before the meeting so my responses may have seemed somewhat skewed in relation to your questions. In any event, I will try inline below to address these questions in hopefully a more clear fashion. These responses are not intended to change the proposal, since I don't think that is what is being necessarily requested in any broad sense, so much as to establish a common understanding of the specific features that are being suggested and the wording to use for those features, and to decide separately whether or not to include the features, esp wrt to the "3 additional qualifiers". Thanks, Rich David Booz wrote: OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">I can understand your surprise at the form of the final proposal. It was the result of analysis of sections 7.3-7.7 in the context of trying to perform the 2 actions plus seeing your email which appeared consistent with the concerns I had with the existing text in those sections.Thanks for getting this out in time for the telecon today. I have to say that I'm again surprised at the proposal because it's different from what we discussed at the F2F, and goes much beyond where I thought we were going. I was expecting to see only what you currently call authorization.finegrain and an example with XACML. My initial reaction to the proposal is to go no further than that as the resolution to issue 57. Never-the-less, I have a few questions and comments in case there is interest in pursuing this proposal further. I probably should have explained more in the cover email about the thinking behind it, which I will try to do retroactively now. First, for the authorization intent and the finegrain qualifier, I realized there was no existing textual infrastructure in sections 7.3-7.7, so I decide to insert a new 7.3. and 7.4 to be consistent w 7.1 and 7.2 and push the remaining sections back and deal with them separately for other action item which was to update the example. So, basically, an unseen virtual intermediary step was to insert 7.3, 7.4, and 7.4.1 as they are in the proposal, with section 7.4.1 only containing the finegrain qualifier on the authorization intent. The 2nd action item was to update the example. However, at this point, with the authorization intent and qualifier in place, they raised the question as to the point of the existing example, which suddenly seemed to make no sense with the absence of any intents to give it context. Also the existing example seemed more like it was configuring the component itself, by saying that the component should only accept requests with a given role, which was in contradiction to the concept of an external authorization service performing this function. Therefore, the sensible thing seemed to be to simply remove this example because it no longer reflected in any way the context that had been established by introducing the az intent. At this point, another look was taken at the other notions of securityIdentity, useCallerIdentity, runas "role", authorization/permitAll and authorization/denyAll, and these appeared to make no sense outside the context of intents either. Therefore, rather than try to remove only the expanded example in the previous proposal, which seemed to begin to cascade thru the rest of those sections because of the logic about the distinction between internal component configuration as opposed to container support services for the component, it seemed to make sense to me to try to recast those concepts, into the intent/qualifier model. I admit that I took further encouragement to taking this step of recasting the remaining functions based on your email indicating that you saw problems as well and would not object to removing the section entirely which was the conclusion I had also reached. I tried to explain this concisely (I tend to be a little "wordy" sometimes, and do make attempts scale back the verboseness of communications where the in depth detail does not seem relevant) in the cover email where I mentioned that the proposal was "separable" with the last 3 qualifiers representing a proposed replacement to the removed text (meaning the text remaining in the original 7.3-7.7 after the "disfunctional" authorization example was removed as the proposed resolution to "fixing" the example.) Hopefully that gives better context to the "form" of the proposed resolution, which was to address the 2 specific action items plus "clean up" the situation created by those actions which seemed to imply that now the remaining text would need to be addressed accordingly as well. OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">I think so, yes. One of the background concerns I have about the SCA specifications is the lack of a contextual framework for which the whole intent/PolicySet infrastructure is intended to address.Question: q1) authorization.finegrain - This is an intent that is only satisfied by the presence of a policySet? I think so, but just want to check that. In particular, the notions of policies and policysets floating around the infrastructure is only partially realized in current technology, imo, where it is well established for web services authentication, msg protection, and confidentiality, but much less established in other areas. In today's current technology for authorization it appears to me that in most case the policies are encased in some "central" or "separated" location from the resources they are protecting. This used to be the case with authentication as well, but WS-Security and WS-Policy changed all that. Therefore, the concept of some kind of deployment and administration tool that is resolving component configuration requirements that come thru as annotations or deployment descriptors with some WS-Policy constructs that are going to be attached the same component seems like a fairly straight-forward step to take. However, current authorization policies tend to be very hard baked within authorization services of one sort or another, and have little contextual meaning outside of their evaluation framework. But current trends I believe are changing this situation fairly briskly and I fully expect that meaning authorization policies and policysets will likely begin to be pushed more toward the resources and away from an isolated central evaluation point. In this context, I would say, yes, that policysets representing capabilities of policy evaluation facilities will follow a pattern similar to the authentication space eventually. OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">Again, I think there is a contextual issue about how containers go about providing services in various technical domains. However, I think it is very reasonable to consider an abstract container which provides support for any of these options and will present its capability to provide the option in the form of a policyset that provides the capability that the application deployer is looking for by specifying the qualified intent.q2) Do any of the other intents need policySets to satisfy them or is the container expected to simply implement them? If so, then we need stronger normative guidance OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">I needed a term to represent the opposite notion of "finegrain". Unfortunately, the term "coarsegrain" which is used as its opposite in some contexts is not very widely accepted so I decided to be explicit and simply coin an abbreviation for the explicit representation of the concept. In retrospect now, I think the term "Access Control List" (ACL) also captures the same concept, so I would suggest that as a possible alternative.Major comments: 1) I really don't know what SAR is. The description in the text is brief. Is there an external reference that we can cite here? OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">My perspective is that "role" is generally an attribute or "Principal" of an identity. My sense is that the fundamental requirement is to distinguish between the logged on caller identity which has gained authorization access to the service and the identity under which that service will actually run. i.e. what is really being granted to the caller in this case is to run as the specified identity, however, the caller is not granted the privileges of that identity for anything outside the current context. An analogy would be a person who went a records registry to look at certain records. The clerk would authorize the person to see the requested records but the person does not become the clerk with the privileges to look at anything the clerk has access to.2) usecalleridentity is identity based instead of role based. I have a strong preference for role based mechanisms, such as RunsAs role. OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">My reading of the above comment is that essentially says the same thing as the proposed text. I have no objection to rewording it, however, because this comment is listed under the "major comments" I think I might be missing something.3) propagatecalleridentity - Reword: "the propagatecalleridentity qualifier specifies that if the component invokes other services then it should use the caller identity that it was invoked by as the identity requesting access to those services. The absence of this intent will cause other services to be invoked with the component’s configured container identity." OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">Ok.Minor comments: a) change qualifier names to camelCase OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">Ok, can change it, but I thought that was what it said: the qualifier when specified => "denied unless explicitly permitted", default => " if not explicitly denied, then permitted". However, I agree consistent phrasing would probably be preferable.b) section 7.4.1 - denyaccessbias - second sentence contradicts the first sentence. I think the entire description should read: ")the denyaccessbias qualifier specifies that access should be denied unless explicitly permitted by the authorization policies. In the absence of this qualifier, access will be permitted unless there are specific authorization policies which explicitly deny access." Thanks, Rich OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">Dave Booz STSM, BPM and SCA Architecture Co-Chair OASIS SCA-Policy TC and SCA-J TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |"Rich.Levinson" <rich.levinson@oracle.com> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |"Rich.Levinson" <rich.levinson@oracle.com> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |OASIS Policy <sca-policy@lists.oasis-open.org> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date:. | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |02/06/2009 11:36 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [sca-policy] Issue 57 - proposed text changes | >--------------------------------------------------------------------------------------------------------------------------------------------------| Hello TC, The attached document contains the revised proposed resolution for issue 57 and subsequent actions from the F2F, Action 20090128-1 and Action 20090128-2, plus input from subsequent emails, particularly http://lists.oasis-open.org/archives/sca-policy/200902/msg00007.html The attached document has changes highlighted. Specifically, the changes to consider are all contained in the brand new sections 7.3, 7.4, which are proposed to totally replace what was previously sections 7.3-7.7. These changes also render Action 20090128-1 moot, provide a resolution to 20090128-2, and with the last 3 qualifiers defined in section 7.4 represent an alternative representation of the requirements that appeared to be indicated by the replaced text that I tried to capture in these 3 qualifiers. As such, these last 3 qualifiers represent a "separable section" of the proposal to address the brunt of the above ref'd email that tries to preserve the original needs expressed in the previous text, with structures that conform to the overall SCA-Policy Framework methodology. Thanks, Rich Rich.Levinson wrote: Hi TC, Attached are two files that contain the proposed changes for XACML and fine grain authorization. The first file is from Ashok that shows the changes Ashok recommends for inclusion of XACML policy fragments. The second file is from me and shows the changes I applied to Ashok's proposal to enhance it to include fine grain authorization. Thanks, Rich --------------------------------------------------------------------- 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. (See attached file: sca-policy-1 [1].1-spec-CD01-Rev13e-chgs-accepted-rich-ashok-mods-3.doc) --------------------------------------------------------------------- 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]