A Relational Security System is one in which your security model is part of your data model. Access to each piece of data or functionality is limited according to the user's relationships to that data or functionality. What this means is that access rights are contextual, based on relationships between that data and the connected user, and that each test for a specific access right is a test in a specific context.
For example:
You have access to the company accounts only for the company you work for.
Your access rights to company accounts data applies only in the context of the company that employs you. You would not have access to company accounts for other companies.
We say that you have been given those access rights in
company-context for your company.
You have access to employee data only for employees of your department.
Your access to employee data applies only in the context of your department. You would not have access to employee data for other departments.
We say you have been given those access rights in
department-context for your department.
You have access to see the postings of only your friends.
You have access to postings only in the contexts of posters who are recorded as your friends.
We say that you have those access rights in
friend-context for each of your friends.
Users acquire their access rights in various ways: all users may get a basic set of rights; some users may be members of teams or departments and their roles in those things may give them implied rights; and some users may be granted specific rights explicitly. Even with explicit assignments, those assignments may occur in different contexts giving the user access to greater or smaller subsets of data: you might be a given the manager role for a project, or for a department, or for a division, or company-wide.
Contexts may be created from almost any definable subset of your data. Mostly they are based on the relationships of your users with their data, though they need not be. Typically, they are defined in terms of users and their relationships to specific artifacts described by your database. For example, a person's relationship to the company they work for, or their membership of a department or project team.
Having contexts associated with each assigned access right means that the granularity of access controls can be as coarse or as fine as the data demands, and it means that there is rarely the need for more complex access checks than "do I have privilege X in context Y?".
Instead of having rights which imply conditional rule checks, such as the right to maintain-a-project-if-the-user-is-a-member-of-the-project-team, rights can effectively contain their conditionality through their context.