What Was PLTW in the Legacy Platform?

Project Lead The Way (PLTW) is a nonprofit organization that provides STEM education curricula to schools across the United States. As a SolidProfessor customer, PLTW needed their users to be able to log in to SolidProfessor using their existing organizational credentials — a feature known as Single Sign-On (SSO).

How It Worked in the Legacy App

In the old SolidProfessor platform, the engineering team built a dedicated, custom-coded login flow specifically for PLTW. Here's what the experience looked like:

1. A user visiting SolidProfessor would see a special "Login with PLTW" button on the login page.
2. Clicking that button redirected the user to PLTW's Okta instance (their identity provider) to enter their credentials.
3. After successful authentication, the user was redirected back to SolidProfessor and automatically provisioned with a 1-year access plan.

The Problem with This Approach

While it worked for PLTW, this approach had serious limitations:

• Every new SSO customer required custom code. If another organization wanted the same login experience, engineers had to write new code, test it, and deploy it — a process that could take days or weeks.
• Each integration was hardcoded. PLTW's Okta endpoints, redirect URLs, and provisioning logic were written directly into the application source code.
• It didn't scale. Supporting 5 SSO customers meant maintaining 5 separate custom integrations, each with its own code paths and potential for bugs.

How SSO Works in Platform 2.0

Platform 2.0 takes a fundamentally different approach to SSO. Instead of writing custom code for each customer, we built a generic, configurable SAML SSO system that works with any identity provider right out of the box.

Legacy vs. Platform 2.0: A Comparison

How It Works at a High Level

1. Customer's IT team configures their identity provider (Okta, Microsoft Entra ID, Google Workspace, etc.) with SolidProfessor's SAML metadata — essentially telling their system where to send authenticated users.
2. A SolidProfessor admin enters the customer's metadata into platform-admin — telling our system where to verify incoming users from that organization.
3. Users log in via SSO. When a user enters their email on SolidProfessor's login page, the system detects their email domain, routes them to their organization's identity provider, and — after successful authentication — automatically provisions them into the correct company account.

Why We Don't Need a PLTW Integration in 2.0

The generic SAML SSO system in Platform 2.0 handles everything that the legacy PLTW custom integration did — and more. Here's a direct comparison of each feature:

What This Means for the Team

• No engineering bottleneck. SSO setup moves from a developer task to an admin task. The engineering team doesn't need to be involved for each new SSO customer.
• Faster onboarding. New SSO customers can be configured and live in the same day, rather than waiting for a development cycle.
• Less maintenance. One generic system to maintain instead of multiple custom integrations, each with their own potential issues.
• Better scalability. Whether we have 5 or 500 SSO customers, the system works the same way.

How We'd Set Up PLTW (or Any Okta Customer) Today

If PLTW — or any new customer using Okta — needed SSO access to SolidProfessor today, here's how the setup would work. No code changes. No deployments. Just configuration.

1. Create the account in platform-admin.
   Set up the customer's organization in platform-admin and select SAML as the onboarding strategy. This tells the system that users from this account will authenticate via SSO.
2. Add the customer's email domain(s).
   Enter the email domains associated with the organization (e.g., pltw.org). This is how the system knows to route users to the correct identity provider when they enter their email address.
3. Send the customer our SAML details.
   Provide the customer's IT team with our ACS URL (Assertion Consumer Service URL) and Entity ID. They'll need these to configure their Okta instance to trust SolidProfessor.
4. Receive their Okta metadata URL.
   The customer's IT team will provide their Okta metadata URL after configuring the SAML application on their side.
5. Configure SAML connection details in platform-admin.
   Enter the following into the account's SAML configuration:
   • Identity — the identity provider name
   • IDP Identifier — from the customer's metadata
   • Client ID — from the AWS Cognito app client
   • Client Secret — from the AWS Cognito app client
6. Done.
   Users with @pltw.org email addresses are now automatically routed to PLTW's Okta instance for authentication. After they log in, they're provisioned into the correct SolidProfessor account.

Summary & Key Takeaways

The legacy SolidProfessor platform required custom, hardcoded integrations for every SSO customer. Platform 2.0 replaces that approach with a standards-based, configurable system that makes SSO accessible to any organization.

• PLTW doesn't need a dedicated integration. The generic SAML SSO system covers everything PLTW's custom integration did, plus it supports any other SAML-compatible identity provider.
• Any SAML 2.0 identity provider works. Okta, Microsoft Entra ID, Google Workspace, and hundreds of others — if it supports SAML 2.0, it works with Platform 2.0.
• Setup is configuration, not code. No deployments, no engineering sprints. A SolidProfessor admin can configure a new SSO customer through platform-admin.
• User provisioning is built in. Auto-creating user accounts and assigning them to the correct company is part of the SAML login flow — no separate provisioning step needed.
• The system scales. The same configuration process works whether we're supporting 1 SSO customer or 100. Each one is just another entry in platform-admin.