Article

Single Sign-On

« Go Back

Information

 
Full Story

What is Single Sign-On?

  • Single Sign-On (SSO) is an access security approach in which a user logs-in once to a core authentication system, and can access other systems without being prompted to log-in again by each system. Essentially it enables employees to access a number of internal systems without having to remember multiple passwords.

  • In principle, when SSO is used with Poppulo, users can log-in to Poppulo Systems using their normal company (corporate) username and password (e.g. the credentials used when logging-on to their corporate computer or network, accessing company email or corporate intranet).

  • In this way, SSO is used as a means of authenticating People who need to access microsite content, or admin users (internal communicators) who need to access the Poppulo console.
     

How does it work?

When a reader attempts to access a Poppulo microsite (or to sign into the Poppulo itself), they'll be seamlessly redirected to your corporate authentication service:

  • If the user is already logged-in, the user will be seamlessly redirected 'back' to Poppulo and shown the resource they requested or clicked.

  • If the user is not already logged-in, they will be shown the corporate log-in page.

  • If a user clicks on an external link in an email they are not authenticated through SSO.
     

In order to enable this capability, your organisation needs to have a Single Sign-On capable Identity Provider (IdP), which can be accessed by Poppulo's systems from outside your corporate network. Examples of SSO implementations which support this model include Microsoft Active Directory Federation Services (ADFS), Ping, Okta and Centrify.


If your organisation has a Security Assertion Markup Language (SAML) based implementation of SSO, where the IdP can be accessed from outside your network, then the Poppulo Technical Services team will work with your own IT team to configure the solution for use with Poppulo:

  • This is achieved by initially sharing Metadata - essentially an XML file which tells the systems how to interact and swap user authentication data.

  • Once the Metadata is shared, some initial testing and troubleshooting will be required to ensure that the Poppulo system can redirect to your SSO system to authenticate users of the Poppulo system.

  • May require asking a few real users to validate the log-in flow in a number of different scenarios.

 

Before deciding to pursue and enable Single Sign-On, you should evaluate whether:

  • The additional security applied is outweighed by any burden or issues placed on those using the system.

    • For example, if a volume of users are remote or are expected to routinely access microsite content on their mobile devices, does your Single Sign-On Identity Service make it easy for users to sign-in on their mobile devices?

  • Your IT department has the experience and capacity to support the integration.

    • While the overhead of enabling SSO is not considerable, if your IT department has not enabled SSO for an "external" vendor or third-party in the past, there may be some additional effort or learnings that could impact the level of effort required by your own team.

Was this article helpful?

   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255