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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-security message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Access control use cases

Title: RE: ebXML Security subteam
Here is the use case that I am planning to submit to XACML COB today.
Please comment.
Some  issues:
1. How do we attach an access control policy for submitting a new RegistryObject?
Should we allow all Submitting Organizations to submit RegistryObjects? In the use case,
I have not mentioned "submit" operation in teh use case attached.
2. If "submit" is used to "save/update" a RegistryObject, then the access control requirements
will de different while creating a new RegistryObject vs. updating an already existing one. For
a new RO, we use whatever we comeup with (1) above, and for the existing, we create a "update"
operation. Creating a new operation is a problem for Object Management Service? There must be
some reason why update was not considered an operation?
3. I have not created Roles in the use case, though we need to have it for ourselves.
-----Original Message-----
From: Damodaran, Suresh
Sent: Tuesday, August 28, 2001 10:05 AM
To: 'regrep-security@lists.oasis-open.org'; 'sekhar.vajjhala@Sun.COM'
Subject: Access control use cases

Farrukh, Sanjay, thanks for your comments on the access control ops.
Let me take it further. Please comment.
The things that need to be done to complete the access control usecase
1. Enumerate the resources (in our case object types) that we want access control on
    Farrukh, you may be able to talk about how RIM changes will impact this.
2. Identify the actions on these resources :
    There is consensus that we tackle
        -life cycle operations
        - read operation
        - update operation
    for V2.
3. Map to "Roles" or "Groups" the security actors (btw, mapping the security actors
to mainstream registry actors is an issue). As an example, Registry Publisher is an
unambiguous actor from the security point of view (i.e., we cannot confuse
a Registry Guest from a Registry Publisher) [Farrukh had mentioned that Registry Guest
can also publish in the registry - in that case we can't make any distinction! - my thinking
is that we we separate roles as we fit now, and later combine the roles - comments?]
4. Think of any preconditions for access as well as any post conditions that need to be
satisfied after the access.
Sanjay, I am hoping that the usecases for access that you are working can be expanded
along these lines. If you take some preliminary steps along these lines, it should help us.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC