ENTERPRISE SECURITY
Genesys
Identity and access control where every persona is a distinct identity, and sensitive operations are restricted to approved physical locations.
- PROJECT
- Genesys
- INDUSTRY
- Enterprise Security
- STACK
- Node.js · TypeScript · OAuth 2.0 · OpenID Connect · RBAC · PostgreSQL · ELK Stack · Kubernetes
OVERVIEW
The project
An enterprise environment where agents, customers and administrators all touched the same systems needed access control that reflected what each of them was actually allowed to do. Allzone modelled every persona as a distinct identity with its own permissions, added physical location as a second authorisation check on sensitive operations, and logged every security relevant event centrally.
CHALLENGE
What made it difficult
Access models decay by exception. One shared model with a carve out for each new case becomes impossible to reason about, and eventually nobody can answer what a given persona is actually able to do.
A role on its own also does not cover the risk here. Some operations should not be possible from an arbitrary location even with the correct role, and every service implementing its own version of that check guarantees the checks will disagree.
WHAT WE DID
The work delivered.
- 01
Per persona identity model
Agent, customer and administrator each modelled as a distinct identity with its own role based permission set, rather than exceptions layered onto a shared one.
- 02
Geofenced authorisation
Location treated as a second authorisation check, so a sensitive operation requires both the correct role and an approved physical location.
- 03
Centralised authentication
OAuth 2.0 and OpenID Connect, so every service in the environment verifies identity the same way instead of implementing its own logic.
- 04
Complete audit trail
Central logging of every operation and security event, giving security and compliance teams one trace across the environment.
ARCHITECTURE
How it fits together
- Distinct identities per persona, each carrying its own role based permission set
- Geofencing as an additional authorisation factor on sensitive operations
- OAuth 2.0 and OpenID Connect as the single authentication path for every service
- Centralised security event logging on the ELK stack
- Containerised services orchestrated with Kubernetes across the enterprise footprint
TECHNOLOGY
The stack
- Node.js
- TypeScript
- OAuth 2.0
- OpenID Connect
- RBAC
- PostgreSQL
- ELK Stack
- Kubernetes
OUTCOME
What exists now.
What a persona can do is answerable from its own permission set, rather than inferred from a list of exceptions
A sensitive operation cannot be triggered from an unapproved location even with valid credentials
Security and compliance teams read one audit trail across the environment instead of correlating logs service by service
NEXT STEP
Tell us what you're building.
Bring us the problem with its real constraints attached. We will tell you what we would build, and what we would not.