Simplifying access for organizational users can be really painful.

Of course, it’s easy if you’re just validating access from within an authorized IP range, but most publishers today are also wanting to verify an individual identity. Those identities can be used to drive a more personalized, engaging experience to users, and give publishers (and their organizational customers) a better understanding of user needs.

The obvious answer is leveraging the organization’s existing Single Sign-On (SSO).

In the world of higher education, Shiboleth offers a gateway to authenticate institutional users around the globe. Shibboleth makes life easier for publishers by standardizing:

  • The details on how to validate user identities at each higher education institution — publishers access this information via identity federations.
  • The technology used for managing that verification process — SAML, an open standard for exchanging authentication data.

However, life gets a lot more complex once you start delivering content and services to organizations outside higher education. Why? Because of the myriad ways in which organization’s manage their employee identities.

Why is Organizational SSO so painful for publishers?

1. Diverse Technologies

Organizational SSO comes in a wide range of protocols and proprietary solutions, many of which are customized and configured for specific technical ecosystems and organizational requirements. Some are managed purely in-house, some purely via 3rd parties, and some are hybrid. Some organizations use multiple identity solutions, such as an internal directory for staff and a hosted solution like G Suite for students.

2. Varied Technical skills

As SSO is a particularly niche area, efficiency depends hugely on speaking to the right people, with the right skills. We regularly participate in calls with multiple technical staff from a single organization because no-one’s sure exactly who has the right skills. Find the right person, and you can make progress … but it can take a lot of effort to get to them.

3. Custom Data requirements

Each organization makes its own decisions on what data to collect, and in what format, so even two organizations with the same identity solution will likely require different approaches towards integrating and using that data. For example, some internal identity solutions capture valuable information like subject specialties/affiliations and locations, while others are very bare bone and we supplement them with custom self-registration workflows.

4. Divergent Data policies

Even where the technology and data structures are the same, organizational policies can hugely impact how the data is used. Some organizations we work with are extremely protective of privacy and only provide us with a unique identifier for each user – we have no idea of the user’s real identity. Others are comfortable sharing names, email addresses, roles, departments and specialties in order to deliver a more personalized access experience and gather granular usage stats.

Publishers risk being shut out of valuable markets

Faced with this complexity and diversity, few publishers are prepared to invest in the expensive skills and technologies needed to interact with organizational SSO at scale.

Unfortunately, the fall back position is often less optimal methods of authentication, such as username/password (adding access friction that deters usage) and IP authentication (no opportunity for personalization). In some cases, they simply exit a market segment altogether.

Our cost-effective solution unlocks this opportunity

We provide you with an easily integrated API for authenticating and authorizing users. When you need to verify organizational identities, we enable the necessary authentication technologies at our end and ensure it’s properly configured for your needs.

As we also work with a wide variety of libraries and other knowledge managers, we’re also happy to help resolve technical issues directly with your organizational customer. Or we can stay behind the scenes, and provide your IT and support teams with the help they need to deliver success.

Credentials can be collected via our completely-customizable login pages, or you can collect them and leave us to do the verification behind the scenes. The information comes back to your application via our API in a standardized format, regardless of the authentication method used.

Most importantly, you don’t need to care about which SSO acronym is the flavor your customer uses – you can focus on delivering a great user experience.

Want to learn more?

If you’d like to try it for yourself, contact us for a demo or to learn more.