Using a whitelist for fine-grained access control

Overview

Starting with Orca 3.1-extended ORCA SMs have the option of using a whitelist to check user IDs of incoming requests (only for XMLRPC APIs, not through the portal). The user ID is either a Distinguished Name (DN) from the certificate issued from BEN or an alternative name (a URN) issued by ProtoGENI or GPO. The whitelist is a list of patterns or usernames of users allowed to place requests against this controller. User DNs or URNs not matching the patterns will be rejected with an error message.

Configuring the whitelist

The controller.properties file (xmlrpc.controller.properties in ORCA 3.x) contains the relevant propertes:

orca.credential.verification.required=true

# works in conjunction with credential verification. the whitelist
# file can contain regex patterns or usernames each on its own line
# The '#' character at the start of the line denotes a comment
controller.whitelist.file=/opt/orca/config/xmlrpc.user.whitelist

The first property turns on user credential verification (user certificate is validated and put through several checks). The second property specifies the name of the file containing the whitelist.

The whitelist contains multiple lines, each line either a comment (starting with '#') or a fragment of a user name or a regex pattern:

# allow anyone with a URN
.+urn:publicid:IDN.+
# allow username 'username' (whether in DN or a URN) 
username
# allow everyone
.*

Obviously the last pattern makes the other two unnecessary.

To whitelist a specific user, the easiest approach is to list the unique part of the DN contained in Subject field or the unique part of the URN contained in X509v3 Subject Alternative Name both of which can be visible with

$ openssl x509 -in filename.pem -text