generated from jric11/baseProject
26 lines
3.0 KiB
Markdown
26 lines
3.0 KiB
Markdown
|
# Application dashboard and assignments
|
||
|
|
|
||
|
|
Sign in as an Administrator or configured System Administrator. Open **Application Access** in the user menu.
|
||
|
|
|
||
|
|
On the first visit, use **Set up application directory**. This runs `migrations/001_application_access.sql` against the configured decauthy database, creating `applications` and `user_applications` and registering the two development URLs. It does not assign any user access. The migration is also available to run directly with your database tools. Repeating it preserves existing URLs and assignments.
|
||
|
|
|
||
|
|
Choose a user and press **Load**. Select their applications and press **Save access**. Clearing all selections removes all of that user's assignments. Saving replaces the selection in one transaction and records the change in the journal. Disabled applications retain assignments but do not appear on the dashboard.
|
||
|
|
|
||
|
|
After sign-in, customers see only their assigned active applications. The launch endpoint checks the assignment again before redirecting, so a removed assignment stops launches immediately.
|
||
|
|
|
||
|
|
These links currently open the applications' existing sign-in flows. They do not convey authenticated identity or replace either application's access checks. The secure authentication handoff and legacy-user mappings are a subsequent integration step.
|
||
|
|
|
||
|
|
For production, update `applications.application_url` to each product's HTTPS address. Each product keeps its own authentication and subscription permissions until integration is complete.
|
||
|
|
|
||
|
|
Verification: test a user with zero, one, and two assignments; clear an assignment and confirm the corresponding launch is denied; confirm a regular user cannot open or post to the administration routes. Administrator account-management routes are also protected server-side because changing an account's role would otherwise bypass assignment administration.
|
||
|
|
|
||
|
|
## Existing application accounts
|
||
|
|
|
||
|
|
Use **Enable account links** on the Application Access page to create the account-link table without changing existing assignments. Fresh directory setup now creates this table too.
|
||
|
|
|
||
|
|
After loading a DEC user, enter the existing `user_serial` from each destination application's `users` table. Matching usernames can help an administrator locate the record, but do not constitute automatic identity verification. Confirm the record belongs to the same customer before saving. Different usernames and different numeric IDs between applications are supported.
|
||
|
|
|
||
|
|
A destination account can be linked to only one DEC user. Duplicate links return a conflict and roll back the entire save, including assignment changes. Blank fields remove mappings. Unchecking application access preserves its account mapping, so restoring access can retain the same customer history. Account existence and active status must also be checked by the destination during the eventual authentication handoff.
|
||
|
|
|
||
|
|
This step prepares the identity mapping only. There is no cross-application authentication token or handoff enabled yet, and destination passwords continue to work as before.
|