Identity and access
We have shipped identity on both sides of the market: Azure AD B2C where customers sign themselves up, and Keycloak where one deployment serves several organisations that must never see each other.
Book a 30-minute scoping call See the implementations
A permission checked only in the interface is not a permission. That is where most of this work starts.
| Engineer, own site Read and submit inspections | Allowed |
|---|---|
| Engineer, another site Same role, different tenant | Denied |
| Manager, whole region Read all, edit none | Allowed |
| Free tier user Premium feature requested | Denied |
| Shared device, shift change Session follows the person | Handled |
Two different problems
They use similar words and completely different products. Choosing the wrong one is expensive to reverse once accounts exist.
Staff and internal
Usually your existing directory extended, rather than anything new built.
Customer facing
Both of our identity builds are this kind. Azure AD B2C for tiered products, Keycloak for multi-tenant platforms.
Plain definitions
Both come up on the first call, and the second one gets answered with acronyms far more often than with reasons.
Identity and access management usually means staff. Accounts created by your IT team, removed when somebody leaves, mapped to job titles, sitting in a directory you already run. Volume is measured in hundreds.
Customer identity and access management means people who sign themselves up. Registration, verification, password reset, entitlements that decide features rather than job titles, and several organisations kept apart on one deployment. Volume is unbounded and every account carries a support cost. Both of our identity builds are the second kind.
OAuth 2.0 grants an application limited access to something on your behalf. OpenID Connect sits on top of it and is how the application learns who you are, which makes it the default for anything new. SAML does the same job through older machinery and remains common inside large organisations.
SCIM is different. It synchronises accounts, so a person removed from a corporate directory disappears from your product without anybody remembering to do it. You need it the day a customer with thousands of staff asks how leavers are handled.
What we build
What people ask us for
The first three are the builds we have shipped. The rest are extensions of the same access model.
Our work
Case study, United Kingdom
Hydrajaws wanted a free app that reached the market and a premium app that justified its price. We put user management behind Azure AD B2C and enforced entitlements server side, so the free tier cannot become the paid tier on a device. The premium tier reads torque values directly from the instrument through the KTC SDK.
Case study, IoT platform
IoT Workz needed enterprise identity without paying a SaaS vendor for the privilege. We built single sign-on through Keycloak with tenant isolation, so each customer sees only their own devices and data, on infrastructure the client owns.
Technology
Two products cover almost everything we are asked for, and we pick between them by who is signing in.
Who does the work
Access bugs are modelling mistakes far more often than coding mistakes, so the useful work happens in a conversation before anybody opens an editor. That conversation goes better with the engineer who will build it than with an account manager.
You interview whoever we put forward. Ask them to describe how one tenant could see another, because an engineer who has thought about it will have an answer ready.
How we work
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
A team that works only on your product, with a lead on our side running delivery.
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
04
One price for a scope that is genuinely settled, with the overrun carried by us.
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
FAQs
No. Use a provider. Password storage, reset flows, verification and account recovery are solved problems with expensive failure modes.
B2C where you are already in Azure and want a managed service. Keycloak where you need to self-host or avoid per-user pricing. We have shipped both in production.
Yes, and large ones will. We build federation in from the start so it does not mean a separate version of your product.
Isolation enforced where data is served, plus tests that specifically attempt to cross the boundary. Assuming a filter will always be applied is how leaks happen.
Yes. We start by writing down what the current rules actually are, which is often the first time anyone has.
Usually your existing directory, extended rather than replaced. We will say if that is the cheaper answer.
Adding self-service sign-up and roles to an existing product is usually three to five weeks. A full access model with tenant isolation, entitlements and federation, designed and enforced across an existing system, takes longer. Replacing identity inside a live product with existing accounts is longer again, because migration has to keep everybody signed in. How it is billed follows the engagement model above.
Often, yes, and it is a fair question to put to us. They are good products and they remove work. The cases where they stop making sense are per-user pricing at consumer volumes, a buyer who will not accept identity sitting in a third-party cloud, and self-hosted delivery where your customer runs the whole platform. That last one is why IoT Workz runs Keycloak rather than a hosted service.
Both Azure AD B2C and Keycloak support them, so the build cost is small and the real work is the policy. Who is forced to use it, what happens when somebody loses a device, and whether an engineer standing on a roof with no signal can still get in. Decide those three and the implementation follows.
That sentence is the access model. Thirty minutes is usually enough to write it down properly and spot where the current system does not hold it.
