Spearhead/rfd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

draft of RDF 1 pearhead Directory Service (LDAP) - previous was predraft

Browse Source
This commit is contained in:
Marius Pana 2018-01-05 12:03:30 +02:00
parent e477c8f23a
commit 2a73c7e05f
1 changed files with 5 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
rfd/0001/README.md
View File

@ -1,6 +1,6 @@
---
authors: Marius Pana <mp@spearhead.systems>
state: predraft
state: draft
---
# RFD 1 Spearhead Directory Service (LDAP)
@ -23,7 +23,7 @@ as well.
## Key Requirements
We wish to have a central location for all user authentication requests so that
we can easily create and manage users.
we can easily create and manage users. We can then use this central store to authenticate with all of our required services.
The first principles we are looking at include:
@ -35,7 +35,7 @@ The first principles we are looking at include:
Operators will interact directly (cli, web, clients) with the directory based on
their permission levels. Operations will include adding new objects, modifying
policies and acls, deleting users, etc. All operations will be typical of other
policies and ACLs, deleting users, etc. All operations will be typical of other
LDAP based directory services.
End users will transparently interact with the system: users will receive their
@ -50,11 +50,7 @@ services.
A new repository Spearhead/ldap (or similar) will be created to host
configuration files (possibly other details) for the framework.
## What is the upgrade impact?
Since this is an initial deploy it will require creating the directory, integrating it with our services (email, git, mattermost, etc.) and then assigning the new uid's.
## What is the security impact?
The service itself must be secured end-to-end (starttls/ssl/tls) including the operating environments. The service itself will require fine grained controls (RBAC/ACLs) to limit what users can modify within the directory.
A compromised directory must be handled in an automated fashion and mechanisms for limiting impact as well as service restoration to a known state must be available.
A compromised directory could allow an attacker access to sensitive information or services. Furthermore a compromised directory could be used against us and therefore other methods of access for critical situations must be implemented (local accounts, override mechanisms, etc.). A mechanism to disable/invalidate all accounts must be implemented.
A compromised user account impact depends on the privileges of the compromised account. A mechanism to quickly disable any compromised account must be implemented.