SSO and service catalog for contractors
The project connected two things users needed together: unified login for corporate services and a catalog that made service access, rules, and contractor next steps visible.
- Role
- Developer and technical consultant in the project team
- Timeline
- 2 months for SSO MVP, 3 weeks for service catalog
- Stack
- Keycloak, Active Directory, PHP/Symfony, Vue.js
- Focus
- Unified login, contractor onboarding, service access
Access fragmentation
Employees and contractors worked across disconnected services: separate links, logins, passwords, and instructions. A lost password quickly became a support ticket, and onboarding external users still depended on manual coordination.
First release boundary
The first release could not cover every access scenario. It needed one entry point, integration with the existing identity infrastructure, and a contractor path that could grow after the first services were connected.
Keycloak setup
Keycloak became the Identity Provider, while Active Directory remained the identity source for the first stage. This avoided a custom authorization layer and kept the existing user base intact.
Service catalog
The first service catalog was released in three weeks while the SSO part was being finalized. It solved a practical question for users: where to find a service, what access rules apply, and what to do next.
Approach
Contractor account
Boxed platforms were too heavy for the first scope. The contractor account used PHP/Symfony and Vue.js so the team could avoid platform overhead and keep the interface close to the real onboarding process.
MVP release
In two months, the team set up development infrastructure, agreed the SSO structure, configured Keycloak, connected Active Directory identification, and enabled SSO for the first corporate service.
Operational change
After launch, the contractor path became easier to explain, fewer password questions went to support, and the service catalog removed part of the daily navigation friction.
Further work
The contractor account could continue from the MVP using real usage data: which services people needed most, where they hesitated, and which permissions were actually requested.