Papyrus Model Repository Administration

The previous article in this series, like so many before it, was all about features for end-users working collaboratively on models in Papyrus with CDO. Today, we turn our attention to the administrative user, that individual who is reponsible for providing the resources that everybody else needs to do their work.

Today's M3 milestone of the Luna release of CDO and Papyrus adds several new enhancements targeting primarily administrative users.

Password Management

In the Kepler release, CDO introduced a new security manager driven by a model of users, roles, and permissions. User identities and credentials are managed in the security model, although passwords are never exposed to clients. Nobody, not even the Administrator, has access to them. Authentication of user passwords is established by a server-initiated challenge to which the client replies an encrypted password response using a key determined by a secure key-agreement protocol.

The Luna M3 milestone adds two new password management functions:

• change password: on any manifestation of a CDO session (in the CDO Sessions view or a connected repository in the Papyrus Model Repositories view) that has a logged-in user ID, a new Change Password action lets the user change its password in the usual way. Note that repositories are not required to have a security manager installed; in these cases, there are no user IDs, so this action is not available
• reset password: in the case that a user has forgotten its password, an Administrator can invoke a new action in the security model editor to reset the user's password. A randomly generated new password is presented to the Administrator to share with the user

Security Model Editor

The standard reflective tree editor is sufficient for managing the security model, but it isn't as efficient as it might be for the most common (80% rule) use cases. Lots of right-clicking and jumping back and forth between the editor and Properties view is required to add users, groups, permissions, and especially associations between the various elements.

To stream-line the basic scenario of defining users, groups, and resource-based access rules, a new form editor provides

• convenient presentation of groups, users, and roles in a master/detail structure
• access to the essential properties of objects right in the details pane of the editor
• intuitive drag-and-drop gestures for associating users, groups, and roles
• simple definition of resource-path-based permissions for roles

Security Model Integrity Checks

The security model is "just" an EMF-based model, so you can do pretty much anything with it, including shoot yourself in the proverbial foot. New in M3 is server-side validation of any transaction that modifies the security model to reject two kinds of change that would break the security manager:

• inheritance cycles in groups: users are implicitly assigned the roles of the groups that they are members of and all groups that those inherit. Inheritance cycles could lead to recursion errors
• inaccessible security model: the server rejects any transaction that would result in no users having administrative access, that is, write access to the security model

Both the reflective tree editor and the dedicated security form editor detect and report transactions rejected by the server, with a message describing the integrity violation.

Remote Repository Administration

The Kepler release of CDO added a CDO Administration view that lets users open an administrative interface to a CDO server to monitor the status of the repositories that it hosts. However, although there was a protocol and API for effecting changes to the server such as creating and deleting repositories, this was unimplemented in the server and not exposed in the UI.

The M3 milestone introduces a new "administrative repository" concept to implement the create/delete repository functions. This repository provides two key components:

• an administrator user role (per the usual security model) that serves as a server-wide administrator to authorize remote administration operations
• a catalog of repositories that were dynamically added via the administrative interface (they are not maintained in the cdo-server.xml file)

A new app extension in the server loads the repository catalog to start the repositories that it defines. On the client side, a new Create Repository wizard and Delete Repository action allow a suitably-authorized user to remotely direct the creation and removal of repositories in the server.

Currently, the deletion function merely stops the repository and removes it from the catalog. Actually dropping a database, for example, is a much more significant action (losing lots of data!) and is left for administrators to manage in ad hoc fashion according to their needs. The important point is that it makes the repository unavailable to connected clients.

The creation wizard currently supports only the most commonly used repository properties and the H2 database store, though it is designed with extensibility in mind to support other store types (contributions are welcome!).

The video embedded above provides a short demonstration of most of these new features. For additional details and discussion, see Bug 415375, especially its dependencies and their associated Gerrit reviews.

Finally, be aware that there are a few glitches in some of these functions in the "official" Luna M3 milestone. The first weekly integration builds of CDO and Papyrus following M3 will have fixes for those that are known so far.