Setting ACLs on UDDI v1v2 Structures

For example, user demo_john can save update following businessEntity even if he is not the owner: businessEntity ... ... categoryBag keyedReference tModelKey=uuid:19885bd0-dcf6-11d5-b239-cbbeaea0a8d4 keyName=user keyValue=demo_john ... categoryBag businessEntity Note ACL permissions cannot be set on the bindingTemplate structure because this structure has no categoryBag in UDDI v1v2.

5.2. Publisher-Assigned Keys

Under UDDI v1 and v2, keys are generated automatically when a structure is published. Generated keys in these versions are in form uuid:8-4-4-4-12 where the numbers indicate a count of hexadecimal values. For example, uuid:327A56F0- 3299-4461-BC23-5CD513E95C55 . Note that the prefix uuid: was only used in tModelKeys. In UDDI v3 users may assign keys when saving a structure for the first time. These Keys can be 255 characters long and can contain numbers and Latin characters, so that the key itself describes what the UDDI structure means. For example, the key uddi:systinet.com:uddiRegistry:demo:businessService has the following elements: • The prefix uddi: is a schema much like http: or ftp: and must be always present. • systinet.com is an optional host name. • The elements uddiRegistry, demo, and businessService represent a hierarchy of domains. The domain demo is a subdomain of uddiRegistry. This description is sufficient for our purposes for now. For a more precise description of keys, please see the UDDI v3 Specification [http:uddi.orgpubsuddi-v3.00-published-20020719.htm_Toc42047261].

5.2.1. Generating Keys

The key generator tModel is a tModel with a key in the form domain:keygenerator. This tModel permits its owner to save structures with keys in the form domain:string . For example, the tModel uddi:systinet.com:uddiRegistry:demo:keygenerator allows its owner to publish structures with keys like: • uddi:systinet.com:uddiRegistry:demo:businessService • uddi:systinet.com:uddiRegistry:demo:b52 These are derived keys of the uddi:systinet.com:uddiRegistry:demo domain. With one exception, the key generator tModel does not allow the user to save keys from subdomains such as uddi:systinet.com:uddiRegistry:demo:businessService:exchangeRate , that is, derived keys of uddi:systinet.com:uddiRegistry:demo:businessService . The key generator tModel, however, permits the user to save the key generator for each direct subdomain. For example, the user can save uddi:systinet.com:uddiRegistry:demo:businessService:keygenerator. After creating this Page 209

5.2.1. Generating Keys

second key generator, the user is permitted to save structures with keys of the uddi:systinet.com:uddiRegistry:demo:businessService domain, such as uddi:systinet.com:uddiRegistry:demo:businessService:exchangeRate . Important To generate keys for a domain, the user must own the domains key generator tModel. Only the administrator can save structures with assigned keys without having the key generator tModel. To enable this process for other users, the administrator must save the domains tModel and then change its ownership to the user via custody transfer. For more information, please see Section Publish Custody Transfer .

5.2.2. Affiliations of Registries

The rules above ensure that two users can not create structures with the same key. A complicated situation arises when one user wants to copy UDDI structures from one registry to another while preserving the keys of those structures. There are two problems: 1. The key of the copied structure must not exist on the second registry. The key must be unique - this is required by the UDDI specification. 2. The user must be allowed to save a structure with a specified key on the second registry. The Affiliated registries mechanism solves both problems. An affiliation is a relationship between two registries. The first registry gives up generation of keys for a certain domain and transfers this privilege to the second registry. This ensures that keys from both registries are unique. Note In the examples below we name the two registries master and slave. Moreover there are three people: • The person 1 is an administrator of the master registry, this account is called master-admin. • The person 2 is an administrator of the slave registry account slave-admin and a common user on the master registry account master-user2. • The person 3 is a common user on slave registry account slave-user3 and a common user on master registry account master-user3. Affiliation Setup To set up an affiliation: 1. The administrator of the slave registry slave-admin registers a user account on the master registry master-user2. 2. Master-user2 requests a key generator tModel from the administrator of the Master registry. 3. This administrator, master-admin, creates the key generator tModel and transfers it to the master-user2 account using custody transfer. 4. Person 2 manually copies the key generator tModel to the slave registry his slave-admin account has permission to assign any key and sets up the slave registry to generate all keys based on this key generator. For more information, please see Section 2.7, Node in the Administrators Guide. All keys generated by the slave registry or its users will be from the domain or some subdomain defined by the key generator. Page 210 Affiliation Setup