OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

[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">
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 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.

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">
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.
  
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.

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">
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
  
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.
OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">
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?
  
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.
OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">
2) usecalleridentity is identity based instead of role based.  I have a
strong preference for role based mechanisms, such as RunsAs role.
  
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.
OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">
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."
  
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.
OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">
Minor comments:
a) change qualifier names to camelCase
  
Ok.
OF46FA70AA.0A81BF7C-ON85257558.00473B5D-85257558.004A6091@us.ibm.com" type="cite">
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."
  
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.

    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

  

--------------------------------------------------------------------- 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]