draft of RDF 1 pearhead Directory Service (LDAP) - previous was predraft
This commit is contained in:
parent
e477c8f23a
commit
2a73c7e05f
@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
authors: Marius Pana <mp@spearhead.systems>
|
authors: Marius Pana <mp@spearhead.systems>
|
||||||
state: predraft
|
state: draft
|
||||||
---
|
---
|
||||||
|
|
||||||
# RFD 1 Spearhead Directory Service (LDAP)
|
# RFD 1 Spearhead Directory Service (LDAP)
|
||||||
@ -23,7 +23,7 @@ as well.
|
|||||||
## Key Requirements
|
## Key Requirements
|
||||||
|
|
||||||
We wish to have a central location for all user authentication requests so that
|
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:
|
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
|
Operators will interact directly (cli, web, clients) with the directory based on
|
||||||
their permission levels. Operations will include adding new objects, modifying
|
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.
|
LDAP based directory services.
|
||||||
|
|
||||||
End users will transparently interact with the system: users will receive their
|
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
|
A new repository Spearhead/ldap (or similar) will be created to host
|
||||||
configuration files (possibly other details) for the framework.
|
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?
|
## 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 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 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 user account impact depends on the privileges of the compromised account. A mechanism to quickly disable any compromised account must be implemented.
|
||||||
|
Loading…
Reference in New Issue
Block a user