generated from jric11/baseProject
54 lines
4.1 KiB
Markdown
54 lines
4.1 KiB
Markdown
# Shared sign-in deployment
|
|
|
|
## Confirmed production addresses
|
|
|
|
| Service | Address |
|
|
| --- | --- |
|
|
| DEC sign-in portal | https://login.realestatedatainc.com/ |
|
|
| Real Estate Data Inc | https://apps.realestatedatainc.com/realestatedatainc/ |
|
|
| Georgia Housing Report | https://apps.realestatedatainc.com/atlhousingreport/ |
|
|
|
|
## Confirmed staging addresses
|
|
|
|
| Service | Address |
|
|
| --- | --- |
|
|
| DEC sign-in portal | https://staging.realestatedatainc.com/decauthy/ |
|
|
| Real Estate Data Inc | https://staging.realestatedatainc.com/realestatedatainc/ |
|
|
| Georgia Housing Report | https://staging.realestatedatainc.com/atlhousingreport/ |
|
|
|
|
The current development environment uses HTTP. Shared sign-in will be verified on these separate HTTPS staging copies. Staging clients, signing keys, sessions, and databases must be separate from production. Use test users and direct staging mail to a test inbox.
|
|
|
|
After initializing the staging application directory, run `deployment/staging-application-urls.sql` against the staging decauthy database to set its dashboard destinations. This script is intentionally excluded from automatic directory setup.
|
|
|
|
## Staging preparation
|
|
|
|
1. Create HTTPS staging sites for all three applications with certificates trusted by the test browser and server. Keep each application's current login available during integration.
|
|
2. Create separate staging databases. Configure each copy to use its staging database and test mail destination before opening it to testers.
|
|
3. Deploy decauthy's dashboard and account-link changes. Initialize its application directory, replace the development application URLs with the actual staging URLs, and assign one test user to each product.
|
|
4. Link that test user to its existing local user_serial in each staging product. Confirm the destination user is active and has the intended test subscriptions.
|
|
5. Install and configure the identity provider on staging, then register one client for each destination application. Exact callback URLs will be chosen when the callback handlers are implemented. Do not register guessed or wildcard callbacks.
|
|
|
|
## Proposed PHP identity provider
|
|
|
|
SimpleSAMLphp with its OpenID Connect provider module is a self-hosted PHP option. The currently documented SimpleSAMLphp baseline is PHP 8.3 or newer; Composer must resolve the selected release and extensions on the actual PHP 8.5 server before compatibility is considered verified.
|
|
|
|
Install SimpleSAMLphp separately from the decauthy application, following the official installation guide. Publish only its public directory; configuration and private signing keys remain outside the web root. From that installation's directory, install the OIDC module with:
|
|
|
|
```sh
|
|
composer require simplesamlphp/simplesamlphp-module-oidc
|
|
composer check-platform-reqs
|
|
```
|
|
|
|
The provider needs an authentication integration with decauthy's central accounts, its own protocol storage, signing keys, and exact client registrations. Installing the module alone does not connect decauthy's current login session to the provider. Neither that integration nor the destination callbacks have been implemented yet.
|
|
|
|
Sources:
|
|
- https://simplesamlphp.org/docs/stable/simplesamlphp-install.html
|
|
- https://simplesamlphp.org/docs/contrib_modules/oidc/2-oidc-installation.html
|
|
- https://simplesamlphp.org/docs/contrib_modules/oidc/3-oidc-configuration.html
|
|
|
|
## Acceptance checks before production
|
|
|
|
Verify central login opens each assigned product as the mapped existing user, preserving its local permissions and history. Test missing mappings, inactive destination users, denied assignments, expired or reused authorization codes, incorrect state/nonce, and incorrect client or callback. Decide and verify how product sign-out, DEC sign-out, and removal of access affect existing sessions.
|
|
|
|
After staging passes, register production clients with separate secrets and signing keys and configure the confirmed production URLs. `deployment/production-application-urls.sql` updates dashboard destinations only and is intentionally excluded from the automatic directory setup. No production database changes or deployments have been performed from this chat.
|