Single sign-on, or SSO, is an authentication service in which one set of login credentials can be used to access multiple applications. With SSO, you simplify your users' login experience by letting them sign into Podium securely and easily by using your company credentials.
There are three different uses for single sign-on in Podium. All three uses may provide different benefits to your account.
Signing in
Before a team member can use SSO, they must be added to Podium (manually or via CSV upload) and have a role and location assigned to them. Users can access Podium through the Podium sign-in page or through your business’s SSO page. When a user tries to sign in, the software checks to see if they’ve already been authenticated through your identity provider. If so, the user will be signed in. If not, the user will be prompted to enter their SSO credentials. Be aware that the enforcement of password requirements will happen through your identity provider, not Podium.
De-provisioning
De-provisioning lets you archive Podium users automatically when the user is removed from your identity provider. Currently, de-provisioning is supported for Azure, Okta, and Google. It is not supported for Microsoft ADFS. If you would like to set up de-provisioning for your account, please contact Product Support by logging into your Podium account and initiating a live chat.
De-provisioning is not the only method to remove access to Podium when using SSO. When a user is deleted from an identity provider for an account that does not have de-provisioning enabled, the employee will lose access to Podium after 10 hours when their authentication token expires. The user won't be archived—they just won't be able to log in anymore. You'll still need to manually archive the user in Podium to remove them from groups, employee reports, etc.
Provisioning (Beta)
Provisioning lets you create users automatically in Podium when you add new employees in your identity provider system. When a new user logs into Podium, their login credentials are compared to existing users in Podium. If the user doesn't exist in Podium, a new user is created based on the information in the identity provider system. Every time a user logs in, Podium automatically verifies that information and make any needed updates to their access. For example, if their role, location, or location groups have changed, the information is updated in Podium. Because this is a more complex setup, it requires a lot more data to configure. If you would like to set up provisioning for your account, please contact Product Support by logging into your Podium account and initiating a live chat.
Technical Requirements
- You must use Okta, Azure, Google, or another identity provider that is SAML 2.0 compliant.
- Microsoft ADFS can be configured to use SSO to sign in, but cannot de-provision users.
- You must be able to map fields within your identity provider.
- You must be able to provide an email address for each user.
- Each user's email address must be the same in Podium and your identity provider, as this is how the user is identified.
Additional requirements for user provisioning:
In addition to the requirements listed above, you must be able to send us the following fields for each user in the payload when they log in:
- First name
- Last name
- Role (exact text match to the roles in our system)
- Locations and/or location groups (exact text match as you have set it up in our system)
Optionally, you can send additional user information as defined below.
Data Format for User Provisioning
| Field name | Required for login | Required for user provision | Format | Description |
|---|---|---|---|---|
|
emailaddress |
Yes |
Yes |
String |
This is how we identify users and is what employees will use to log in to Podium. |
|
firstname |
No |
Yes |
String |
First name of the employee |
|
lastname |
No |
Yes |
String |
Last name of the employee |
|
role |
No |
Yes |
AccountOwner LocationAdmin TeamLeader Manager TeamMember Contributor |
This must be an exact match for one of the roles, and that role must already be enabled in Podium. |
|
segment |
No |
Yes |
String |
This must be an exact text match for a location or segment (location group) you’ve already created within Podium. |
|
bio |
No |
No |
String |
Optional: This will only work if bios are enabled for your company. It can be up to XX characters long. |
|
phone |
No |
No |
Number |
Optional: Set an phone number for the employee. |
|
title |
No |
No |
String |
Optional: Set a job title for the employee. |
|
group |
No |
No |
String |
Optional: This designates which user group the employee will be added to. This field must be an exact text match for a user group you’ve already created within Podium. |
Implementation Steps
- Podium creates a domain for your account if one doesn't exist.
- Send Podium your Entity ID and callback URL. This information can be found in your identity provider system.
- Podium sends a Metadata XML file to you via a link that is unique to you.
- Send Podium the following information, depending on which identity provider you are using:
Azure Okta Microsoft ADFS Metadata
Tenant ID
Client ID
Client secret
Metadata
API_token (only for de-provisioning)
Metadata
- You create an app for Podium through your identity provider.
- You map the fields.
- You generate Metadata (entity ID, signing certs), then send it back to Podium. URL preferred, but an XML file is also sufficient.
- Podium maps the data on our side and creates an SSO detail record.
- Podium sends a login URL for testing. The testing URL only works when using a desktop browser. At this point in the process, your users can log in using either SSO or their Podium login credentials.
- Once the test confirms the configuration is working and users exist, Podium will enable SSO. Users will then use SSO to log in using a desktop browser or the mobile app.