Identity governance forms an important foundation to a layered security strategy. Internally, most modern organizations have solved this. But far fewer have tackled this for their external population.
Think of suppliers, contractors, and partner-side users who need a certain level of self-service to be productive. However, on the other side they need restrictions that make sure they never get to see or touch what an internal user can.
This article covers this topic at one of our customers, a government instance with about 1700 users. We were able to provide a solution through midPoint that closed that gap without introducing a second product into their existing identity landscape.
A supplier portal outside the governance perimeter
MidPoint was already the backbone of our customer’s internal IGA processes. Internally requesting access, approvals, provisioning, all the usual ran through it.
Suppliers though, had their own separate, standalone supplier portal product that the customer procured and maintained independently from midPoint. It served its purpose enabling supplier-side managers to submit and manage access on behalf of their own people.
The problem was that it lived outside the governance perimeter that the customer had already built. That meant two platforms to license, patch and integrate, and two environments to explain to auditors. And most of all, two places where someone had to reason about “who has permission do what”.
Operational efficiency drove the question the customer asked us: “Couldn’t midPoint cover this too?” They wanted to manage supplier access through their existing platform that had already proven itself. Thereby eliminating the need for two governance models, existing side by side.
Same structure, separate dimensions
With a solid foundation already established in midPoint, we chose the logical route and extended it. We left the organizational tree that modelled internal departments, business units and management lines untouched.
Alongside it, we introduced a separate, parallel tree dedicated to suppliers. In this model, each supplier has its own branch.
Within this separation lies the true strength of the solution: It allows us to define, tree by tree, what is and isn’t allowed. Internal nodes kept the full governance model the client already had. The supplier tree carried its own, deliberately narrower, set of rules.
A supplier-side manager sits at the top of their own branch. They have the ppower to act on it much like an internal manager can act on theirs. The difference lies in their breadth of options. A supplier manager will never be able to act outside of his own branch.
These parallel trees allow for shared context and policies with an increased ease of use and governance, while also keeping internal and external organizations separate.
How midPoint’s native capabilities allowed for an efficient extension and easy build
- Multi-tree organizational modelling
Internal and supplier populations are organized as separate branches under midPoint’s standard organizational structure. They coexist under the same environment, rather than being completely separated systems.
- Delegated administration
The concept of “managers” gets reused but holds administrative authority relative to their organization nodes. External supplier managers are constrained in their reach by where they are located in the tree. This allows to have CRUD (Create, Read, Update and Delete) permissions inside their own organizational scope.
- Curated request catalogs
Supplier users never get to see internal roles as options in their request-access flows. The only roles that surface, are the ones explicitly assigned to the supplier portal. They are not being hidden behind a permission check, they simply don’t exist in the external tree.
- Separated authorization policies
The same goes with visibility and management rights. Suppliers only have insight into who can see which users, which organizational nodes and which requests exist in their own subtree.
The customer could now retire the standalone portal, eliminating separate licensing and maintenance. Consolidation also meant both trees are now operating under the same shared platform. Access governance, policies and their audit trail all fall under one single system to record.
Secondly, clearer visibility also means more insight into the scope for suppliers. The organization can now define more easily what the scoping entails. And because the organization can define it clearly, suppliers benefit too: supplier managers get real self-service. Where it’s scoped tightly enough, it doesn’t call for the same trust in internal managers.
Key lessons learned
The biggest challenge was scoping. We strongly feel this is the one that’s worth other implementers knowing about in advance. It might feel tempting to reuse the internal manager model for suppliers. Conceptually, “a manager is a manager”. But it’s important to review access to external roles.
In practice, a supplier manager indeed needs some of the same power an internal manager has: approving requests, seeing their own people, assigning roles,… but, restricted.
- Supplier managers can only request roles specifically tagged for the supplier portal. The internal role catalogue is invisible, not just restricted.
- We limited organizational visibility to the supplier’s own branch. They can’t browse the wider tree like an internal manager can.
- You have to narrow the delegated administration model by organizational branch. A single global definition of a “manager” can’t be a reliable alternative for scoping.
The most design effort went into getting these boundaries right. That’s why we would strongly advise other implementors to tackle this early on, not in the end.
With this tackled, the road to an efficient, well-built self-service portal for suppliers was right open. We were able to provide our customer with an extension of their tool, rather than an add-on that could fit perfectly into their existing infrastructure.
