diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..a60bb20
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,180 @@
+
+
+
+
+
+# Hub Documentation
+
+This rule can be found [here](.cursor/rules/hub-documentation.md)
+
+
+name: hub_documentation
+description: Standards for creating and maintaining hub documentation guides
+
+filters:
+ - type: file_extension
+ pattern: "\\.mdx$"
+ - type: path
+ pattern: "^connection-guides/"
+
+actions:
+ - type: validate
+ conditions:
+ - pattern: "^---\ntitle:.*\ndescription:.*\n---"
+ message: "Each guide must start with frontmatter containing title and description"
+ - pattern: "import IntegrationFooter.*"
+ message: "Must import and use IntegrationFooter component"
+ - pattern: ".*"
+ message: "Must use Steps component for integration instructions"
+
+ - type: suggest
+ message: |
+ Hub documentation guides must follow this structure:
+
+ 1. File Location:
+ - Place directly in connection-guides/{category}/{integration-name}.mdx
+ - Use kebab-case for filenames
+ - Categories: ats, documents, hris, iam, lms, marketing, screening, crm
+ - IMPORTANT: Do NOT place in docs/hubs/{category}/ - place directly in the category folder
+
+ 2. Required Frontmatter:
+ ```mdx
+ ---
+ title: "Integration Name"
+ description: "Follow these steps to connect {Integration} via the StackOne Hub successfully."
+ ---
+ ```
+
+ 3. Required Imports:
+ ```mdx
+ import IntegrationFooter from "/snippets/integration-footer.mdx"
+ ```
+
+ 4. Standard Sections:
+ - Warning (if applicable)
+ - Introduction paragraph
+ - Authentication steps in component
+ - IntegrationFooter
+ - Available data section
+
+ 5. Authentication Patterns:
+ - OAuth
+ - API Key
+ - Service Account
+ - Partner OAuth
+ Each pattern has specific required steps
+
+ 6. Image Guidelines:
+ - Store in /images/{integration-name}/
+ - Use descriptive kebab-case names
+ - Include in components
+ - Add alt text and className
+
+ 7. **Link Validation Requirements:**
+ - Test ALL external links before adding them to documentation
+ - Verify links are accessible and return expected content
+ - Check that API documentation links are still valid
+ - Ensure provider website links are working
+ - Test any download links or resource links
+ - If a link is broken, either find an alternative or remove it
+ - Consider adding link checking to your documentation workflow
+
+ 8. **Linking Section Guidelines:**
+ - Use generic language like "your platform" or "the integration platform" instead of "StackOne"
+ - Focus on the provider's perspective and what they need to do
+ - Avoid mentioning specific product names in the linking steps
+ - Example: "Navigate to the Integrations page in your platform" instead of "Navigate to StackOne Hub"
+
+ 9. **Integration Index Entry:**
+ - After creating a new guide, add an entry in `integrations.mdx` that redirects or links to the new guide.
+ - Example:
+ ```mdx
+ - name: OneDrive
+ href: /connection-guides/documents/onedrive
+ ```
+ - This ensures the new integration is discoverable in the documentation index.
+
+ - type: validate
+ conditions:
+ - pattern: "- name: [Ii]ntegration\\s*Name\\s*\\n\\s*href: \\/connection-guides\\/[a-z-]+\\/[a-z-]+"
+ path: "integrations.mdx"
+ message: "A new entry must be added to integrations.mdx with a redirect or link to the new guide."
+
+examples:
+ - input: |
+ ---
+ title: "Example Integration"
+ description: "Follow these steps to connect Example via the StackOne Hub successfully."
+ ---
+
+ import IntegrationFooter from "/snippets/integration-footer.mdx"
+
+
+ Required permissions or prerequisites
+
+
+ Introduction paragraph explaining the integration process.
+
+
+
+ Instructions for first step
+
+
+ 
+
+
+
+
+ ## Linking your Provider Account
+
+ Now that you have all the required information, you can link your account.
+
+
+
+ Navigate to the Integrations page in your platform.
+
+
+
+ Search for the integration name in the list of available integrations and click on it.
+
+
+
+ Fill in the required fields with the information you gathered.
+
+
+
+ Click Test Connection to verify the connection, then click Save to complete the integration.
+
+
+
+
+
+ ## Available data
+
+ This integration has the following [CATEGORY Resources](mdc:https:/docs.stackone.com/reference/getting-started-with-your-api) available from the provider:
+
+ - Resource1
+ - Resource2
+
+
+ # integrations.mdx
+ - name: Example
+ href: /connection-guides/documents/example
+ output: "Valid hub documentation guide and index entry"
+
+metadata:
+ priority: high
+ version: 1.3
+ category: documentation
+ applies_to: ["connection-guides/**/*.mdx", "integrations.mdx"]
+
+
+
+
+# Cursor Rules Location
+
+>Standards for placing Cursor rule files in the correct
+This refers to: *.mdc
+
+Read the full rule [here](.cursor/rules/cursor-rules-location.md)
+
diff --git a/connection-guides/lms/docebo.mdx b/connection-guides/lms/docebo.mdx
index c0b8548..7e1b966 100644
--- a/connection-guides/lms/docebo.mdx
+++ b/connection-guides/lms/docebo.mdx
@@ -3,6 +3,8 @@ title: "Docebo"
description: "If you've been directed to StackOne to integrate with Docebo, the following steps will help you understand the process and any necessary actions to configure successful integration."
---
+import IntegrationFooter from "/snippets/integration-footer.mdx";
+
This guidance assumes you have Admin privileges for your Docebo account.
@@ -127,3 +129,5 @@ description: "If you've been directed to StackOne to integrate with Docebo, the
+
+
diff --git a/integration-configuration-concepts.mdx b/integration-configuration-concepts.mdx
index ec62524..a3cb095 100644
--- a/integration-configuration-concepts.mdx
+++ b/integration-configuration-concepts.mdx
@@ -34,4 +34,11 @@ import { IntegrationTile } from '/snippets/integration-tile.mdx';
-
\ No newline at end of file
+
+
+## IDP Configuration for SSO
+
+
+
+
+
diff --git a/integration-configuration-concepts/idp/azure-ad-sso-configuration.mdx b/integration-configuration-concepts/idp/azure-ad-sso-configuration.mdx
new file mode 100644
index 0000000..fd90aef
--- /dev/null
+++ b/integration-configuration-concepts/idp/azure-ad-sso-configuration.mdx
@@ -0,0 +1,233 @@
+---
+title: "Azure AD (Microsoft Entra ID) SSO Configuration"
+description: "Configure custom SSO attributes in Azure AD for LMS integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx";
+import LMSIdentifiers from "/snippets/lms-identifiers.mdx";
+
+
+ Ensure that your Azure AD account has **Global Administrator** or **Application Administrator** privileges.
+
+
+This guide explains how to configure custom SSO attributes (such as `lms_user_id`) in Azure AD (Microsoft Entra ID) that can be used with LMS integrations. These attributes allow you to map user identities between your platform and the LMS provider.
+
+## Access Azure AD Admin Center
+
+
+
+ Log in to the Azure AD Admin Center at https://aad.portal.azure.com/
+
+
+ 
+
+
+
+
+ In the left navigation menu, click on **Enterprise applications**.
+
+
+ 
+
+
+
+
+ Find and click on the application that will be used for SSO with your LMS integration.
+
+ If you haven't created an application yet, click **New application** and either:
+ - Search for your LMS in the Azure AD Gallery
+ - Create a **Non-gallery application** for custom SAML configuration
+
+
+
+## Configure Single Sign-On
+
+
+
+ In your application's overview page, click on **Single sign-on** in the left menu.
+
+
+ 
+
+
+
+
+ Choose **SAML** as your single sign-on method if not already selected.
+
+
+ 
+
+
+
+
+ Complete the basic SAML configuration with your LMS-specific URLs (if not already configured):
+ - **Identifier (Entity ID)**: Your LMS entity ID
+ - **Reply URL (Assertion Consumer Service URL)**: Your LMS ACS URL
+ - **Sign on URL**: Your LMS SSO URL
+
+
+
+## Configure User Attributes & Claims
+
+
+
+ In the SAML configuration page, find the **Attributes & claims** section and click **Edit**.
+
+
+ 
+
+
+
+
+ Click **Add new claim** to create a custom attribute for your LMS integration.
+
+ Configure the new claim with:
+ - **Name**: `lms_user_id` (or the specific attribute name required by your LMS)
+ - **Namespace**: Leave blank or use your organization's namespace
+ - **Source**: User attribute
+ - **Source attribute**: Choose from available options:
+ - `user.userprincipalname` - for email-based identifiers
+ - `user.objectid` - for Azure AD object ID
+ - `user.mail` - for email address
+ - `user.employeeid` - for employee ID
+ - Custom extension attribute (see next section)
+
+
+ The exact attribute name and source will depend on your specific LMS requirements. Common LMS platforms may require different configurations:
+ - Docebo: Often uses `user.userprincipalname` or `user.mail`
+ - Cornerstone: May require `user.employeeid` or custom identifier
+ - SAP SuccessFactors: Typically uses `user.userprincipalname`
+
+
+
+
+ If your LMS integration requires additional user attributes, repeat the previous step:
+
+ Common additional claims include:
+ - **givenname**: `user.givenname`
+ - **surname**: `user.surname`
+ - **emailaddress**: `user.mail`
+ - **employeeid**: `user.employeeid`
+ - **department**: `user.department`
+ - **jobtitle**: `user.jobtitle`
+
+
+
+ Click **Save** to apply your attribute and claims configuration.
+
+
+
+## Configure Custom User Attributes
+
+If you need to use custom attributes that aren't available in the default Azure AD user schema:
+
+
+
+ In the Azure AD Admin Center, go to **App registrations** and find your application.
+
+
+
+ Go to **Manifest** and add custom extension properties, or use Azure AD B2C custom attributes if applicable.
+
+ Alternatively, you can populate standard fields like `extensionAttribute1` through `extensionAttribute15` via:
+ - PowerShell commands
+ - Microsoft Graph API
+ - Azure AD Connect (for on-premises sync)
+
+
+
+ Populate the custom attributes for your users using one of these methods:
+
+ **Via PowerShell:**
+ ```powershell
+ Set-AzureADUser -ObjectId "user@domain.com" -ExtensionProperty @{"extensionAttribute1"="LMS123456"}
+ ```
+
+ **Via Microsoft Graph API:**
+ ```http
+ PATCH https://graph.microsoft.com/v1.0/users/{user-id}
+ {
+ "extensionAttribute1": "LMS123456"
+ }
+ ```
+
+
+
+ Return to your application's **Attributes & claims** and create a new claim mapping to `user.extensionattribute1` (or your chosen extension attribute).
+
+
+
+## Test SSO Configuration
+
+
+
+ In your application settings, go to **Users and groups** and assign a test user to the application.
+
+
+
+ Use the **Test** option in the SAML configuration or initiate SSO from your LMS to verify the configuration.
+
+
+ 
+
+
+
+
+ Check the SAML response to ensure that your custom `lms_user_id` and other configured attributes are present with the expected values.
+
+
+
+## Configure Conditional Access (Optional)
+
+
+
+ In Azure AD, go to **Security > Conditional Access** to set up policies for your LMS application.
+
+
+
+ Create a new policy to control access to your LMS based on conditions like:
+ - User or group membership
+ - Device compliance
+ - Location
+ - Risk levels
+
+
+
+ In the policy settings, select your LMS application under **Cloud apps or actions**.
+
+
+
+## Linking with Your LMS Integration
+
+Now that you have configured the custom SSO attributes in Azure AD, you can reference these in your LMS integration setup:
+
+
+
+ Navigate to the integration configuration page for your specific LMS platform.
+
+
+
+ In the SSO or user mapping section of your LMS integration, specify:
+ - **SSO Attribute Name**: `lms_user_id` (or the claim name you configured in Azure AD)
+ - **LMS Field**: The corresponding field in your LMS (varies by platform)
+
+
+
+ Perform a test sync or SSO login to verify that users are being correctly identified and mapped between systems.
+
+
+
+
+
+## LMS-Specific Attribute Requirements
+
+Different LMS platforms may require specific attribute names or claim formats:
+
+
+
+### Troubleshooting
+- Ensure claim names match exactly between Azure AD and your LMS configuration
+- Verify that all required claims are mapped and have values for your users
+- Check SAML assertion format and namespace usage
+- Confirm that users have the necessary attribute values populated in their Azure AD profiles
+- Use Azure AD sign-in logs to debug SSO issues and view SAML token contents
\ No newline at end of file
diff --git a/integration-configuration-concepts/idp/google-workspace-sso-configuration.mdx b/integration-configuration-concepts/idp/google-workspace-sso-configuration.mdx
new file mode 100644
index 0000000..fba508a
--- /dev/null
+++ b/integration-configuration-concepts/idp/google-workspace-sso-configuration.mdx
@@ -0,0 +1,255 @@
+---
+title: "Google Workspace SSO Configuration"
+description: "Configure custom SSO attributes in Google Workspace for LMS integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx";
+import LMSIdentifiers from "/snippets/lms-identifiers.mdx";
+
+
+ Ensure that your Google Workspace account has **Super Administrator** privileges.
+
+
+This guide explains how to configure custom SSO attributes (such as `lms_user_id`) in Google Workspace that can be used with LMS integrations. These attributes allow you to map user identities between your platform and the LMS provider.
+
+## Access Google Admin Console
+
+
+
+ Log in to your Google Admin Console at https://admin.google.com/
+
+
+
+
+
+
+
+ In the left navigation menu, click on **Apps > SAML apps**.
+
+
+
+
+
+
+
+ Find and click on the SAML application that will be used for SSO with your LMS integration.
+
+ If you haven't created a SAML app yet, click the **+** (plus) button to **Add a service/App** and choose **Add custom SAML app**.
+
+
+
+## Configure Custom User Attributes
+
+
+
+ Before configuring the SAML app, you need to set up custom user attributes.
+
+ Go to **Directory > Users** and click on any user to see the profile structure.
+
+
+
+ If you need custom attributes beyond the standard Google Workspace fields:
+
+ 1. Go to **Directory > Directory settings > Custom attributes**
+ 2. Click **Add custom attribute**
+ 3. Configure:
+ - **Category**: Create or select a category (e.g., "LMS Integration")
+ - **Name**: `lms_user_id` or your desired attribute name
+ - **Info type**: Text (single value)
+ - **Visibility**: Visible to admin and user
+ - **No. of values**: Single value (most common)
+
+
+ Google Workspace provides standard user profile fields that are often sufficient:
+ - Primary email address
+ - Employee ID
+ - Employee type
+ - Department
+ - Manager email
+ - Custom schemas for additional fields
+
+
+
+
+ Ensure that the attribute you plan to use (custom or standard) is populated for your users:
+
+ - Via Admin Console: **Directory > Users** > Select user > Edit profile
+ - Via Google Admin SDK API
+ - Via CSV import/export
+ - Via Google Cloud Directory Sync (GCDS) for on-premises integration
+
+
+
+## Configure SAML Application Attributes
+
+
+
+ In your SAML app settings, click **Edit Service** or go to the app configuration.
+
+
+
+
+
+
+
+ Ensure your LMS service provider details are correctly configured:
+ - **ACS URL**: Your LMS Assertion Consumer Service URL
+ - **Entity ID**: Your LMS entity identifier
+ - **Start URL**: Your LMS SSO initiation URL (optional)
+
+
+
+ In the **Attribute mapping** section, click **Add mapping** and configure:
+
+ **For Primary User Identifier:**
+ - **Google Directory attribute**: Choose from:
+ - Primary email
+ - Employee ID
+ - Custom attribute you created
+ - **App attribute**: `lms_user_id` (or the name expected by your LMS)
+ - **Attribute format**: Basic information (most common) or URI reference
+
+ **For Additional Attributes (Optional):**
+ Add mappings for other required fields:
+ - **First name**: Basic information > First name → `first_name`
+ - **Last name**: Basic information > Last name → `last_name`
+ - **Email**: Basic information > Primary email → `email`
+ - **Department**: Basic information > Department → `department`
+ - **Job title**: Basic information > Job title → `job_title`
+ - **Employee ID**: Basic information > Employee ID → `employee_id`
+
+
+
+ Set the **Name ID format** and **Name ID** based on your LMS requirements:
+ - **Name ID format**: Usually "EMAIL" or "UNSPECIFIED"
+ - **Name ID**: Map to the primary identifier (often Primary email)
+
+
+
+ Click **Save** to apply your SAML attribute configuration.
+
+
+
+## Advanced Custom Schema Configuration
+
+For complex LMS integrations requiring multiple custom fields:
+
+
+
+ Go to **Directory > Directory settings > Manage custom attributes**.
+
+ Click **Add custom attribute** and select **Add custom schema**.
+
+
+
+ Create a schema specifically for LMS integration:
+ - **Schema name**: "LMS_Integration"
+ - Add multiple fields as needed:
+ - `lms_user_id` (Text, single value)
+ - `lms_role` (Text, single value)
+ - `lms_groups` (Text, multi-value for multiple group memberships)
+ - `training_manager` (Email, single value)
+
+
+
+ Use the Admin SDK API or CSV import to populate these custom schema fields for your users:
+
+ ```json
+ {
+ "customSchemas": {
+ "LMS_Integration": {
+ "lms_user_id": "LMS123456",
+ "lms_role": "employee",
+ "lms_groups": ["engineering", "management"]
+ }
+ }
+ }
+ ```
+
+
+
+ In your SAML app attribute mapping, you can now reference:
+ - **Google Directory attribute**: Custom schema > LMS_Integration > lms_user_id
+ - **App attribute**: `lms_user_id`
+
+
+
+## Test SSO Configuration
+
+
+
+ Ensure your SAML application status is **ON** for the appropriate organizational units.
+
+
+
+
+
+
+
+ Use the **Test SAML login** feature in the Google Admin Console or test through your LMS SSO flow.
+
+
+
+ Check the SAML response to ensure your `lms_user_id` and other configured attributes are being transmitted with the expected values.
+
+ You can use browser developer tools or SAML debugging tools to inspect the response.
+
+
+
+## Configure Group-Based Access (Optional)
+
+
+
+ Go to **Directory > Groups** and create a group for LMS access (e.g., "LMS Users").
+
+
+
+ Add the appropriate users to this group who should have LMS access.
+
+
+
+ In your SAML app settings, under **Service status**, you can restrict access to specific organizational units or groups.
+
+
+
+ If your LMS supports group-based role assignment, you can add attribute mappings for group membership:
+ - **Google Directory attribute**: Group membership
+ - **App attribute**: `groups` or `roles`
+
+
+
+## Linking with Your LMS Integration
+
+Now that you have configured the custom SSO attributes in Google Workspace, you can reference these in your LMS integration setup:
+
+
+
+ Navigate to the integration configuration page for your specific LMS platform.
+
+
+
+ In the SSO or user mapping section of your LMS integration, specify:
+ - **SSO Attribute Name**: `lms_user_id` (or the attribute name you configured in Google)
+ - **LMS Field**: The corresponding field in your LMS (varies by platform)
+
+
+
+ Perform a test sync or SSO login to verify that users are being correctly identified and mapped between systems.
+
+
+
+
+
+## LMS-Specific Attribute Requirements
+
+Different LMS platforms may require specific attribute configurations:
+
+
+
+### Troubleshooting
+- Ensure attribute names match exactly between Google Workspace and your LMS configuration
+- Verify that all required attributes are mapped and have values for your users
+- Check that users are in the correct organizational unit with access to the SAML app
+- Use Google Admin Console's audit logs to debug SSO issues
+- Confirm that custom schema fields are properly populated for your users
+- Test with multiple users to ensure consistent attribute mapping
\ No newline at end of file
diff --git a/integration-configuration-concepts/idp/okta-sso-configuration.mdx b/integration-configuration-concepts/idp/okta-sso-configuration.mdx
new file mode 100644
index 0000000..4cca778
--- /dev/null
+++ b/integration-configuration-concepts/idp/okta-sso-configuration.mdx
@@ -0,0 +1,173 @@
+---
+title: "Okta SSO Configuration"
+description: "Configure custom SSO attributes in Okta for LMS integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx";
+import LMSIdentifiers from "/snippets/lms-identifiers.mdx";
+
+
+ Ensure that your Okta account has **Application Administrator**, **Organization Administrator**, or **Super Administrator** privileges.
+
+
+This guide explains how to configure custom SSO attributes (such as `lms_user_id`) in Okta that can be used with LMS integrations. These attributes allow you to map user identities between your platform and the LMS provider.
+
+## Access Okta Admin Dashboard
+
+
+
+ Log in to your Okta Admin Console at https://login.okta.com/
+
+
+ 
+
+
+
+
+ From the Okta Admin Dashboard, navigate to **Applications > Applications** in the left sidebar.
+
+
+ 
+
+
+
+
+ Find and click on the application that will be used for SSO with your LMS integration.
+
+ If you haven't created an application yet, click **Create App Integration** and follow the setup wizard to create a new SAML 2.0 or OIDC application.
+
+
+
+## Configure Custom User Attributes
+
+
+
+ In your application settings, click on the **Sign On** tab.
+
+
+ 
+
+
+
+
+ Scroll down to the **SAML Settings** section and click **Edit**.
+
+
+ 
+
+
+
+
+ In the SAML Settings page, scroll to the **Attribute Statements** section.
+
+ Click **Add Another** to create a new attribute statement with the following values:
+
+ - **Name**: `lms_user_id` (or the specific attribute name required by your LMS)
+ - **Name format**: `Unspecified` (recommended) or `URI Reference`
+ - **Value**: Choose the appropriate user attribute from the dropdown:
+ - `user.login` - for username/email
+ - `user.id` - for Okta user ID
+ - `user.email` - for user email address
+ - Custom expression or profile attribute as needed
+
+
+ The exact attribute name and value will depend on your specific LMS requirements. Common LMS platforms may require different attribute names such as:
+ - Docebo: `user.login` or `user.email`
+ - Cornerstone: `user.employeeNumber`
+ - SAP SuccessFactors: `user.login`
+
+
+
+
+ If your LMS integration requires additional user attributes, repeat the previous step to add them:
+
+ Common additional attributes include:
+ - **first_name**: `user.firstName`
+ - **last_name**: `user.lastName`
+ - **email**: `user.email`
+ - **employee_id**: `user.employeeNumber`
+ - **department**: `user.department`
+ - **role**: `user.title`
+
+
+
+ Click **Next** through the remaining steps and **Finish** to save your SAML configuration.
+
+
+
+## Configure User Profile Mapping
+
+If you need to use custom profile attributes that aren't available in the default Okta user schema:
+
+
+
+ In the Okta Admin Console, go to **Directory > Profile Editor**.
+
+
+
+ Find and click on the **User (default)** profile to edit the base user schema.
+
+
+
+ Click **Add Attribute** and configure:
+ - **Data type**: String (most common)
+ - **Display name**: Descriptive name (e.g., "LMS User ID")
+ - **Variable name**: Technical name (e.g., "lmsUserId")
+ - **Description**: Purpose of the attribute
+ - **Attribute required**: Set based on your requirements
+
+
+
+ Return to your application's **Sign On** settings and use the new custom attribute in your SAML attribute statements as `user.lmsUserId`.
+
+
+
+## Test SSO Configuration
+
+
+
+ In your application settings, go to the **Assignments** tab and assign a test user to the application.
+
+
+
+ Use Okta's **Preview SAML Response** feature or test the SSO flow through your LMS integration to verify that the custom attributes are being passed correctly.
+
+
+
+ Check that the `lms_user_id` and other configured attributes appear in the SAML response with the expected values.
+
+
+
+## Linking with Your LMS Integration
+
+Now that you have configured the custom SSO attributes in Okta, you can reference these in your LMS integration setup:
+
+
+
+ Navigate to the integration configuration page for your specific LMS platform.
+
+
+
+ In the SSO or user mapping section of your LMS integration, specify:
+ - **SSO Attribute Name**: `lms_user_id` (or the name you configured in Okta)
+ - **LMS Field**: The corresponding field in your LMS (varies by platform)
+
+
+
+ Perform a test sync or SSO login to verify that users are being correctly identified and mapped between systems.
+
+
+
+
+
+## LMS-Specific Attribute Requirements
+
+Different LMS platforms may require specific attribute names or values:
+
+
+
+### Troubleshooting
+- Ensure attribute names match exactly between Okta and your LMS configuration
+- Verify that all required attributes are mapped and have values for your users
+- Check SAML response format if using SAML-based SSO
+- Confirm that users have the necessary attribute values populated in their Okta profiles
\ No newline at end of file
diff --git a/integration-configuration-concepts/idp/onelogin-sso-configuration.mdx b/integration-configuration-concepts/idp/onelogin-sso-configuration.mdx
new file mode 100644
index 0000000..84a8b21
--- /dev/null
+++ b/integration-configuration-concepts/idp/onelogin-sso-configuration.mdx
@@ -0,0 +1,296 @@
+---
+title: "OneLogin SSO Configuration"
+description: "Configure custom SSO attributes in OneLogin for LMS integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx";
+import LMSIdentifiers from "/snippets/lms-identifiers.mdx";
+
+
+ Ensure that your OneLogin account has **Super User** or **Account Administrator** privileges.
+
+
+This guide explains how to configure custom SSO attributes (such as `lms_user_id`) in OneLogin that can be used with LMS integrations. These attributes allow you to map user identities between your platform and the LMS provider.
+
+## Access OneLogin Admin Portal
+
+
+
+ Log in to your OneLogin Admin Portal at https://[your-subdomain].onelogin.com/admin
+
+
+ 
+
+
+
+
+ In the top navigation menu, click on **Applications**.
+
+
+ 
+
+
+
+
+ Find and click on the application that will be used for SSO with your LMS integration.
+
+ If you haven't created an application yet, click **Add App** and either:
+ - Search for your LMS in the OneLogin App Catalog
+ - Create a **SAML Test Connector (IdP w/ attr)** for custom configuration
+
+
+
+## Configure Custom User Attributes
+
+
+
+ Before configuring SAML parameters, set up custom user attributes if needed.
+
+ Go to **Users > Custom User Fields** in the left navigation menu.
+
+
+ 
+
+
+
+
+ If you need a custom attribute beyond OneLogin's standard user fields, click **New User Field**:
+
+ - **Name**: `LMS User ID` (display name)
+ - **Short name**: `lms_user_id` (technical name)
+ - **Include in User Provisioning**: Check if you want to sync this field
+ - **Required for all users**: Set based on your requirements
+ - **Searchable**: Check for easier user management
+ - **Values**: Leave blank for free-text entry
+
+
+ OneLogin provides many standard user fields that might be sufficient for your needs:
+ - Username
+ - Email
+ - Employee ID
+ - Manager email
+ - Department
+ - Title
+ - Phone numbers
+ - Custom fields 1-10
+
+
+
+
+ Ensure that the attribute you plan to use is populated for your users:
+
+ - Via OneLogin Admin Portal: **Users** > Select user > Edit
+ - Via OneLogin API
+ - Via CSV import
+ - Via directory sync (AD, LDAP, Google Directory, etc.)
+
+
+
+## Configure SAML Parameters
+
+
+
+ In your application settings, click on the **Parameters** tab.
+
+
+ 
+
+
+
+
+ Click the **+** button to add a new parameter for your LMS user identifier:
+
+ **Parameter Configuration:**
+ - **Field name**: `lms_user_id` (or the attribute name expected by your LMS)
+ - **Flags**:
+ - Check **Include in SAML assertion**
+ - Check **Multi-value** if the attribute can have multiple values
+ - **Default if no value selected**: Leave blank or set a default
+ - **Transform using macro**: Configure the source of the data
+
+
+ Common macro values for LMS integrations:
+ - `{user.username}` - OneLogin username
+ - `{user.email}` - User's email address
+ - `{user.employee_id}` - Employee ID field
+ - `{user.custom_field_lms_user_id}` - Custom field you created
+ - Static value or combination of fields
+
+
+
+
+ In the **Value** field, specify how to populate this parameter:
+
+ **Examples:**
+ - **For email-based identifier**: `{user.email}`
+ - **For employee ID**: `{user.employee_id}`
+ - **For custom field**: `{user.custom_field_lms_user_id}`
+ - **For username**: `{user.username}`
+ - **For combination**: `{user.firstname}.{user.lastname}@{user.company}`
+
+
+
+ Create additional parameters as needed by your LMS:
+
+ Common additional parameters:
+ - **first_name**: `{user.firstname}`
+ - **last_name**: `{user.lastname}`
+ - **email**: `{user.email}`
+ - **department**: `{user.department}`
+ - **title**: `{user.title}`
+ - **manager**: `{user.manager_email}`
+ - **groups**: `{user.role}` or custom group mapping
+
+
+
+ Click **Save** to apply your parameter configuration.
+
+
+
+## Configure SAML Assertion Settings
+
+
+
+ Click on the **SSO** tab to configure SAML assertion details.
+
+
+ 
+
+
+
+
+ Ensure your SAML settings are configured for your LMS:
+ - **SAML Consumer URL**: Your LMS Assertion Consumer Service URL
+ - **SAML Audience**: Your LMS entity ID
+ - **SAML Recipient**: Usually the same as Consumer URL
+ - **SAML Validator**: Usually the same as Audience
+
+
+
+ Configure the **Name ID** format based on your LMS requirements:
+ - **Name ID format**: Choose from Email, Username, UUID, etc.
+ - **Name ID value**: Map to your primary identifier (often `{user.email}` or `{user.username}`)
+
+
+
+## Configure Role and Group Mappings
+
+
+
+ Click on the **Rules** tab to set up conditional logic for attribute mapping.
+
+
+
+ If you need conditional attribute mapping based on user properties:
+
+ - **Name**: Descriptive name for the rule
+ - **Enabled**: Check to activate the rule
+ - **Conditions**: Set conditions based on user attributes
+ - **Actions**: Define what attributes to set when conditions are met
+
+
+
+ If your LMS requires role or group information:
+
+ 1. Go to **Users > Groups** to manage user groups
+ 2. In your application **Parameters**, add a group parameter
+ 3. Use macros like `{user.role}` or custom group logic
+
+
+
+## Test SSO Configuration
+
+
+
+ Go to **Users** and assign a test user to your LMS application:
+
+ 1. Select the user
+ 2. Click **Applications** tab
+ 3. Click **+** to add your LMS application
+
+
+
+ Use OneLogin's **Test** functionality or initiate SSO from your LMS:
+
+ 1. In your application settings, click **More Actions > Test**
+ 2. Or use the OneLogin portal to launch the application
+
+
+ 
+
+
+
+
+ Check the SAML response to ensure your `lms_user_id` and other configured parameters are present:
+
+ - Use browser developer tools to inspect the SAML POST
+ - Check OneLogin's event logs under **Events**
+ - Use SAML debugging tools to decode the assertion
+
+
+
+## Advanced Configuration Options
+
+
+
+ For complex scenarios, you can use OneLogin's **Smart Hooks** or **Mappings** features:
+
+ - **Smart Hooks**: JavaScript-based pre and post authentication hooks
+ - **Mappings**: Advanced rules for transforming user attributes
+
+
+
+ Use OneLogin's API to programmatically update user attributes:
+
+ ```bash
+ curl -X PUT "https://api.us.onelogin.com/api/1/users/{user_id}" \
+ -H "Authorization: Bearer {access_token}" \
+ -H "Content-Type: application/json" \
+ -d '{"custom_field_lms_user_id": "LMS123456"}'
+ ```
+
+
+
+ If your LMS supports SCIM provisioning, configure it under the **Provisioning** tab:
+
+ - Enable provisioning
+ - Map OneLogin fields to LMS fields
+ - Set up real-time user updates
+
+
+
+## Linking with Your LMS Integration
+
+Now that you have configured the custom SSO attributes in OneLogin, you can reference these in your LMS integration setup:
+
+
+
+ Navigate to the integration configuration page for your specific LMS platform.
+
+
+
+ In the SSO or user mapping section of your LMS integration, specify:
+ - **SSO Attribute Name**: `lms_user_id` (or the parameter name you configured in OneLogin)
+ - **LMS Field**: The corresponding field in your LMS (varies by platform)
+
+
+
+ Perform a test sync or SSO login to verify that users are being correctly identified and mapped between systems.
+
+
+
+
+
+## LMS-Specific Attribute Requirements
+
+Different LMS platforms may require specific parameter configurations:
+
+
+
+### Troubleshooting
+- Ensure parameter names match exactly between OneLogin and your LMS configuration
+- Verify that all required parameters are configured and have values for your users
+- Check OneLogin event logs for SSO authentication details
+- Confirm that users have the necessary attribute values populated in their OneLogin profiles
+- Use OneLogin's SAML test feature to debug attribute mapping issues
+- Verify that macro syntax is correct and references valid user fields
\ No newline at end of file
diff --git a/integration-configuration-concepts/idp/sso-configuration-overview.mdx b/integration-configuration-concepts/idp/sso-configuration-overview.mdx
new file mode 100644
index 0000000..efa6149
--- /dev/null
+++ b/integration-configuration-concepts/idp/sso-configuration-overview.mdx
@@ -0,0 +1,183 @@
+---
+title: "SSO Configuration Overview"
+description: "Learn how to configure custom SSO attributes for LMS integrations across different Identity Providers."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx";
+
+This guide provides an overview of configuring Single Sign-On (SSO) attributes for LMS integrations. Custom SSO attributes, such as `lms_user_id`, allow you to map user identities between your identity provider and Learning Management System (LMS) platforms.
+
+## What are Custom SSO Attributes?
+
+Custom SSO attributes are additional user data fields that are passed from your Identity Provider (IDP) to your LMS during the SSO authentication process. These attributes enable:
+
+- **User Identity Mapping**: Link users between your IDP and LMS using custom identifiers
+- **Role Assignment**: Automatically assign roles or permissions based on user attributes
+- **Group Membership**: Map users to appropriate groups or organizational units
+- **Profile Enrichment**: Pass additional user information like department, manager, or job title
+
+## Common Use Cases for LMS Integrations
+
+### Learning Management Systems
+When integrating with LMS platforms, you typically need to configure custom attributes to:
+
+1. **Map User Identities**: Each LMS may require a different user identifier format
+2. **Assign Learning Paths**: Route users to appropriate training based on their role or department
+3. **Track Compliance**: Ensure users complete required training based on their job function
+4. **Reporting and Analytics**: Provide detailed reporting based on organizational structure
+
+### Typical Attribute Requirements
+Most LMS integrations require at least one custom attribute for user identification:
+
+- **`lms_user_id`**: Primary identifier for the user in the LMS
+- **`employee_id`**: Corporate employee identifier
+- **`department`**: User's organizational department
+- **`role`** or **`job_title`**: User's position for role-based access
+- **`manager_email`**: Manager information for approval workflows
+
+## Supported Identity Providers
+
+We provide detailed configuration guides for the most popular Identity Providers:
+
+
+
+ Configure custom attributes in Okta for LMS integrations using SAML attribute statements.
+
+
+
+ Set up custom claims in Microsoft Entra ID (Azure AD) for seamless LMS user mapping.
+
+
+
+ Configure SAML attribute mapping in Google Workspace for LMS integrations.
+
+
+
+ Set up custom parameters in OneLogin for LMS user identification and role mapping.
+
+
+
+## Configuration Steps Overview
+
+While each Identity Provider has its own interface and terminology, the general process follows these steps:
+
+
+
+ Determine what custom attributes your LMS integration needs:
+ - Check your LMS documentation or integration requirements
+ - Common attributes include user ID, email, employee ID, department, role
+
+
+
+ Set up the required custom attributes in your Identity Provider:
+ - Create custom user fields if needed
+ - Populate existing user profiles with the required data
+ - Map attributes to appropriate user properties
+
+
+
+ Set up your LMS application in your Identity Provider:
+ - Configure SAML settings (Entity ID, ACS URL, etc.)
+ - Map user attributes to SAML assertions or claims
+ - Set up attribute statements with the correct names and values
+
+
+
+ Verify that your SSO configuration works correctly:
+ - Test with a sample user account
+ - Check that all required attributes are being passed
+ - Verify attribute values are formatted correctly
+
+
+
+ Map the SSO attributes to your LMS integration:
+ - Specify which SSO attributes correspond to LMS fields
+ - Configure role mappings and group assignments
+ - Test the complete integration flow
+
+
+
+## LMS-Specific Considerations
+
+Different LMS platforms have varying requirements for SSO attributes:
+
+### Popular LMS Platforms
+
+**Docebo**
+- Primary identifier: Usually email or username
+- Additional attributes: First name, last name, role, groups
+- Format: Standard SAML attributes
+
+**Cornerstone OnDemand**
+- Primary identifier: Employee ID or custom identifier
+- Additional attributes: Manager, department, location
+- Format: May require specific attribute names
+
+**SAP SuccessFactors**
+- Primary identifier: Username or email-based identifier
+- Additional attributes: Job title, organization unit
+- Format: SAML assertions with specific formatting
+
+**Workday Learning**
+- Primary identifier: Employee ID or custom identifier
+- Additional attributes: Manager, cost center, location
+- Format: SAML or SCIM-based provisioning
+
+**360Learning**
+- Primary identifier: Email address
+- Additional attributes: First name, last name, team
+- Format: Standard SAML attributes
+
+## Best Practices
+
+### Security Considerations
+- **Minimize Attribute Exposure**: Only pass attributes that are necessary for the integration
+- **Use Secure Protocols**: Ensure all SSO communications use HTTPS and proper certificate validation
+- **Regular Audits**: Review and audit SSO configurations and attribute mappings regularly
+- **Access Controls**: Implement proper access controls for SSO application management
+
+### Data Management
+- **Consistent Naming**: Use consistent attribute naming conventions across integrations
+- **Data Quality**: Ensure user profiles have complete and accurate data for required attributes
+- **Change Management**: Implement processes for handling changes to user attributes
+- **Backup Strategy**: Maintain backups of SSO configurations and user attribute mappings
+
+### Testing and Monitoring
+- **Regular Testing**: Test SSO flows regularly, especially after configuration changes
+- **Monitor Logs**: Review SSO authentication logs for errors or issues
+- **User Feedback**: Collect feedback from users about SSO experience and any issues
+- **Performance Monitoring**: Monitor SSO performance and response times
+
+## Troubleshooting Common Issues
+
+### Attribute Not Passed
+- Verify attribute is configured in IDP
+- Check that user has value for the attribute
+- Confirm attribute mapping syntax is correct
+
+### Incorrect Attribute Format
+- Review LMS documentation for required format
+- Check IDP attribute transformation rules
+- Verify data type compatibility
+
+### User Not Found in LMS
+- Confirm primary identifier attribute is correct
+- Check that user exists in both IDP and LMS
+- Verify attribute value matches between systems
+
+### Permission Denied
+- Check user has access to the SSO application
+- Verify group memberships and role assignments
+- Review conditional access policies
+
+
+
+## Need Help?
+
+If you need assistance with SSO configuration for your specific LMS integration:
+
+1. **Check Provider Documentation**: Review your Identity Provider's documentation for SAML/SSO configuration
+2. **LMS Support**: Consult your LMS provider's SSO setup guide
+3. **Integration Support**: Contact your integration platform support team for specific mapping requirements
+
+Each Identity Provider guide linked above provides detailed, step-by-step instructions for configuring custom SSO attributes specific to that platform.
\ No newline at end of file
diff --git a/snippets/lms-identifiers.mdx b/snippets/lms-identifiers.mdx
new file mode 100644
index 0000000..84e594f
--- /dev/null
+++ b/snippets/lms-identifiers.mdx
@@ -0,0 +1,5 @@
+### Common LMS Attribute Mappings
+- **Docebo**: Use `user.user_id` for the user identifier
+- **SAP SuccessFactors**: Typically uses `user.USERID` or email-based identifier
+- **Workday Learning**: Often requires `user.employee_id`
+- **360Learning**: Usually accepts `user.mail`.
\ No newline at end of file