Access Control: OpenGamma

PROBLEM

Our development and sales teams were spending too much time supporting account-related request coming from our users: account creation, password recovery, and permissions management. With our valuable resources tied up, we were challenged to deliver on the product roadmap and acquire new customers at the pace needed. How might we free up the team from the low-value tasks related to client account administration?

APPROACH

Gathered business requirements and likely usage scenarios.
Researched popular implementations of access control, including Atlassian and Google.
Access control models were researched and a role-base access control (RBAC) model was tentatively chosen due to its applicability (versus attribute-based (no id or authentication), discretionary (object owners), and mandatory (sensitivity level of subjects and objects)) and its compatibility with other systems utilising access control models, e.g., directory services.
Possible ways of permissioning elements were grouped and ordered, e.g., users (admins, traders, all users, etc.), organisation (front office, risk management, IT, FX desk, etc.), capabilities (blotter, analytics, administration, etc.), and content (portfolios, market data, etc.)
The group of permissioning elements were mapped to the RBAC model within the workflows defined by the identified scenarios to create the UI. To manage complexity a model that used roles centrally was adopted.

CONSIDERATIONS/ASSUMPTIONS

Admins do not enjoy managing users/roles/permissions.
On system installation, user set up will done via command line/xml edit/upload.
Keep it simple and help admins to minimise complexity of management. E.g., suggest role schema
We won’t force a particular role definition model, but we may want to encourage ones that will lead to less complexity.
Allow batch editing.
The difference between roles and groups seemed mostly academic in this application of access control, so the term role was used to avoid confusion.