OASIS Ebxml Registry

1OASIS ebXML Registry

2Access Control Related Use Cases

3July 16, 2001

4V 0.5

6Author: Suresh Damodaran

7 Status of this Document 8This document is created to present the access control related use cases in 9OASIS ebXML Registry to OASIS XACML TC to start discussions.

101 Overview 11 12We provide a grossly simplified description of the Registry, followed by the 13information model relevant to security. These should provide enough background 14information on the registry. The use cases follow.

152 Registry Basics 16OASIS ebXML Registry (“the Registry”) supports sharing of information among 17Principals by storing RegistryObjects (XML artifacts, UML diagrams, and in 18general any type of content) in an ebXML Registry and associating each such 19RegistryObject with one or more Classification Schemes. Principals may access 20information about or in1 RegistryObjects by querying the Registry. 21 22Here is a grossly simplified version of the Registry Information Model. For a 23detailed description of the Registry Information Model, see [ebRIM]. 24 25Corresponding to each instance of RegistryObject (the content stored), there is 26an instance of RegistryEntry (metadata related to content). RegistryEntry is 27mapped to one or more ClassificationNodes. This mapping is stored in 28Classification. 29

11 Proposed for V2 (Contend based Query)

2Suresh Damodaran Page 1 4/28/2018 RegistryObject

classifiedObject 1 1 0..* RegistryEntry

0..* Classification

Association

classifiedBy

ClassificationNode

31 Figure 1 Simplified Registry Information Model 32A RegistryEntry may be associated to another RegistryEntry through an 33Association. Association, Classification, and ClassificationNode inherit from 34RegistryEntry.

353 Security View of Registry Information Model [ebRIM, Section 36 12] 37This section describes the aspects of the information model that relate to the 38security features of the Registry. 39 40Figure 2 shows the view of the objects in the Registry from a security 41perspective. It shows object relationships as a UML Class diagram. It does not 42show Class attributes or Class methods that will be described in subsequent 43sections. It is meant to be illustrative not prescriptive. 44

3Suresh Damodaran Page 2 4/28/2018 45 46 Figure 2: Information Model: Security View2

473.1 Interface AccessControlPolicy 48Every RegistryObject is associated with exactly one AccessControlPolicy which 49defines the policy rules that govern access to operations or methods performed 50on that RegistryObject. Such policy rules are defined as a collection of 51Permissions. 52 53 54 55

42 Read “Object” as “RegistryObject”

5Suresh Damodaran Page 3 4/28/2018 Method Summary of AccessControlPolicy Collection getPermissions() Gets the Permissions defined for this AccessControlPolicy. Maps to attribute named permissions. 56

573.2 Interface Permission

58 59The Permission object is used for authorization and access control to 60RegistryObjects in the Registry. The Permissions for a RegistryObject are 61defined in an AccessControlPolicy object. 62 63A Permission object authorizes access to a method in a RegistryObject if the 64requesting Principal has any of the Privileges defined in the Permission. 65See Also: 66 Privilege, AccessControlPolicy 67 Method Summary of Permission String GetMethodName() Gets the method name that is accessible to a Principal with specified Privilege by this Permission. Maps to attribute named methodName. Collection GetPrivileges() Gets the Privileges associated with this Permission. Maps to attribute named privileges. 68

693.3 Interface Privilege

70 71A Privilege object contains zero or more PrivilegeAttributes. A PrivilegeAttribute 72can be a Group, a Role, or an Identity. 73 74A requesting Principal MUST have all of the PrivilegeAttributes specified in a 75Privilege in order to gain access to a method in a protected RegistryObject. 76Permissions defined in the RegistryObject's AccessControlPolicy define the 77Privileges that can authorize access to specific methods. 78 79This mechanism enables the flexibility to have object access control policies that 80are based on any combination of Roles, Identities or Groups. 81See Also: 82 PrivilegeAttribute, Permission 83 84 85 Method Summary of Privilege Collection getPrivilegeAttributes() Gets the PrivilegeAttributes associated with this Privilege.

6Suresh Damodaran Page 4 4/28/2018 Maps to attribute named privilegeAttributes. 86

873.4 Interface PrivilegeAttribute 88All Known Subinterfaces: 89 Group, Identity, Role 90 91PrivilegeAttribute is a common base Class for all types of security attributes that 92are used to grant specific access control privileges to a Principal. A Principal may 93have several different types of PrivilegeAttributes. Specific combination of 94PrivilegeAttributes may be defined as a Privilege object. 95See Also: 96 Principal, Privilege

973.5 Interface Role 98All Superinterfaces: 99 PrivilegeAttribute 100 101A security Role PrivilegeAttribute. For example a hospital may have Roles such 102as Nurse, Doctor, Administrator etc. Roles are used to grant Privileges to 103Principals. For example a Doctor Role may be allowed to write a prescription but 104a Nurse Role may not.

1053.6 Interface Group 106All Superinterfaces: 107 PrivilegeAttribute 108 109A security Group PrivilegeAttribute. A Group is an aggregation of users that may 110have different Roles. For example a hospital may have a Group defined for 111Nurses and Doctors that are participating in a specific clinical trial (e.g. 112AspirinTrial group). Groups are used to grant Privileges to Principals. For 113example the members of the AspirinTrial group may be allowed to write a 114prescription for Aspirin (even though Nurse Role as a rule may not be allowed to 115write prescriptions).

1163.7 Interface Identity 117All Superinterfaces: 118 PrivilegeAttribute 119 120A security Identity PrivilegeAttribute. This is typically used to identify a person, an 121organization, or software service. Identity attribute may be in the form of a digital 122certificate.

1233.8 Interface Principal

124 125Principal is a completely generic term used by the security community to include 126both people and software systems. The Principal object is an entity that has a set 127of PrivilegeAttributes. These PrivilegeAttributes include at least one identity, and

7Suresh Damodaran Page 5 4/28/2018 128optionally a set of role memberships, group memberships or security clearances. 129A principal is used to authenticate a requestor and to authorize the requested 130action based on the PrivilegeAttributes associated with the Principal. 131See Also: 132 PrivilegeAttributes, Privilege, Permission 133 Method Summary of Principal Collection getGroups() Gets the Groups associated with this Principal. Maps to attribute named groups. Collection getIdentities() Gets the Identities associated with this Principal. Maps to attribute named identities. Collection getRoles() Gets the Roles associated with this Principal. Maps to attribute named roles.

1344 Roles and Default Access Control Policy [ebRS, Section 9.4] 135There are predefined roles for Registry Users. There are also default access 136control policies for each RegistryObject. 137

1384.1.1 Pre-defined Roles For Registry Users 139The following roles must be pre-defined in the Registry: Role Description The submitter or owner of a Registry content. Submitting ContentOwner Organization (SO) in ISO 11179 A “super” user that is an administrator of the Registry. RegistryAdministrator Registration Authority (RA) in ISO 11179 Any unauthenticated user of the Registry. Clients that RegistryGuest browse the Registry do not need to be authenticated.

1404.1.2 Default Access Control Policies 141The Registry must create a default AccessControlPolicy object that grants the 142default permissions to Registry users based upon their assigned role. 143The following table defines the Permissions granted by the Registry to the 144various pre-defined roles for Registry users based upon the default 145AccessControlPolicy. 146 Role Permissions Access to all methods on Registry Objects that are ContentOwner owned by the ContentOwner.

8Suresh Damodaran Page 6 4/28/2018 RegistryAdministrator Access to all methods on all Registry Objects Access to all read-only (getXXX) methods on all Registry RegistryGuest Objects (read-only access to all content). 147 148The following list summarizes the default role-based AccessControlPolicy: 149  The Registry must implement the default AccessControlPolicy and 150 associate it with all Objects in the Registry 151  Anyone can publish content, but needs to be authenticated 152  Anyone can access the content without requiring authentication 153  The ContentOwner has access to all methods for Registry Objects owned 154 by them 155  The RegistryAdministrator has access to all methods on all Registry 156 Objects 157  Unauthenticated clients can access all read-only (getXXX) methods 158  At the time of content submission, the Registry must assign the default 159 ContentOwner role to the Submitting Organization (SO) as authenticated 160 by the credentials in the submission message. In the current version of 161 this specification, it will be the DN as identified by the certificate 162Clients that browse the Registry need not use certificates. The Registry must 163assign the default RegistryGuest role to such clients. 164There is a predefined access control policy associated with each RegistryObject.

1655 Use Cases

1665.1 Restricting Read-Only Access 167A Submitting Organization (SO) submits a RegistryObject to a Registry. SO also 168submits an AccessControlPolicy associated with a RegistryObject. This 169AccessControlPolicy allows only selected partners of SO to have read-only 170access to the RegistryObject. All objects in the registry have a unique id specified 171by Universally Unique Identifier (UUID) and must conform to the format of a URN 172that specifies a DCE 128 bit UUID as specified in UUID [ebRS:Section 7.3.1, 173UUDI].The partners (Principal) may be specified in the AccessControlPolicy 174using Identity, Role, or Group of Users in Organizations (see Section 3). It is 175assumed that the partner information is available through Organization for all 176authenticated Users. Partner may also be a RegistryGuest.

1775.2 Write-Access beyond the Owner 178A Submitting Organization (SO) submits a RegistryObject to a Registry. SO also 179submits an AccessControlPolicy associated with a RegistryObject. This 180AccessControlPolicy allows write (modify/deprecate/delete) access to some of 181the partners of SO. All objects in the registry have a unique id specified by 182Universally Unique Identifier (UUID) and must conform to the format of a URN 183that specifies a DCE 128 bit UUID as specified in UUID [ebRS:Section 7.3.1, 184UUDI].The partners (Principals) may be specified in the AccessControlPolicy 185using Identity, Role, or Group (see Section 3). It is assumed that the partner

9Suresh Damodaran Page 7 4/28/2018 186information is available as Organization (is a RegistryEntry) for all authenticated 187Users.

1886 Issues 189Some of the issues are below. Most of these are for ebXML Registry TC, though 190some might be interesting to XACML. 1911. The relationship between the security information model and RIM is not 192 specified now. E.g., 193 a. Can an AccessControlPolicy be a RegistryEntry? What would be the 194 AccessControlPolicy for such a RegistryEntry? 195 b. What are the rights of RegistryAdministrator on the 196 AccessControlPolicy? 1972. Should AccessControlPolicy .dtd/schema be integrated with 198 Registry.dtd/schema? If so how? 1993. What are the bindings for accessing AccessControlPolicy? What is the 200 mechanism of enforcement? 2014. How do the RegistryObjects share an AccessControlPolicy? 2025. Can Roles/Groups be defined dynamically? If so what are implications on 203 AccessControlPolicy? 2046. “For every object, the access controller will iterate through all the 205 AccessControlPolicy objects with the object and see if there is a chain 206 through the permission objects to verify that the requested method is 207 permitted for the Principal. If any of the permission objects which the object is 208 associated with has a common role, or identity, or group with the principal, 209 the action is permitted [ebRS: Appendix E2]” Overprescription? 210

2117 References 212[FNPRO1] Proposal for Authorization Policy Administration 213 http://lists.oasis-open.org/archives/regrep/200107/msg00005.html 214[ebRS] ebXML Registry Services Specification 215 http://www.ebxml.org/specs/ebRS.pdf 216[ebRIM] ebXML Registry Information Model 1.0 217 http://www.ebxml.org/specs/ebRIM.pdf 218[UUID] DCE 128 bit Universal Unique Identifier 219 http://www.opengroup.org/onlinepubs/009629399/apdxa.htm#tagcjh_20 220http://www.opengroup.org/publications/catalog/c706.htmttp://www.w3.org/TR/RE 221 C-xml 222

10Suresh Damodaran Page 8 4/28/2018