Design of the Domain Backend
Domains each represent a distinct set of user accounts and projects. In the event that identity data comes from more than one source, we need a way to distinguish between those sources. The management of domains can be extracted from the rest of the identity background. It will then be implemented as a chain of responsibility. Each link in the chain will provide access to one type of identity backend.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Not
- Drafter:
- Adam Young
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Adam Young
Related branches
Related bugs
Sprints
Whiteboard
(henry-nash) So how about the first thing we do is extract domains into its own backend (a it like we did with credentials). I think we should leave it in SQL initially, with then potential other backend implementations as we progress this.
I think we can maintain domains as as SQL only construct for the foreseeable future. If we do one domain per LDAP install, then having a single place to manage them makes sense. Dynamic domain creation will be against SQL, and but the LDAP ones can also be stored in the same data backend, just with an indicator that they are in LDAP, not SQL. It should be able to indicate whether just the identity portion is in LDAP, or both Identity and project.
The scope of this bp seems to be enormous; can it be limited to henry's suggestion above? -dolph
Work Items
Dependency tree
* Blueprints in grey have been implemented.
