Why care about Hoop.dev if you already use SSO

Identity providers became quite standard these days. Why would a company care about another solution for Single Sign-On (SSO) if they are already using an identity provider? The answer is multifold.

Compatibility

Firstly, it's important to note that not everything is SSO compatible.

Consequently, there are often weak links in the infrastructure if everything isn't put behind the strong authentication of an SSO provider. These weak links often present as static key-based usernames and passwords spread across the infrastructure. Primarily when there is insufficient time to build an SSO connector.

Implementing OpenID Connect or SAML protocols for tools that do not inherently support them is tricky.

Intermediary Solution

A set of tools that are difficult to add SSO support to are open-source databases.

The connectors are not ideal. If you're running on a cloud provider, you may have the option to proxy connections through SSO, but even so, you're essentially provisioning temporary database users. For a period of time, you're exposed to the legacy database authentication methods. Such systems are primarily provisioning tools for credentials. They're a step up from static credentials.

But still fall short of the authentication power offered by native SAML or OpenID authentication.

Suppose there is console access involved in your development process. In that case, it could be your engineers or even support team members accessing the runtime of processes, such as the Rails Console or Django shell. These access points should be protected with strong authentication behind a robust IDP with policies in place.

The list goes on.

SSO bridge

That's primarily why we created the SSO bridge.

It serves as a bridge that protects your systems with your identity provider's authentication at the source. This means it doesn't provision temporary users to the backend system.

Instead, it uses a single user per profile you want to expose.

Then, you integrate your central user directory with this profile, and the authentication happens natively. This is the main reason why an addition to your Single Sign-On provider with the SSO bridge might be worth considering. It effectively closes all the gaps in your identity system.

Bringing the level of protection up to that of your IDP.

Remember, if you have weak links in your security chain, that dictates your security level. Consider areas in your infrastructure where you're still using legacy authentication methods. These places can't support identity provider protocols by default.

Trying to make them compatible means wasting a lot of work.