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


We decided we needed a top-level intent called 'authorization' to 
indicate that some kind of authorization was needed.  Then we needed 
qualified intents to indicate the type of authorization: fine-grained, 
role-based, id-based.

We thought of leaving the XACML and existing policy assertions as 
examples but realized that none of the other sections had examples of 
how intents may be realized. 

All the best, Ashok


David Booz wrote:
>
> 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.
>
> 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.
> 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
>
> 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?
> 2) usecalleridentity is identity based instead of role based. I have a 
> strong preference for role based mechanisms, such as RunsAs role.
> 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."
>
> Minor comments:
> a) change qualifier names to camelCase
> 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."
>
>
> 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
>
> Inactive hide details for "Rich.Levinson" ---02/06/2009 11:36:22 
> PM---Hello TC, The attached document contains the revised 
> prop"Rich.Levinson" ---02/06/2009 11:36:22 PM---Hello TC, The attached 
> document contains the revised proposed resolution for issue
>
>
> 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]