Managing the private UDDI

This section describes how to administer the private UDDI server from the Web console.

Once connected to the private UDDI server, you see three folders:

• Administration – contains the Registry and Security Administration folders, from which you can administer the private UDDI server. See “Administering the private UDDI”.

• Search – allows you to search the private UDDI repository for specific information based on your input. See “Inquiries and searches”.

• Publish – allows you to publish information about your business, Web service tModel, and so on, to the private UDDI repository. See “Publishing”.

Administering the private UDDI

Private UDDI administration consists of:

• Changing the connection cache – allows you to change connection caches, which allows you to use another database as the private UDDI repository.

• Initializing the database – this option is available from the Connection Cache property sheet, and appears only if the database being used as the repository has not been initialized.

• Controlling access to resources – map private UDDI repository roles to EAServer roles to control which users can query, search, and administer the private UDDI registry.

Changing the connection cache

1. Connect to the private UDDI registry.

2. Right-click the Registry Administration folder and select Configure Connection Cache.

3. Follow the instructions in the Configure Connection Cache wizard to change the connection cache. You can select only a connection cache that is already defined in the EAServer to which you are connected.

Initializing the repository database

If the database has not been initialized, follow this procedure to create the tables within the database that are required by the UDDI server.

1. Connect to the private UDDI registry.

2. Highlight the Registry Administration folder.

   You see the status of the database; true - the database is initialized, or false - the database has not been initialized.

3. If false, select Initialize Database.

   To start the initialized database run either uddidb.bat (Windows) or uddidb.sh (UNIX).

Controlling access to resources

You can implement a flexible authorization policy using roles. Membership in a role determines the level of authoriization for a given user. There are three roles that are predefined as Web application roles and used for the private UDDI server:

• UddiInquire role – members can search and query the UDDI registry. By default, UDDI does not require the user to be authenticated to search the UDDI server. However, you might not want to do this in a production environment. So, by mapping this role appropriately in a publish or aadministration capacity authentication and authorization can be explicitly enforced by the container.

• UddiPublish role – members can publish information to and query from the UDDI registry. Members of this role can modify or delete only information that they have published.

• UddiAdmin role – members can modify or delete any information published in the UDDI registry. In addition, members of this role have publish and query privileges, and can add, modify, and delete configuration parameters.

You can map these roles to any EAServer role to enforce the desired authorization policy. See Chapter 3, “Using Web Application Security,” in the EAServer Security Administration and Programming Guide for information about roles and role mapping.In a development environment, you might want to map the UddiAdmin role to EAServer’s Admin role, and map the other two roles to “everyone.” In this case, any authenticated user is considered a member of the role and can publish and query. Only the jagadmin user can modify published data and UDDI configuration settings.

The default security policy permits unauthenticated users to query the UDDI registry. However, you can modify the policy by defining the UddiInquire role for the Web application.

Mapping UDDI registry roles

1. Connect to the private UDDI server (UDDI on localhost).

2. Expand the Administration folder.

3. Highlight the Security Administration folder. The UDDI registry roles display in the right pane.

4. Each role is mapped to an EAServer role. To change the role mapping, select an EAServer role from the drop-down list to which you want to map the UDDI role. Click Apply to apply the changes.

Using security constraints

In addition to using roles to enforce security, you can use secure transport connections when publishing information to the UDDI server. By setting the appropriate security constraints for the private UDDI Web application, the EAServer Web container enforces HTTPS access for publish only.

See Chapter 3, “Using Web Application Security,” in the EAServer Security Administration and Programming Guide for information about establishing security constraints.

Copyright © 2005. Sybase Inc. All rights reserved.