Introduction to Single Sign-on (SSO)
Populi supports SAML 2.0 single sign-on as either an Identity Provider or a Service Provider.
- When functioning as an identity provider, Populi accepts incoming authentication requests and provides a login page. When the user has successfully authenticated, Populi will redirect them back to your external application.
- When functioning as a service provider, Populi won't store user passwords and will instead redirect users to your SAML 2.0 Identity Provider instead. Once the user has authenticated on your system, they will be redirected back to Populi where we will validate the response and then allow them access.
You cannot use Populi as both Identity Provider and Service Provider: it has to be either the authoritative source for user credentials or it has to look to an external system, but not both.
To set up SSO, you need to be a Populi account admin. Start by going to Account > Account Settings...
Populi as identity provider
If your application needs to authenticate against user accounts stored in Populi, use the provided metadata URL (see below). If you want to use Google Apps for Education through Populi, our support team will set up Google Apps to use Populi as an Identity Provider as part of the integration.
Go to Account Settings > Single Sign-On (IdP).
Populi's IdP metadata can be found at
Its IdP certificate can be found at
Under Should other applications be allowed to authenticate against Populi?, you have three options:
- Never let other applications authenticate: as you can guess, this keeps Populi from being used as Identity Provider
- Always let other applications authenticate: any application can authenticate against Populi
- Choose which applications can authenticate: lets you specify service providers that can authenticate against Populi; see below
Add a service provider
If you select Choose which... you can add as many service providers as you wish. Click add a service provider and enter the following details:
- Name: The name by which this service provider will be identified within Populi
- Entity ID: The same entity_ID as that of the service provider
- X509 Certificate: Copy-paste the certificate contents (i.e. -----BEGIN CERTIFICATE-----[linux-style newline character][certificate contents here in 64-character-wide chunks separated by linux-style newline characters][linux-style newline character]-----END CERTIFICATE-----), or leave this blank if you want to skip the identity check
- Status: Is the application Active or Inactive?
Populi as service provider
If your college already maintains a SAML 2.0-compliant Identity Provider to authenticate students against your local network (Microsoft Active Directory Federation Services, for example), you can configure Populi to authenticate against your existing system
SSO has no effect on a user's roles/permissions within Populi. It simply offloads to your system the decision about whether a particular login (username and password) is valid.
Also, if you block a user in Populi, Populi will deny him access and not even try to authenticate; therefore, you can disable a user's access to Populi without disabling him in your system.
The decision to set up Populi as a Service Provider should not be taken lightly. A misconfiguration on your end (in the Identity Provider) could allow anyone to log into Populi—whether or not they should be able to!
If you happen to be using Microsoft ADFS, the following instructions might be useful to you: http://www.thepicketts.org/2013/02/how-to-install-adfs-2-0-and-configure-saml-for-sso-auto-loginad-login-integration/
Go to Account Settings > Single Sign-On (SP).
Populi's metadata as SP can be found at
You'll need to fill in the following settings:
Identity Provider URL
When a user attempts to log in, Populi will redirect their browser to this page, appending an unsigned SAML 2.0 <AuthnRequest> element to the URL and including the RelayState parameter set to your instance of Populi. This URL will vary depending on how you've set up your Identity Provider; check the documentation for whatever software you're using.
When a user logs out of Populi, where should we send them? Depending on your setup, this could be a sign-out URL that would destroy the session in your system that was created when the user logged in to Populi.
Enter the SAML entityID you chose when you set up your Identity Provider. If the issuer in your response doesn't match what you've entered in Populi, we won't allow the user to log in, so it's important to get this right.
Identity Provider Certificate
When your Identity Provider sends Populi an authentication response, we have to verify that it's you who sent it and not someone else. The SAML specification does this by requiring the Service Provider (Populi in this case) to have a copy of the Identity Provider's public key. The Identity Provider uses its private key to sign the request, and then the Service Provider can verify the signature because it has the Identity Provider's public key.
Download your Identity Provider's public key as an X509 certificate; next, upload it here.
Service Provider Entity ID
When Populi sends a request to your identity provider, it needs to say who the request is from. By default, Populi identifies itself as "populi.co", but in some cases you'll need to change this - Azure, for example, requires the entity ID of all service providers to be a URL, so you could have Populi send requests using the entity ID "http://populi.co" instead. The entity ID is just an identifier used by your identity provider to match each request to the list of service providers it's been configured to support, so even if you use a URL, it doesn't have to point anywhere in particular (it just has to match what you set up in your identity provider).
Enable Single Sign-on
Before you enable Single Sign-on, you must first Save your settings so we can validate your Identity Provider Certificate and confirm that the rest of your settings have been filled in.
When you check this box, SSO is active and all login requests will be routed to the URLs above. Please make sure everything is set up properly before you check this box.
If you are having trouble, try pasting your raw SAML request into the decoder tool here: https://www.samltool.com/base64.php. A common mistake is that the Issuer listed does not match what you have entered into Populi's Single Sign-On (SP) settings.
- To aid in testing your SSO setup before you check this box (and possibly lock everyone out of Populi if it's not set up properly!), you can fill in and save the rest of your settings, then visit
https://myschool.populiweb.com?sso=1. We won't actually allow you to log in until the Enable Single Sign-on box is checked, but we will redirect you to the Identity Provider URL and then show debugging information when you're redirected back to Populi after a successful login. Make sure you try this a few times and confirm that all your settings are correct before enabling SSO.
- If at any time SSO breaks and you find yourself locked out of Populi, you can visit
https://myschool.populiweb.com?sso=0to bypass SSO and log in using your Populi credentials. As an account administrator, you can also reset key users' Populi passwords from their profile even while SSO is enabled. This will allow them to choose a Populi password that an be used to access Populi as described above if SSO breaks for some reason.
- In order to access the API with Populi set up as a Service Provider, you must:
- Create the user account for making API calls in Populi before enabling SSO. If you already have SSO enabled, contact customer support for help in provisioning the user account.
- Bypass SSO when accessing the API. Your endpoint from which you will receive the access key will be
- Here is a quick snippet for testing the connection by issuing a cURL POST:
curl --data "username=username%40yourdomain.edu&password=_YOUR_URL_ENCODED_PASSWORD_" https://yourschool.populiweb.com/api/index.php?sso=0;