Data Segmentation and Access Roles🔗︎
Roles allow you to be flexible in the document access controls you want to apply on your users. This requires assigning roles to documents and search requests:
- Assign a list of roles to each document when adding them to the index.
- Specify roles when searching. The role specifiers determine which documents are visible depending on the roles on the document.
Roles Assignment and Format🔗︎
Assignment of roles to documents and roles to search requests is managed by yourself, so this can be as simple or as complex as required per business requirements.
You are free to provide any string as a role that satisfies the following regular expression format (mixed numbers and letters, case sensitive):
When specifying roles for searching, they may be listed as multiple roles: both negative and positive. They grant access to a document only if it matches at least one positive role and not any of the negative roles:
- role: positive role, grants access if the document matches one of these
- role1 -role2 -role3: positive role with exceptions, acts as a positive role but is ignored if the document contains any of the negative roles.
- -role: negative role, forbids access to the document if it matches one of these. This rule overrides a positive match.
In addition to the above formats, there is a special role "all" which can be used in place of a positive (with or without exceptions). Role "all" is interpreted to match all documents.
Example Roles Scheme🔗︎
Below are examples of using roles. The general approach is to map out all user types against document groups, and use that to find the minimal set of roles necessary to enforce the desired level of access control. Please also note that, access roles are case sensitive ('all' is not equal to 'ALL').
Example 1: Flat🔗︎
Suppose a career consultancy company has many customers, each with their own customer database. Customers can search only in their own database.
On documents🔗︎
- Document roles: assign the customer name (e.g. Google)
On search requests🔗︎
- Customer roles: assign the customer name (e.g. Microsoft)
- Administrator access roles: role "all" can see all documents
Example 2: Matrix🔗︎
Suppose a recruitment company works in several lines of business (FIN, EDU) in multiple countries (UK, US). Each combination is a business unit. A possible roles scheme is:
On documents🔗︎
- Document roles: assign three roles to each document: line of business, country and business unit. e.g. (FIN, US, FINUS)
On search requests🔗︎
- Standard recruiter roles: assign one business unit role. e.g. (FINUS), can only access ICT documents in US.
- Foreign recruiter roles: assign two business unit roles. e.g. (FINUK, ICTUS), can access ICT documents in both UK and the US.
- Country manager roles: assign one country role. e.g. (US), can access documents in US for all business lines.
- General manager roles: assign special role: "all", can access all documents
Example 3: Hierarchical🔗︎
Suppose a staffing agency has organized its candidate pool in several groups and sub groups. They are organized in a hierarchical structure. Access is granted by specifying parts of the hierarchy with exceptions. And it is also possible to grant access to a specific candidates overriding the hierarchical rules.
On documents🔗︎
- Document access roles: assign roles for each layer in the hierarchy, e.g. (1, 1x2, 1x2x1, 1x2x1x4)
On search requests🔗︎
- Access to a sub group in the hierarchy, e.g. (1x2), can access all documents within the 1x2 group
- Access to a sub group with exceptions, e.g. (1x2, -1x2x1), can access all documents within the 1x2 group except for documents in 1x2x1
- Access to a sub group with exceptions and individual additions, e.g. ("1x2 -1x2x1", 1x2x1x4), can access all documents within the 1x2 group except for 1x2x1, but also access 1x2x1x4.