From e477c8f23a8e6656195cf7ab7e540eb984b07696 Mon Sep 17 00:00:00 2001 From: mpana Date: Fri, 5 Jan 2018 12:02:20 +0200 Subject: [PATCH] draft of RDF 1 pearhead Directory Service (LDAP) --- rfd/0001/README.md | 60 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 rfd/0001/README.md diff --git a/rfd/0001/README.md b/rfd/0001/README.md new file mode 100644 index 0000000..eed6af3 --- /dev/null +++ b/rfd/0001/README.md @@ -0,0 +1,60 @@ +--- +authors: Marius Pana +state: predraft +--- + +# RFD 1 Spearhead Directory Service (LDAP) + +## Overview + +As we grow we require a central store of user ID's to use for authentication/ +authorization purposes within our infrastructure and third parties +(integrations). + +# What problem are we solving? + +We use many different services (email, hosting, etc.) and more are coming. It is +cumbersome to maintain user/passwords and other access policies individually per +service. In many cases we end up with multiple user accounts/passwords and +managing the lifecycle of these accounts is difficult and error prone: when a +user leaves we must also track down all of the accounts and disable/delete those +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. + +The first principles we are looking at include: + +* A centralized store for obtaining user ID's and Passwords +* Restricted access (RBAC) +* Secure end-to-end access + +## How will users interact with these features? + +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 +LDAP based directory services. + +End users will transparently interact with the system: users will receive their +credentials and will not have to manage any properties within the directory +itself. + +Developers may in the future build upon this framework and integrate with other +services. + +## What repositories are being changed, if known? + +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.