Configuring SAML Single Sign-On (SSO) with Okta for Pluto

Set up Okta SAML 2.0 SSO for Pluto

Introduction

Pluto supports SAML 2.0-based Single Sign-On (SSO), allowing users to log in through an organization’s Identity Provider (IdP)​. This means you can use your company’s internal Okta credentials to access Pluto, rather than separate Pluto-specific passwords. Once SAML SSO is set up, users will be required to sign in via Okta, enabling your organization to enforce its own security policies (password complexity, multi-factor authentication, etc.) for Pluto access. Okta can serve as the IdP in this setup, since Pluto can integrate with any provider that implements the SAML 2.0 protocol​. Using SAML SSO with Okta has several benefits:

• Centralized Authentication: Users authenticate with the same Okta credentials they use for other enterprise apps, simplifying login management.
• Enhanced Security: Your existing IT policies (MFA, password rotation, IP restrictions, etc.) automatically apply to Pluto logins​.
• Streamlined User Management: Access to Pluto can be managed via Okta—when a user is added or removed in Okta, their Pluto access follows accordingly, reducing administrative overhead.

In the sections below, we’ll walk through configuring Okta as the SAML IdP for Pluto, sending the Okta SAML metadata to Pluto, and enabling SSO for all Pluto users. Screenshots are included to illustrate the process step-by-step.

Step-by-step configuration in Okta

To integrate Pluto with Okta via SAML, you will create a SAML 2.0 application in your Okta Admin Console and input Pluto’s SSO details. Follow these steps:

1. Create a new SAML app in Okta: Log in to your Okta Admin Console, and navigate to the Applications section. Click the Create App Integration button​. (In the Okta navigation menu, the Applications tab is where you manage and add applications.) This will open a dialog to create a new app integration.
   
2. Select SAML 2.0 as the sign-in method: In the Create a new app integration dialog, choose SAML 2.0 as the Sign-in method​ and click Next. Okta supports multiple SSO methods (like OpenID Connect and OIDC, SWA, etc.), but for Pluto you should select SAML, since Pluto uses the SAML 2.0 standard for SSO. After you click Next, Okta will take you to the app setup wizard for SAML integration.
   
3. General Settings – App name and logo: On the General Settings page of the Okta SAML integration wizard, enter an application name (for example, Pluto Bio) and upload a logo if desired. You can use Pluto’s logo for easy recognition (this step is optional). Ensure the App visibility settings are as desired (by default, the application icon will be visible to users in Okta). Then click Next to continue. (Giving the app a clear name like “Pluto Bio” will help you and your users identify it in Okta.)

   4.    Configure SAML Settings: On the Configure SAML screen, you will enter Pluto’s SSO details provided by Pluto. Fill in the fields as follows:

• • Single sign-on URL (ACS URL): https://api.pluto.bio/auth/social/complete/saml/
    . This is the Assertion Consumer Service (ACS) URL where Okta will send its SAML Response when a user logs into Pluto.
  • Check the option for “Use this for Recipient URL and Destination URL” (if present in Okta’s interface). This ensures the ACS URL is used correctly for the SAML response.
  • Audience URI (SP Entity ID): https://api.pluto.bio
    This is the Entity ID that identifies Pluto as the Service Provider. Make sure to enter it exactly as given (including the https:// prefix).
  • Default RelayState: Leave this blank (not required for Pluto unless instructed otherwise).
  • Name ID Format: EmailAddress​
    Select “EmailAddress” from the format drop-down. This tells Okta to format the SAML subject NameID as an email address.Configure SAML Settings: On the Configure SAML screen, you will enter Pluto’s SSO details provided by Pluto. Fill in the fields as follows:
  • Application Username: Email. Set the Application username format to user email as well. This pairs with the Name ID format so that the user’s email address is used as the SAML NameID sent to Pluto. (Okta will use the user’s Okta login email for the NameID by default when these are set.)
  • Okta SAML Settings – In this step, you input Pluto’s ACS URL and Entity ID into Okta’s SAML Settings form. In the example screenshot above, you can see where the Single sign-on URL and Audience URI (SP Entity ID) are configured (the values shown are just examples; use Pluto’s URLs as given). Ensure that the Name ID format is set to email and the Application username is mapped to the user’s email, so that the SAML assertion’s subject will be the user’s email address (this is required by Pluto)​. Okta might also show an option to allow other SSO URLs or to set a Recipient—use the default settings (with the Recipient checkbox checked) so that the ACS URL is used for all SAML responses. After filling in these fields, scroll down to Attribute Statements to configure user attribute mappings.
    

5.    Attribute Statements (Mappings): Pluto expects certain user attributes to be passed in the SAML response, so you will add three attribute statements in Okta for first name, last name, and email​. In the Attribute Statements section of Okta’s SAML settings, click Add Another (if needed) to create the following attribute mappings:

• • first_name – mapped to user.firstName
  • last_name – mapped to user.lastName
  • email – mapped to user.Email

Make sure to type the attribute names exactly as shown above (all lowercase, with an underscore) and select the corresponding Okta user profile fields from the dropdown for values. You can leave the Name format as Unspecified for each. Do not use namespace prefixes or URI formats in the attribute names; use simple names like "first_name" rather than a lengthy URI​.

Adding SAML attribute statements in Okta – The screenshot above shows an example of adding an attribute statement in Okta. (In this example, a generic email attribute is being added with a default schema URI, but for Pluto you should use the simple names specified, such as "email".) Ensure that first_name, last_name, and email are entered as the attribute names, and map each to the appropriate user profile value (e.g. user.firstName, user.lastName, user.email)​. These attributes will be sent to Pluto in the SAML response to populate the user’s profile. After entering all required fields and attribute statements, click Next to proceed.

• 

6.   Feedback and Finish: Okta will next show a Feedback step (sometimes labeled “Help Okta support understand how you configured this application”). Here, you can select “I’m an Okta customer adding an internal app” when asked about the type of integration, and check “It’s required to contact the vendor to enable SAML”​. (This simply informs Okta and the app vendor – Pluto – that SAML setup requires coordination.) On the feedback screen, as shown above, choose the options indicating this is an internal app for your organization and that you’ll contact the vendor to enable SAML. These selections won’t affect functionality, but they help document your integration​. Now click Finish to save the new SAML application. You should see your newly created “Pluto Bio” app in Okta’s applications list.

• 

At this point, the Okta side configuration is done. You have created a SAML 2.0 app in Okta with Pluto’s ACS URL, Entity ID, and attribute mappings. The next steps will be to provide Okta’s SAML metadata to Pluto and then verify the SSO connection.

Download and send metadata to Pluto

Now that your Okta SAML app is configured, you need to retrieve the Identity Provider (IdP) metadata from Okta and send it to Pluto for the integration to be completed. This metadata contains information Pluto needs (like Okta’s SSO URL, certificate, and entity ID) to trust Okta as an IdP.

• Download Okta metadata: In your Okta app’s settings, navigate to the Sign On tab for the Pluto SAML application. Here, look for a section or link for Identity Provider metadata. Okta provides a metadata URL or a downloadable metadata XML file for the IdP configuration​. Click the Identity Provider metadata link to download the metadata.xml file (or copy the metadata URL, if provided). This XML file contains Okta’s SAML configuration (issuer, certificate, endpoints) that Pluto will use to set up the trust. Save this file to your computer. (If you have trouble finding the metadata link, ensure your Okta app is saved. On the Sign On tab, you should see an “Identity Provider metadata” link or button – clicking it will either download an XML file or display the XML which you can save.)

Okta “Sign On” settings for the SAML app – On the Sign On tab of your Okta application, you’ll find the link to Identity Provider metadata (as highlighted above). Clicking this will allow you to download the metadata XML file containing your Okta IdP details. This file (often named metadata.xml) includes the information Pluto needs to finalize the SSO setup.

• Send metadata to Pluto: Once you have the Okta metadata file (or a URL to it), send it to the Pluto team. Pluto may have provided a form or a secure method for you to upload the SAML metadata​. Typically, your Pluto representative will send you a configuration form where you can attach the metadata XML or paste the metadata URL​. Fill out that form and submit it so that Pluto receives your Okta IdP metadata. (If you haven’t received a form, contact support@pluto.bio or your Pluto representative for instructions on how to send the SAML metadata.)
• Pluto enables SAML for testing: After you send the metadata to Pluto, the Pluto support team will enable SAML SSO on Pluto’s side for your account, initially for the admin user only​. This means Pluto will configure the trust with Okta using your metadata and turn on SSO, but restrict it to just the organization’s admin account at first to test the integration. You will be notified once this is done, so you can proceed with verification.

Note: For the initial SSO test, ensure that the Pluto admin user’s account exists in Okta and is assigned to the Pluto SAML application. In Okta, go to the Assignments tab for your Pluto app and verify that the admin’s Okta user is assigned (or that the app is set to auto-assign via group membership). If the admin user is not assigned in Okta, they will not be able to log in via SAML during testing. (Generally, you should assign all intended Pluto users to this Okta app now, or confirm that the app is set for all users in the organization, to avoid login issues later.)​

Verification and enforcing SAML for all users

With SAML enabled for the Pluto admin account, it’s time to verify that everything works, then roll it out to everyone.

• Verify SSO Login (Admin user): Pluto will provide your organization’s admin user with instructions to test the SSO login​. This usually involves the admin attempting to log in to Pluto via the SSO route. For example, the admin can go to the Pluto login URL specifically for SSO (which is usually https://app.pluto.bio/login/<your-org-slug> as noted in Pluto’s documentation​) – this will redirect to Okta for authentication. Upon entering their Okta credentials, the admin should be logged into Pluto. Alternatively, the admin can initiate the login from the Okta side by clicking the Pluto Bio app icon in their Okta dashboard (IdP-initiated SSO). Test both ways if possible, to ensure the integration is working. During this verification phase, Pluto support is checking that the SAML response from Okta is being accepted and that the user can successfully access their Pluto Lab Space via SSO.
• Ensure all users are ready: While testing, make sure that all users who need access to Pluto are set up in Okta and assigned to the Pluto SAML application. Any user not in Okta or not assigned to the app will not be able to log in once SAML is enforced. It’s a good idea to double-check the Okta Assignments for the Pluto app and add any missing users or groups. Additionally, Pluto will inform you of any existing Pluto users (by email domain) who had signed up with a password previously; those users will be switched to SSO after enforcement​. If someone had an individual Pluto account using their company email, they will need to use Okta SSO going forward, and Pluto can help merge or transition those accounts as needed.
• Enforce SAML for all users: After the admin confirms that SSO login works correctly for their account (and any initial issues are resolved), Pluto support will enable SAML SSO for all users in your organization​. This is the final step where SSO becomes mandatory for your Pluto organization. Once enforced, all login attempts for your organization’s Pluto workspace will redirect to Okta. Users navigating to Pluto’s login page will be prompted to use SSO, and upon entering their email (or choosing the organization), they’ll be sent to Okta to authenticate, then returned to Pluto upon success​. From this point on, standard email/password logins are disabled for your organization – everyone must use the Okta SSO. Ensure your team is informed of this change. Users should bookmark your Pluto login link or know to start from the Okta portal for access.
• Testing and confirmation: It’s recommended to do a few more tests once SAML is enforced for all. Have a couple of regular users (not just admin) try to log in via Okta SSO to confirm everything is smooth. If any user has trouble, verify their Okta account is properly assigned and that they’re using the correct login URL.

Once SAML is enforced and working for all, your Pluto SSO integration with Okta is complete. Your users can now enjoy a seamless login experience using Okta, and you benefit from centralized control over access.

Troubleshooting & Additional Notes

Setting up SAML SSO should be straightforward, but here are some common tips and issues to watch out for:

• Incorrect URL or Entity ID: If users encounter an error after authenticating (for example, “Invalid Audience” or “No service provider found”), double-check that the ACS URL and Audience URI in Okta exactly match what Pluto provided​. Typos or missing URLs will cause the SAML response to be rejected by Pluto. Ensure the ACS URL is https://api.pluto.bio/auth/social/complete/saml/ (with trailing slash) and the Entity ID is https://api.pluto.bio in Okta’s settings.
  
  
• NameID or Email Issues: Pluto requires the SAML NameID to be the user’s email address​. Make sure you set Okta’s Application Username to Email and Name ID Format to EmailAddress. You can verify what NameID Okta is sending by looking at the Okta System Log or using a SAML tracer. If the NameID isn’t the email, users will not be recognized by Pluto. Similarly, the user’s email in Okta must match their email in Pluto. If an email address is different (alias or corporate domain change), update either Okta or the Pluto user account so they match.
  
  
• User Not Assigned in Okta: If a user tries to log in and gets an Okta error like “App not assigned” or is not redirected at all, it often means they are not assigned to the Pluto application in Okta. Ensure every Pluto user is either individually assigned to the app or part of an Okta group that is assigned. During testing, this is a common issue for the admin account​ – so always verify assignments.
  
  
• Attribute Mappings: The additional attributes (first_name, last_name, email) are used by Pluto to create or update the user’s profile (so that names appear correctly in the Pluto interface). If these aren’t configured, the SSO may still work (as long as NameID is correct), but Pluto might not receive the user’s name info. If you notice that user profiles in Pluto lack names after SSO, check that your Okta SAML app is sending the first_name and last_name attributes correctly. Remember, no XML namespaces or custom URI in attribute names​ – use the exact names Pluto expects.
  
  
• Okta Groups (Optional): Pluto doesn’t explicitly require group information via SAML. However, you might use Okta groups to manage who is assigned to the Pluto app. All that matters for Pluto SSO is that the users are assigned and the required attributes are sent. If you do need to send group or role info in SAML (for advanced team provisioning), you’d coordinate that with Pluto separately (not covered in this basic setup).
  
  
• Testing IdP-Initiated vs SP-Initiated SSO: Okta supports both flows. IdP-initiated means a user can launch Pluto from the Okta dashboard (after logging into Okta, clicking the Pluto app icon will log them in to Pluto). SP-initiated means a user can go to Pluto (e.g., Pluto login page) and be redirected to Okta. Both should work with this configuration. If one method isn’t working, focus on the error message. For example, if IdP-initiated login from Okta fails, ensure the Audience URI (Entity ID) is correct and that Pluto has that exact Entity ID on file. If SP-initiated login fails to redirect properly, ensure you’re using the correct Pluto login URL format for SSO (which includes your organization slug).
  
  

Still having issues? If you’ve double-checked the configuration and users still cannot log in, collect some information to help diagnose the problem. In Okta, check the System Log for any SAML-related errors when a login is attempted. Common errors will often tell you what’s wrong (e.g., “Unknown User”, “Invalid Response Signature”, etc.). Similarly, Pluto may provide an error message on the login screen if something is misconfigured. Most issues come down to metadata mismatches (certificate or Entity ID), incorrect credentials, or user assignment problems. Don’t hesitate to reach out to Pluto Support for help by emailing support@pluto.bio with the details of the error and we can assist in troubleshooting the SAML setup.