Re: [regrep] XACML and Access Control Policy

[Matthew MacKenzie <matt@mac-kenzie.net>]

Initially, it appears that verbiage will need to be added somewhere 
(Farrukh can indicate where) to require the policy module to be 
contacted prior to each operation in the registry to verify the 
requester's permission to access an object/item.  I don't think that 
there will be too many locations in the spec that are touched, but 
policy checking based on XACML will become a pervasive, overarching 
requirement, probably with its own section.

The XACML expert(s) (Suresh?) should verify this, the understanding 
being that XACML is basically a policy format, instance(s) of which 
ebXML Registry would use to decide who and what may perform various 
actions.

-Matt

On Tuesday, January 7, 2003, at 02:42  PM, Breininger, Kathryn R wrote:

> Sounds like this should be the first agenda item.  Do you anticipate 
> other sections of the specs changing as a result?  If the second 
> agenda item is reviewing the current changes, are there sections that 
> will be affected by this proposal that we should skip in our spec 
> review?
>
> -----Original Message-----
> From: Matthew MacKenzie [mailto:matt@mac-kenzie.net]
> Sent: Monday, January 06, 2003 8:09 PM
> To: Farrukh Najmi
> Cc: Damodaran, Suresh; regrep@lists.oasis-open.org
> Subject: Re: [regrep] XACML and Access Control Policy
>
>
> I would help on this one.  I see it as important.
>
> -Matt
>
> On Monday, Jan 6, 2003, at 17:03 America/Vancouver, Farrukh Najmi 
> wrote:
>
>> Suresh,
>>
>> XACML based custom access control policy was planned for V3 and is in
>> fact the only task that was planned for V3 that we have not addressed
>> for V3. The task was dropped for two reasons:
>>
>> -XACML was a moving target
>>
>> -We had no one signed up for the task
>>
>> Given that XACML is now a month away from becoming the next OASIS
>> approved standard ( I believe it will get approved) and given that you
>> are offering to take ownership of the, I completely agree with your
>> suggestion that we should do it for V3.
>>
>> My experience with several strategic ebXML Registry pilots using the
>> ebxmlrr project has shown that this is a *MUST* feature for V3. In
>> fact the ebxmlrr project has been implementing XACML based custom ACP
>> as a implementation specific feature already. The experience further
>> suggests that XACML is ready for building our specs on top of and that
>> we *SHOULD* do custom ACP for V3 based on XACML.
>>
>> I believe we could accommodate the increase in scope with about 1
>> month slip to our V3 schedule. I think that the benefit of having this
>> strategic feature far outweighs the cost of the delay to V3 schedule.
>>
>> I would be very willing to help you with this task. Maybe Sanjay could
>> help as well (Sanjay?) and we could get our security sub-team charged
>> up for V3.
>>
>> Kathryn, I propose we add this issue to this week's TC con-call.
>>
>> --  
>> Regards,
>> Farrukh
>>
>>
>>
>> Damodaran, Suresh wrote:
>>
>>> Hi all,
>>>
>>> It would be great to have XACML based custom access control policy
>>> for V3. Is this something we are considering for V3?
>>>
>>> I may even volunteer sometime:-)
>>>
>>> Best regards,
>>>
>>> -Suresh
>>> Sterling Commerce (on loan to RosettaNet)
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Farrukh Najmi [mailto:farrukh.najmi@sun.com]
>>> Sent: Thursday, January 02, 2003 9:00 AM
>>> To: regrep@lists.oasis-open.org
>>> Subject: [regrep] ebRIM and ebRS 2.33 distribution
>>>
>>>
>>>
>>> Team,
>>>
>>> Happy new year to all of you.
>>>
>>> The ebRIM and ebRS 2.33 specifications may be downloaded respectively
>>> from:
>>>
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> doc/ebRI
>>> M.doc?rev=1.10&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> doc/ebRS
>>> .doc?rev=1.9&content-type=text/vnd.viewcvs-markup
>>>
>>> Thanks to Nikola, Matt, Suresh, Monica and Sanjay for their
>>> contributions to this version.
>>>
>>> Please review this version of the specifications and be prepared to
>>> discuss the changes during our TC meeting on January 9th 2003.
>>>
>>> The changes to the documents were driven by the Action Items List,
>>> the latest version of which is
>>> found at:
>>>
>>> http://ebxmlrr.sourceforge.net/ebxmlrr-spec/specActionItems.htm
>>>
>>> Good news is that we have closed most of the Action Items on the
>>> actual specification documents in version 2.33!
>>>
>>>
>>> The latest XML Schema files may be found at:
>>>
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/rim.xsd?rev=1.10&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/query.xsd?rev=1.7&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/rs.xsd?rev=1.11&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/federation.xsd?rev=1.7&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/event.xsd?rev=1.4&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/contentManagementServices.xsd?rev=1.2&content-type=text/
>>> vnd.viewcvs-m
>>> arkup
>>>
>>>
>>> Changes in RS 2.33
>>> ------------------
>>>
>>> -Updated Contributors list for Joe's affiliation change.
>>>
>>> -Updated figure 4 in section 6.3 for HTTP binding
>>>
>>> -Updated 6.6.4, 6.9.1 and 6.9.2 for SignatureList. Now defines how
>>> signed request/responses are
>>> handled by HTTP binding.
>>>
>>> -Fixed UpdateObjectRequest semantics to only allow updates and not
>>> allow new submisison per Nikola's suggetsion.
>>> Fixed 7.4.1.2 appropriately.
>>>
>>> -Added UndeprecateObjects protocol in section 7.9
>>>
>>> -Specified in 9.10 that repositoryItem input is specified via a
>>> $repositoryItem variable.
>>>
>>> -Updated chapter 10 (event Notification) and corresponding schema
>>> after design review with following changes:
>>>    -Now uses base type AdhocQuery in Selector instead of choice
>>> between FilterQuery and SQLQeury
>>>    -Now only supports 2 notificationOptions (ObjectRefs and Objects)
>>>    -Now allows multiple EmailAddresses and Services in
>>> NotificationAction sub-types
>>>    -NotificationType no longer abstract
>>>    -Notification element defined to allow the simplest Notifications
>>> (used in Object Relocation)
>>>    -Notification is now a RegistryResponseType
>>>    -Removed GetNotificationResponse as it is replaced by
>>> NotificationType.     -Updated section 11.4 Object Relocation as
>>> follows:
>>>    -Now uses AdhocQuery to select objects being relocated.
>>>    -Decided that Object Import/Export was not adequate alone and that
>>> an Object relocation protocol was still needed.
>>>    -Updated fig 70 sequence diagram to show use of EVent Notification
>>>    --Updated fig 70 sequence diagram to show use AdhocQueryRequest
>>>    -Updated  11.4.5 and 11.4.6 to spec how notifications are used for
>>> Object Relocation protocol.
>>> -Updated chapter 12 and appendix F to clarify that User that submits
>>> content is the owner of the content.
>>>
>>> -Removed RegistryProfile from appendix and rs.xsd and merged
>>> attributes into Registry class.
>>> The registry class replaces all prior functionality of the
>>> RegistryProfile element.
>>>
>>> -Updated appendix E2 SQL BNF to use hyperlinks
>>>
>>> -Updated Appendix C for Canonical ClassificationSchemes and their
>>> proposed locations.
>>>
>>> Changes in RIM 2.33
>>> -------------------
>>>
>>>
>>> -Updated Contributors list for Joe's affiliation change.
>>>
>>> -Updated chapter 11 Event Notification for design changes in Event
>>> Notification itemized in RS changes above.
>>>
>>> -Updated 12.1.1 and sub-sections to add missing attributes to
>>> Registry class.
>>>
>>> -Updated figure 2 Registry Object Inheritence View in chapter 7 to
>>> add Subscription, Registry and Federation classes
>>>
>>> Looking forward to your comments on the January 9th TC meeting.
>>>
>>>
>>
>>
>>
>>
>> ----------------------------------------------------------------
>> To subscribe or unsubscribe from this elist use the subscription
>> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>