Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
Documentation
Project
Overview
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
2
Issues
2
List
Board
Labels
Milestones
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
snac
Documentation
Commits
48c7e912
Commit
48c7e912
authored
May 27, 2016
by
Tom Laudeman
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Change role to privilege, user type to role
parent
dff9ca92
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
53 additions
and
53 deletions
+53
-53
DBUser API.md
Requirements/DBUser API.md
+53
-53
No files found.
Requirements/DBUser API.md
View file @
48c7e912
...
...
@@ -18,9 +18,9 @@ For background about users, please see:
-
support for data necessary to authenticate (log in), which is currently handled outside DBUser by
OpenID. This data includes an access token and expires time
-
support for user authorization for specific system features. This requirement relies on
rol
e(s).
-
support for user authorization for specific system features. This requirement relies on
privileg
e(s).
-
create user, requ
ri
es a username which we default to the email address string. We also expect that the email
-
create user, requ
ir
es a username which we default to the email address string. We also expect that the email
field will contain an email address. There was some discussion of multiple email addresses per user. That
has not been implemented.
...
...
@@ -29,15 +29,15 @@ For background about users, please see:
-
delete or inactivate user
-
create
rol
e
-
create
privileg
e
-
add
rol
e to user
-
add
privileg
e to user
-
remove
rol
e from user
-
remove
privileg
e from user
-
delete
rol
e (probably inadvisable, but we make it possible)
-
delete
privileg
e (probably inadvisable, but we make it possible)
-
allow multiple
rol
es per user
-
allow multiple
privileg
es per user
-
create session
...
...
@@ -61,7 +61,7 @@ using that account's username due to username being unique in table appuser. Use
accidentally reused because the database creates them from a Postgres sequence.
Some features are described in more detail in other requirements docs although we list them below with
rol
es. Requirements here will cover data necessary to support implementation of authorization, and support
privileg
es. Requirements here will cover data necessary to support implementation of authorization, and support
management of authorization.
Each user has account info:
...
...
@@ -88,17 +88,17 @@ Current session data includes:
The REST API requires the same session data. REST API users will have the same Au/Az constraints
The system has
rol
es conceptually, extensively integrated throughout the DBUser API. Each user is granted one
or more
roles. Each user has one or more rol
es, as many as necessary.
The system has
privileg
es conceptually, extensively integrated throughout the DBUser API. Each user is granted one
or more
privileges. Each user has one or more privileg
es, as many as necessary.
###
Rol
es
###
Privileg
es
The SNAC permission system is based entirely on
rol
es (groups). SNAC is authorizing users to run various
The SNAC permission system is based entirely on
privileg
es (groups). SNAC is authorizing users to run various
functions. Ownership is a non-concept, but essentially the system owns all functions. In a situation like SNAC
where there is a single owner, the concept of "owner" has no utility in authorization. The Linux concept of
"other" doesn't apply to SNAC as "other" is only allowed to perform read-only actions such as search. That
leaves SNAC needing only a
rol
e system.
leaves SNAC needing only a
privileg
e system.
(Optional paragraph) Not having "files", there is no concept of "file has no privileges" for user, group, or
other. An example of what SNAC does not have is the shared web server situation where user grants privileges
...
...
@@ -106,13 +106,13 @@ and group removes privileges. In a shared web server, users are all assigned to
accessible directories have no group permissions and are owned by group user. Lacking permissions for group
user, no one in group user has any access. Actual access then is granted only to the owner who has
read-write-execute (rwx) for that directory. Apache runs as suexec for each user, and thus each user's CGI
scripts gain access to only that user's directory via the user privs.
scripts gain access to only that user's directory via the user priv
ilege
s.
SNAC lacks the Linux "subtractive" permission which is sometimes used with groups permissions. Instead SNAC
has only additive permissions.
In a global sense, the cumulative collection of users and
rol
es is complicated. However, that complexity is
essential (not accidental) and on a per-user or per-
rol
e basis, things are very manageable. When managing the
In a global sense, the cumulative collection of users and
privileg
es is complicated. However, that complexity is
essential (not accidental) and on a per-user or per-
privileg
e basis, things are very manageable. When managing the
system, imagine asking these typical, and manageable questions:
-
List all users affiliated with California Digital Library (CDL).
...
...
@@ -128,56 +128,56 @@ system, imagine asking these typical, and manageable questions:
-
List all users who may run reports for their own affiliation.
Below is an example. Anyone who can log in can get a dashboard, so there are no specific dashboard permissions
(yet). The user id "public" and the
role "research" may not make any sense. Conceptually, everyone has rol
e
(yet). The user id "public" and the
privilege "research" may not make any sense. Conceptually, everyone has privileg
e
"Public HRT", so there's no reason to restrict or authorize it. In actual implementation the "what is public"
divide is simply any published record or read-only acti
ti
on on published constellations. The table below
initially had a user id "public" with
role "Public HRT", and every user also had the rol
e "Public HRT", but
divide is simply any published record or read-only action on published constellations. The table below
initially had a user id "public" with
privilege "Public HRT", and every user also had the privileg
e "Public HRT", but
that was simply redundant.
The
rol
es below are real, but do not imply any actual policy or any relation to persons living or dead.
The
privileg
es below are real, but do not imply any actual policy or any relation to persons living or dead.
Pulling a couple of random details from the table below, and wording them in English:
-
Casey at CDL can approve NACO submissions (NACO approve)
-
Jessie at NYPL is limited to assigning
roles only for NYPL (affiliation-nypl and rol
e-assign-own)
-
Jessie at NYPL is limited to assigning
privileges only for NYPL (affiliation-nypl and privileg
e-assign-own)
| user | description |
rol
es |
| user | description |
privileg
es |
|------------------|----------------|-------------------------------------------------------------------------------------------------|
| Marley Turner | content expert | contribute, affiliation-none |
| Remy Roberts | power editor | contribute, change-status-any, change owner, publish, affiliation-any |
| Casey Miyazaki | editor CDL | contribute, change-status-own, publish, NACO approve, affiliation-cdl, report-own-affiliation |
| Jessie Coughlin | admin NYPL | affiliation-nypl, enroll-own-affiliation report-own-affiliation,
rol
e-assign-own |
| Avery Valenzuela | super admin | enroll-any, report-any,
rol
e-assign-any |
| Jessie Coughlin | admin NYPL | affiliation-nypl, enroll-own-affiliation report-own-affiliation,
privileg
e-assign-own |
| Avery Valenzuela | super admin | enroll-any, report-any,
privileg
e-assign-any |
Rol
es have a number of traits.
Privileg
es have a number of traits.
-
Roles are additive, and all rol
es of a user define that user's authorized functions
-
Rol
es are created and maintained by admins and developers.
-
Some instance
rol
es (such as affiliation) can be created by admins as needed.
-
Roles (ideally) have a single privilege per role. Rol
es are very granular.
-
Rol
es and privileges must be coordinated with work flows and application features.
-
One
rol
e exists per institutional affiliation.
-
Every user has the conceptually
role Public HRT, although no actual rol
e exists for read-only access to published constellations
-
Potentially, we can have
rol
es for ad hoc groups (sub-institution, department, professional orgs, etc.)
-
Roles can be deprecated, but re-purposing rol
es is inadvisable from a security standpoint.
-
Rol
es need explicit, on-going policy guidance.
-
Privileges are additive, and all privileg
es of a user define that user's authorized functions
-
Privileg
es are created and maintained by admins and developers.
-
Some instance
privileg
es (such as affiliation) can be created by admins as needed.
-
Privileges (ideally) have a single privilege per privilege. Privileg
es are very granular.
-
Privileg
es and privileges must be coordinated with work flows and application features.
-
One
privileg
e exists per institutional affiliation.
-
Every user has the conceptually
privilege Public HRT, although no actual privileg
e exists for read-only access to published constellations
-
Potentially, we can have
privileg
es for ad hoc groups (sub-institution, department, professional orgs, etc.)
-
Privileges can be deprecated, but re-purposing privileg
es is inadvisable from a security standpoint.
-
Privileg
es need explicit, on-going policy guidance.
The minimal
rol
e "Research" grants privileges for search history, and certain research reports. Members of
The minimal
privileg
e "Research" grants privileges for search history, and certain research reports. Members of
the public are mostly identical to Researchers. The primary feature gained by having an account is a
persistent dashboard. As already noted, "Public HRT" not an actual
rol
e, but instead is conceptual.
persistent dashboard. As already noted, "Public HRT" not an actual
privileg
e, but instead is conceptual.
(Comment: I just noticed that
rol
es are mostly verbs: research, contribute, delete, propose, approve, block,
embargo, enrol
e
, assign. It seems like a nice idea to enshrine this as a convention. We would have to change
"administrator" to "administer", and we need to come up with a verbs for the remaining
rol
es, especially
(Comment: I just noticed that
privileg
es are mostly verbs: research, contribute, delete, propose, approve, block,
embargo, enrol
l
, assign. It seems like a nice idea to enshrine this as a convention. We would have to change
"administrator" to "administer", and we need to come up with a verbs for the remaining
privileg
es, especially
"affiliation".)
|
Role | Role Description
|
|------------------------------+----------------------------------------------------------------------------|
|
Privilege | Privilege Description
|
|------------------------------
----
+----------------------------------------------------------------------------|
| Research | Use discovery interface and dashboard, has an account |
| Contribute | Create and edit constellations but cannot publish (contributor) |
| Publish | Approve constellation publication, change status to "published" (editor) |
...
...
@@ -192,8 +192,8 @@ embargo, enrole, assign. It seems like a nice idea to enshrine this as a convent
| Propose NACO | Create(?) NACO contributions, but not push(?) to NACO |
| Approve NACO | Approve, finalize, submit NACO contributions (editor) |
| Enroll | Enroll new SNAC participants, create new users |
|
Role assign own institution | Assign new roles for own-institution users
|
|
Role assign any institution | Assign new roles for any institution users
|
|
Privilege assign own institution | Assign new privileges for own-institution users
|
|
Privilege assign any institution | Assign new privileges for any institution users
|
| System administrator | Maintains server hardware and operating systems |
| Developer | Writes the SNAC application, a programmer |
| Web administrator | (duplicate? historical?) May perform admin tasks via the web interface |
...
...
@@ -203,23 +203,23 @@ embargo, enrole, assign. It seems like a nice idea to enshrine this as a convent
| Report any | Run any report, super reporter |
| Report admin | Run special administrative reports |
| Affiliation X | Affiliated with institution X. |
| Affiliation any
| Affiliated with all institutions, a super role (discuss?)
|
| Affiliation any
| Affiliated with all institutions, a super privilege (discuss?)
|
Example
user types, with their rol
e(s) and description.
Example
role, with their privileg
e(s) and description.
|
User type | Role(s) | User Description
|
|----------------------------+-----------------------------------------------------
+
-------------------------------------------------------------|
|
Role | Privilege(s) | User Description
|
|----------------------------+-----------------------------------------------------
---------+--
-------------------------------------------------------------|
| Sysadmin | System administrator | Maintain server, backups, etc. |
| Database Administrator | DBA | Schema maintenance, data dumps, etc. |
| Software engineer | Developer + DBA | Coding, testing, QA, release management, data loading, etc. |
| Manager | Enroll +
Role assign own + Report own | SNAC accounts: create, manage, assign roles, run reports
|
| Manager | Enroll +
Privilege assign own + Report own | SNAC accounts: create, manage, assign privileges, run reports
|
| Peer vetting | Enroll | Approve moderators, reviewers, content experts |
| Moderator | Publish | Approve maintenance changes, posting those changes |
| Reviewer/editor | Contribute + publish | Maintainer privileges, interacts with moderators |
| Content expert | Contribute
| Domain expert, may have zero institutional roles
|
| Documentary editor | Contribute
| (Any distinguishing roles?)
|
| Content expert | Contribute
| Domain expert, may have zero institutional privileges
|
| Documentary editor | Contribute
| (Any distinguishing privileges?)
|
| Maintenance | Contribute, constellation | May be older terminology for "contribute" |
| Research | Research | Use the discovery interface and history dashboard |
| Archival description donor | Block upload | May do bulk uploads of EAC-CPF, finding aids, etc. |
...
...
@@ -230,8 +230,8 @@ Example user types, with their role(s) and description.
| Author | Contribute + Publish + Propose Del/Emb+Propose NACO | Contribute, with additional privileges |
| Editor | Contribute + Publish + Delete/embargo + NACO | Review constellations, approve and publish |
| Author-NACO | Propose NACO | Creates NACO entries, sends to editor for submission |
| Administrator | Contributor
roles + Editor roles + enroll + assign | Everything, only own institution
|
| Administrator-super | Administrator
roles + any institution | Admin plus assign roles for any user of any institution
|
| Administrator | Contributor
privileges + Editor privileges + enroll + assign | Everything, only own institution
|
| Administrator-super | Administrator
privileges + any institution | Admin plus assign privileges for any user of any institution
|
### API
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment