On the local node
- Sign-in and local identity lookup continue while Account and its database are healthy.
- Identity records remain within the configured node data boundary.
Wizaya Server Suite
PBB Account
Local canonical identity and OAuth-style sign-in for participating PBB applications on a deployed node.
What it is
A service in the local-node foundation
Integrated · Production hardening
Baseline node service
PBB Account provides a local identity authority and shared sign-in surface for participating applications. It keeps identity available inside the node boundary when an upstream route is unavailable.
Its current contracts are OAuth-like integration contracts for the PBB stack, not a claim of complete OpenID Connect conformance or compatibility with every third-party relying party.
Node role
What it contributes
Acts as the local identity authority so participating applications can recognize one governed user identity without depending on a public cloud login route.
Service behavior
Local operation and connectivity
Across a route
- Cross-node identity exchange is not implied by local sign-in.
- External identity federation requires an explicit, separately reviewed integration.
Confirmed current integration
Modules with verified service paths
Only module integrations confirmed in the current implementation are listed here. Planned packaging, architectural relationships, and unverified paths are excluded.
Deployment placement
Where it fits
Baseline deployment
Barangay node; Local command node; Daily-apps node
Hardware, power, connectivity, training, travel, and field logistics remain deployment-specific.Operations and security
Boundaries operators must preserve
Operational considerations
- Back up identity data and signing material under a documented recovery procedure.
- Coordinate client identifiers, redirect routes, and role mappings for each application.
Security boundary
- Keep administrative access and secrets inside the managed node boundary.
- OAuth-style support must not be presented as certified full OIDC support.
Practical questions
Frequently asked questions
Is PBB Account a complete OpenID Connect provider?
No. PBB Account provides a shared local identity and sign-in service for participating PBB apps, but it is not presented as a complete OpenID Connect service.
Can users sign in without internet access?
Yes, as long as PBB Account, its stored data, and the app are working on the local PBB network.
Does one account automatically work on every PBB node?
No. Accounts work across nodes only when the deployment owner deliberately connects them and sets rules for how identities are managed.
Who defines application roles and permissions?
The deployment owner decides which roles people receive. Each app must then check those roles before allowing access to protected features.
What must operators protect during recovery?
Operators must protect account records, security keys, app connection settings, and the documented steps used to restore access safely.
Status and readiness
Integrated
Canonical local identity and application sign-in integrations are implemented across participating services.
Remaining hardening work
- Complete production credential and key rotation procedures.
- Harden role and claim contracts for every deployed relying application.
- Do not advertise full OpenID Connect conformance without a separate verification effort.
Companion services
Related infrastructure
Broader platform context
Architecturally related modules
These relationships provide context and do not assert a confirmed current service integration. Verified integration paths appear in the earlier confirmed-integration list.
Briefing and pilot discussion
Discuss PBB Account in a local PBB deployment
Explore how a local-node deployment could support practical service continuity in your community.