Faban does not include a security and/or authentication provider. It relies on external security providers that you may use in your organization. It utilizes the Java Authentication and Authorization Service (JAAS) for authentication. To enable security, you will need both an authentication service (such as an LDAP service) and a JAAS login module for that service. Several providers are available in JavaSE 6 by itself and are listed here. Alternatively, you can create your own JAAS login module. Creating your own JAAS login module is beyond the scope of this document. You can read more about it in the JavaSE 6 documentation at LoginModule Developers Guide. These custom login modules may be added to the Faban harness' classpath by placing its packaged jar file into the faban/master/common/lib directory.
Once you found or created the login module of your choice and placed it into the right directory, you want to configure Faban to use the login module. This is done by editing the relevant sections in the faban/config/harness.xml file. Lets look at the part in question:
<security enabled="false">
<loginPrompt>User ID</loginPrompt>
<loginHint>Enter your user id</loginHint>
<passwordPrompt>Password</passwordPrompt>
<passwordHint>Enter your
password</passwordHint>
<loginModule>
<class>com.sun.security.auth.module.LdapLoginModule</class>
<property>
<name>userProvider</name>
<value>ldap://ds1/ou=people,dc=sun,dc=com</value>
</property>
<property>
<name>userFilter</name>
<value>(&(uid={USERNAME})(objectClass=inetOrgPerson))</value>
</property>
<property>
<name>debug</name>
<value>true</value>
</property>
<property>
<name>authzIdentity</name>
<value>monitorRole</value>
</property>
<property>
<name>useSSL</name>
<value>true</value>
</property>
</loginModule-->
....
</security>
The first step in enabling security is obviously to change the security element, setting the enabled attribute to "true". Next we want to set the login module class. The example above uses theLdapLoginModule provided by JDK6 - com.sun.security.auth.module.LdapLoginModule. After that, we need to configure the login module properties, such as the service to connect and others that make the login module function properly. These are passed to the login module using the property element and the name and value children thereof. The most important property for an the LDAP login module is the userProvider which identifies the service to authenticate against. There are different properties for each login module and they are usually documented in each login module's documentation.
Going back, you will be able to see a few elements that help users understand the login screen. These are loginPrompt, loginHint, passwordPromp, and passwordHint. These are messages to help the user understand what to do in the login screen. For example, the prompt "LDAP User ID" may make better sense than just "User ID" for certain cases. The hint messages are tooltip messages providing more detailed description for what to do when the mouse hovers over the login and password fields, respectively. They are all configurable through these elements in the harness.xml file.
If security is enabled, all users by default will be able to do normal tasks such as submit runs, as well as administrative tasks such as killing off runs, removing runs in the run queue, and even starting and stopping the run daemon or run scheduler. In certain circumstances, you want to limit the administrative roles to certain users. All other users can still submit runs and view runs. However, users can only delete runs from the run queue or kill runs submitted by that individual. Other administrative tasks are not allowed. The administrative users will be able to perform all administrative tasks as well as managing the run queue and killing off other user's runs. Their actions will be logged in the run log.
To enable administrative users, just add their identity (identity of their principals) in the name elements under the managePrincipals element, such as:
....In this example, users identified by "foo" and "bar" will have administrative rights over this rig.
There are two separate kinds of special users in Faban. These are users that do not derive their identity from the login module. These users access Faban through tools and their user names and passwords are usually kept in bare text in some file. Using an ordinary user from the login module for these tasks will jeopardize their security. Also these users do not have the right of the ordinary logged in user interact with the Faban harness. They can only be used for their specific tasks.
The sections of harness.xml to configure these kind of users is shown below.
....Faban does not use JAAS for authorization. Instead, it has it's own access control list (ACL) mechanism. There are several ACLs you can enable in Faban, depending on the permissions you want to restrict. In our world of open-source, we discourage you from setting ACLs. It prevents flow of information. However, there are organizations that act with more secrecy and we want to accommodate them in our little community, too. The following table lists the permissions you can set using ACLs and the scope such permissions cover:
| Permission | Scope | Description |
|---|---|---|
| manage | benchmark | Permission to manage, remove, and kill benchmark runs pertaining to a certain type of benchmark. |
| submit | benchmark | Permission to submit a benchmark run of a specific type of benchmark on this rig. |
| view | run | Permission to view the run results |
| write |
run |
Permission to change the run
description and tags |
To setup an ACL for a certain benchmark, create a directory following the benchmark's short name under the config directory, such as
$ cd faban/config
$ mkdir web101
Then, create the corresponding ACL file for the permission and benchmark in the directory you just created:
$ cd web101
$ vi submit.acl
Then list the user id as provided by the JAAS login module (some JAAS login module also identify the user by email address, which can also be used here), once per line, such as:
foo
bar
And that's it. Save the file. Now only foo and bar are allowed to submit runs for the web101 benchmark.
The acl file names correspond to the permissions described above. I.e. the manage acl file must be named manage.acl and the view acl file view.acl. They all follow the same simple format. An empty ACL is equivalent to allowing all users to perform the action.
The view permission has a slightly different meaning than the manage and submit permissions. While one manages a benchmark and submits a benchmark, he/she does not view benchmarks. He/she would view benchmark results instead. Specifying the view ACL in the config directory (and benchmark subdirectory) will make all runs submitted for the benchmark while the ACL is in effect to also carry the same ACL. In other words, the ACL is inherited to the run results for each of the submitted runs. Faban will make a copy of view.acl and place it into the result's META-INF directory. This is located at faban/output/<runId>/META-INF. You can also manually place the view.acl into the run's META-INF directory or edit its entries. If the view ACL for a benchmark run exists and is not empty, only the submitter of the benchmark and the persons whose identities are listed in the view ACL will be able to view the benchmark run results in question. To de-classify a run result, just remove the corresponding ACL file and all users - including the ones not logged on - will be able to view the results.