Mostly Cumin

Things about the Cumin web UI for Condor (and other random insights).

Role Enforcement in Cumin

Roles in Cumin scope activities and content in the UI. There are currently two roles defined in Cumin, admin and user. The admin role is a superset of the user role, and every new account has the user role by default.

Differences in the Roles

The admin role allows a user to see various charts, graphs, and statistics related to performance of the Condor pool. An admin can also see information about Condor infrastructure components such as schedulers and negotiators and can run certain pool management commands. Admins are free to manage any job running in the pool regardless of who owns the job, but can also switch to the user view for the admin account.

The user role allows a user to create and manage their own submissions. They do not have visibility to jobs owned by other users, performance metrics, or pool management commands.

Enabling Role Enforcement

Role enforcement is disabled by default in the standard Cumin configuration file, effectively making every user an admin (the default will change in a future revision). To enable role enforcement, set the auth configuration value to True in the cumin.conf configuration file:

[web]
authorize: True  

Setting Role Values

The role value is part of the account metadata along with username and password. While username and password may optionally be managed in LDAP repositories, role values at this time may only be defined in the local PostgreSQL database. This restriction will likely be removed in a future version. You can read more about LDAP authentication in the earlier blog post Cumin Authentication with LDAP, and we’ll explain how to set roles for external user accounts below.

Roles are managed with the cumin-admin commands add-assignment and remove-assignment:

# cumin-admin add-assignment joeuser admin
# cumin-admin remove-assignment joeuser admin

(An account may have the user and admin roles at the same time, but currently this has no real effect since admin is a superset. It is not necessary to explicitly set the user role.)

Creating an Entry to Hold the Role for an LDAP Account

For accounts authenticated against LDAP, an entry must be added to the PostgreSQL database as a placeholder before the role value may be set. This is done with the cumin-admin command external-user:

# cumin-admin external-user myldapuser
# cumin-admin add-assignment myladpuser admin

More to Come

A future post may address the relationship of roles to persona and talk about development hooks that allow customization of the UI based on user and site profiles.

The Cumin project wiki can be found here

Credentials in LDAP URLs When Anonymous Search Is Disabled

Cumin authenticates logins against LDAP using a two step process:

  • Search for LDAP entries based on the login name and the search filter in the LDAP URL
  • Attempt a simple bind operation using the distinguished names (dn) in returned entries and the password

If anonymous access is disabled by the LDAP server, the first step will fail. In this case, Cumin needs to bind to the server with credentials before doing the search for user records. Happily, the URL syntax allows for credentials in the URL and Cumin will use them if provided to bind before the search.

Extra Attributes

The credentials for an initial bind can be set using LDAP extensions supported by the ldapurl module. There are two additional attributes:

  • bindname (a formal dn corresponding to an LDAP entry)
  • X-BINDPW (a password that will work for that entry)

These attributes follow the filter specification and are separated by a comma. Any comma (,) characters present in the bindname value must be html-escaped because the URL parser will see them as attribute separators. Futhermore, the % character in the escape code for a comma must be escaped itself to prevent Python from seeing it as a string substituion sequence. Simple, right?

An Example

Let’s assume the following:

  • The LDAP server is at example.com:389
  • The search dn is ou=People,dc=example,dc=com
  • The search scope is sub
  • The filter compares uid to username (this is actually the default)
  • The dn for an initial bind is uid=joeuser,ou=People,dc=example,dc=com
  • The password for the initial bind is joepassword

The LDAP URL in the Cumin configuration file would like like this:

auth: ldap://example.com:389/ou=People,dc=example,dc=com??sub?(&(uid=%%s))?bindname=uid=joeuser%%2cou=People%%2cdc=example%%2cdc=com,X-BINDPW=joespassword  

Note in particular the %%2c substrings in the URL. These are the commas in the bindname value. In the interest of full disclosure, let me be the first to say “yuck”. But it works!

Caution!

LDAP credentials specified as part of a URL in the cumin configuration file will be visible to anyone who has access to the configuration file. When Cumin is installed as a package the configuration file will be located at /etc/cumin/cumin.conf and will only be readable by the cumin user. This should be adequate to protect the credentials as long as the permissions on that file are not changed.

However, if Cumin is run from sources in a development instance, alternate configuration files are possible. Care should be taken to protect those configuration files if they contain credentials.

The Cumin project wiki can be found here

Integrating Cumin With LDAP for Authentication

Past versions of Cumin have relied on a local database for storing user accounts. However, that solution adds extra maintenance for site administrators who already have or plan to have a central authentication mechanism for their users. Consequently, development is ongoing to integrate Cumin with common central auth mechanisms. LDAP integration is available now, with support for other technologies planned for the future.

How will central authentication work with Cumin?

Let’s call an instance of a supported authentication scheme an “authenticator”. The PostgreSQL database installed with Cumin is the default authenticator – it will always be checked first whenever Cumin attempts to authenticate a user. If Cumin cannot authenticate the user via PostgreSQL, it will try other authenticators (i.e., LDAP repositories) specified in the cumin configuration file in listed order until the user is authenticated or the list of authenticators is exhausted.

A current limitation

There is one limitation in the initial LDAP support which makes the PostgreSQL user database indispensable: username and password may be specified in an LDAP repository, but the user role value can only explicitly be set in the PostgreSQL database (roles will be covered further in another blog post). This means that the admin role must be applied to users in the local database via the cumin-admin script. Non-admin users will default to the user role and no such entry will be needed. In the future, support for role values in LDAP is planned and local entries for admins will not be necessary.

Miscellaneous Benefits, Implications, and Warnings

  • The local PostgreSQL user database may be very sparsely populated, containing only admin role assignments for certain users. If a site has few Cumin administrators or uses a single shared administration account, overhead for managing the PostgreSQL user database will be very low indeed.

  • An entry for a user may be made in the PostgreSQL database at any time to occlude any and all LDAP repository entries for that user. Using this feature, an admin could override a password to lock out a particular account or diagnose problems within that account, etc.

  • Multiple LDAP repositories may be specified as authenticators, and the same repository may be specified multiple times with different search criteria. This allows the same user to be authenticated by alternative servers or different criteria in priority order.

  • Cumin supports LDAP connections over SSL as well as SSL between the browser and the web server. In order for LDAP passwords to remain secure, SSL must be used on both network legs.

Documentation

The Management Console Installation Guide contains everything you need to know to configure Cumin for LDAP authentication.

Here is a link to the Cumin project wiki

So What Is Cumin Anyway?

Cumin is a Python web UI developed in the Fedora community for managing Condor pools and Qpid messaging brokers. It is packaged for Fedora but may be run from sources and would probably be easy to port to other Linux distributions (or just run Fedora on a node or two in a heterogeneous environment!) The current development focus for Cumin is on expanding the Condor management facilities.

Condor Management Facilities

Cumin is designed to meet the needs of a variety of Condor users. Non-admin end users are given a streamlined interface to create and manage their own submissions. The administrative views allow System Admins to monitor pool resources and Condor infrastructure while Operational Admins may be more interested in the workload running on the pool. Cumin has development hooks which make it possible to create customized presentations for different user and site profiles.

Qpid Management Facilities

Cumin’s Qpid messaging views allow management of a Qpid deployment. Users have visibility to message queues, exchanges, connections, and broker links. Many of the tasks that can be done from the Qpid command line tools can also be done through Cumin.

How to Get Started

The Cumin project wiki can be found here, including user and developer mailing lists, install guides, and links to documentation. If you have any questions or comments, please do not hesitate to hit the Cumin mailing lists!