Single Sign-On (SSO) for the Foleon platform

Use Single Sign-On (SSO) for Foleon to make logging in easy and secure for your workspace — by allowing you to restrict access to a specific set of people. This article shows you how to set up Single Sign-On (SSO) for the Foleon platform.

What is SSO?

Single Sign-on, or SSO, is an authentication process that allows a user to access multiple websites or applications with one set of login credentials. This means that once you’ve logged in with your username and password, you don’t have to log in repeatedly for every single application linked to the system. You can look at it as if you have one key that unlocks multiple locks.

How to set up SSO for the Foleon platform

In the dashboard, go to account and then click on SSO for Foleon platform. To create a new SSO configuration, click on the blue New SAML configuration button to get started.

Copy the service provider details to the SSO configuration of your identity provider.

You then enter your identity provider URL — manually type the URL or upload an XML file.

Next, copy the three claims to later add them to the configuration of your identity provider.

Click Save. Your new configuration will then appear in the configuration overview.

To finish your setup, add the information you copied earlier into your access management tool.

You're able to edit or delete your SSO configuration by clicking on the icons on the right side of the screen.

Add SSO users to Foleon from the dashboard

When you've set up SSO for the Foleon platform and you're an admin of your account, you can add SSO users right from the dashboard. 

How it works depends on which login methods you decide to support:

• • Let users only log in with SSO 🔐
    In this case, users can only log in with SSO. Having an email address of the user is enough, you can't fill in their first and last name — this happens automatically later.
    
    When you invite a new user on the users page, you'll see the pop-up window from the screenshot below. After inviting the user, they can start using Foleon immediately. 
    
    
    
    
  • Let users also log in with their email address and password (next to SSO) 💁‍♀️
    In this case, users have two login methods: log in using SSO or log in with their email address and password. 
    
    When you invite a new user on the users page, you'll see a checkbox that says "User can log in with SSO". If you check this box, the new user can only log in with SSO. This means they won't receive an account activation link and won't be able to create a password.
    
    

When you've set up SSO for the Foleon platform, you still support email address and password login, and you've added SSO users, admins will see a blue exclamation mark next to the initials of a user. In addition to the SSO login method, these users can also access Foleon with their email address and password.

This helps admins keep track of who can log in with which method, making it easier to perform user management based on the login method. For example, removing users who log in with their email address and password. 

Switching to an SSO setup

For Foleon customers, it's common that users log in with their email addresses and password. 

If you later decide to enable SSO for the Foleon platform — making logging in easy and secure for your team — you'll need to consider what to do with existing users. You have two options as an admin:

• • Give users a choice of how to log in 💁‍♀️
    In this case, users have two login methods: log in using SSO or log in with their email address and password. 
    
    If you go with this approach, you don't need to do anything else. Users that can log in with two different methods only count as one toward your total user count. 
    
    
  • Let users only log in with SSO only 🔐
    In this case, users can only log in with SSO. 
    
    If you already have existing users that log in with their username and password, admins can delete these users and add them again as SSO users.
    
    Alternatively, you can ask your Customer Success Manager to disable the email address and password login method for you. When doing this, no one will be able to log in with their email address and password. 

Logging in with SSO

Before users can log in to the Foleon platform with SSO, there are three requirements you need to meet:

1. You need to have SSO for the Foleon platform set up (as described in this article)
2. The user's email address is known to Foleon, because they were added as a user
3. Your IDP allows the user (and their email address) to log in to Foleon with SSO

Once you meet these requirements as a user, you're able to log in through your company's SSO solution. Alternatively, log in on the Foleon login page by clicking log in with single sign-on (SSO). 

If the email address is registered with Foleon as belonging to a user that can log in to Foleon with SSO, Foleon will redirect the user to the identity provider's (IDP) login page (e.g., "Log in with your Google account" or "Log in with your Microsoft Azure Active Directory account").

Set up automatic user provisioning with SCIM

With SCIM 2.0 — System for Cross-domain Identity Management — user updates made in your identity provider (IdP) will automatically be reflected in Foleon.

This means that when users are added or removed from your IdP, their access to Foleon will be updated accordingly. This eliminates the need to update multiple systems and ensures that only authorized users can access your Foleon account.

In order to set up SCIM, you must take the following steps: 

1. Decide in which workspace new users should end up
   If you're working with multiple workspaces, you first need to decide which workspace your users should become a part of. By default, it's the main workspace. If you want to set up SCIM for a regular workspace, the API SCIM token must be generated accordingly by Foleon.
   
   
2. Get the SCIM credentials from Foleon
   When you've settled on which workspace to set up SCIM for, contact the Foleon Support team and pass on your information. Not sure how to contact Support? Check out this article. 
   
   With help from our development team, we will provide you with a SCIM API token and SCIM URL. 
   
   
3. Set up SCIM in the identity provider (IdP)
   

   Next, you must set up the SCIM profile on the identity provider (IdP) side. Make sure you have set up SSO for the Foleon platform first — as described in the article above.
   
   The process for setting up provisioning depends on the IdP. If you need any assistance with this, we recommend reaching out to your IT department or your IdP supplier. 
   
   As part of the setup process with your IdP, you'll need to choose which provisioning functions to use. Make sure at least the following functions are enabled: create users and deactivate users.

   That's it: now, if a user is added or removed from the IdP, Foleon will automatically create or delete a Foleon user account.

   💡Foleon's SCIM feature doesn't support user role assignment or workspace membership assignment through SCIM. You can assign users a role in the Foleon dashboard — not in your IdP.

   
   
4. Change 'admins' to 'SCIM admins' (optional)
   Eligible customers have an additional role available to them in the role dropdown on the users page: SCIM Admin. This role is the same as the regular admin role, except it can't create or delete user accounts.
   
   This is recommended for all customers that use SCIM, to help admins remember that SCIM takes care of user creation and deletion. 
   

FAQ

• Once we enable SSO, what happens to the currently active native users in our account?

  It depends on if you want to let your users only log in with SSO or let them log in with their email address and password as well. Read the section Switching to an SSO setup for all information. 

• If SSO has been enabled for the Foleon platform, is it still possible to create non-SSO users?
  Yes, this is possible — remember, they will count toward the total user count. The same applies to when you're using workspaces.

• If we enable SSO, is there any impact on the projects that currently active native users have set up?

  No, there's no impact.

• Is a user migration or mapping required before enabling SSO?

  No, unless you need people to be forced into a specific workspace.

• Are there any permissions-related changes we need to make before we enable SSO?

  No, we don't believe there are any.