Business identity is a complex issue rife with risks across the board. Large enterprises often require deep, flexible integrations with dozens or hundreds of partners, but this comes with significant risk — between the potential for information leakage, concerns around replays or data usage for continued insecure access, and the sheer friction of such a large system at scale, organizations are stuck between the need to share access and the potential failures.

With all of these risks in mind, and a desire for more efficient and scalable connections, how can enterprises build a partner ecosystem that is low friction, governable, and secure by design? Today, we’re going to look at one potential answer in the form of B2B identity federation, which was the subject of a talk given by Mihails Galuška, IAM Global Product Manager at If P&C Insurance, at last year’s Summit.

The Partner Integration Challenge

In many cases, the problem of identity and access comes from a simple reality: the business need may be clear and legitimate, but the operational model to support it is often the weakest part of the process. Within his talk, Galuška detailed the day-to-day reality of If P&C Insurance, a Nordic and Baltic insurance organization working with 7-8 thousand partner organizations, each with its own methods for accessing internal systems and digital channels.

The nature of this access is business-driven, and while that side of the argument is sound — after all, why shouldn’t partners be able to connect with this data? — it does create a central and complicated catch-22.

In this reality, the company must share sensitive data with partners, but it must also protect that data. The partners need flexible data access and account processes, but traditional methods created risks of password sharing, account inactivity, and limited visibility into partner lifecycle and account usage. Fundamentally, this process is extremely heavy, requiring manual access reviews, account processing, and auditing every 6-12 months, adding frustration throughout every step of the process.

Because of this core friction, a better approach was required — and it could apply to any organization trying to manage trust amongst partners while securing its own data.

Identity Federation as a Trust Management Platform

To get around this issue, If P&C Insurance decided to implement identity federation. The flow is simple:

• Partners authenticate users using their own corporate identity management and authentication systems.
• These systems are vetted and authenticated to create a trusted identity provider for If P&C Insurance.
• Auth decisions are then made using the group or role data received from the partner that is connected.
• When changes are made, such as a user leaving the organization or a change in access systems internally to the partner, access to If P&C Insurance is then changed or revoked accordingly.

Technical Implementation

The process of implementing this is actually quite straightforward. To make this work, If P&C Insurance deployed an internal Identity Provider (IdP) Broker to connect to these external partners.

When users validate using their existing company credentials over SSO, a validation process checks to see if the external provider is trusted and aligned with local identity processing. If it is — and if the provider is trusted — then the account access structure is mirrored via the IdP Broker on If P&C Insurance’s side, granting transparent access and authentication without requiring additional complex systems to route to login pages, set up new keys, and so on.

Federation integration was simple to deploy, but the real challenge was in the technical validation and implementation of trust management on the partner level. Verifying partner security maturity, aligning identity practices, modeling security policies effectively, and finally deploying contractually aligned responsibility was more complex and required significant forethought and planning.

That being said, this implementation had more tack-on benefits than drawbacks from complexity. Implementing identity federation in this way resulted in better security, reduced operational overhead, improved partner experience, and better retention over time. Partners were able to work within the platform as if it were a native resource, reducing friction and ensuring strong partnership development.

Preventing and Avoiding Data Leaks

Most importantly, however, this implementation created a deployment that, by its very nature, avoided data leaks and ensured that identity would be used as a strengthening system for access control and data ownership.

Firstly, this approach eliminates unmanaged external credentials within the overall system, enabling real-time identity lifecycle control and ensuring that identity can be used as a store of trust rather than a simple facilitator of access.

Secondly, it does this without requiring complex stored partner passwords or external user credential references. With this in place, there are no external user credentials that can be stolen and reused, and no data that could be used to forcibly access resources without first breaking the IdP Broker, resulting in significantly improved security states and a stronger firewall against complex attack vectors.

This process also assisted in the development of a way to automatically revoke account access. While this is tied to things like employees leaving the organization or changing structures, this also leads to the ability to eliminate stale accounts based upon access context and reported utilization. Over time, this reduces the need to employ manual access reviews while still ensuring the prevention of long-lived orphan accounts or captured and replayed user credentials.

Centralizing to Improve API Governance

As an additional benefit to this identity federation approach, this centralized authorization process also reduces credential sharing. Typical processing can often see people “work around” old or complex flows by simply sharing the same login. By abstracting that instead to use the local process for account access management, If P&C Insurance can effectively prevent this problem by leaning on external identity brokerage as well as corporate security controls such as multifactor authentication and account monitoring.

Finally, this approach deployed a powerful centralized authorization context, allowing for the tight mapping of role and group membership data from the partner identity system onto the local identity broker control flow. In addition to the other benefits mentioned above, this delivers exceptional alignment to security policy and expectations, resulting in a much more robust and secure system at scale.

Taken as a whole, this results in a flow that shrinks the attack window dramatically both in terms of time and scope, dramatically lowering the chance of unauthorized access, data leaks, and security failure.

Implementation Lessons

This is a unique method for dealing with a complex problem, and we can learn some takeaways from this approach. Firstly, we should recognize that the traditional partner-account model is quite insecure. Manual credential provisioning creates uncontrolled identity lifecycles, password sharing, and delayed revocation — ultimately resulting in an insecure and untrusted process for data security.

Secondly, and as an answer to the first point above, we should begin to think of the solution to this process as an allocation of authority to the domain of interest and control. This flow places the control of the ultimate access within If P&C Insurance’s domain, but understands that the edge access must be controlled and generated where it is first interacted with — at the edge in external partners and systems.

By adopting this model of identity federation, we can shift identity risk to the most accurate source of truth while ensuring that the end user is given a system they will use with low friction and adequate provision modalities. This, in turn, results in a trust platform that is actually trustworthy.

And notably, this trust doesn’t expire. Unlike other approaches, real-time access revocation and federation mean that exposure windows can be significantly reduced in scope and impact — assuming, of course, that you can properly handle the more difficult part of this, which is governance and trust, not technology.

Moving Forward: A New View of Trust

For a very long time, trust has either been external or internal. Either you have full internal control, or you trust some outside broker and hope for the best. The industry is now moving largely to a third option, and this approach herein is a good example — a hybrid approach of external trust with internal validation, one that gives you the user experience of external systems while granting the full control of internal identity processing.

As we moved into a more complicated reality of interconnected webs of devices, these sorts of approaches are going to grow in prominence and application — as well they should, as they represent a strong solution for managing identity, trust, and governance without losing developer experience, ease of connection, and partner flow.