diff --git a/integration-configuration-concepts.mdx b/integration-configuration-concepts.mdx
index 8c36321..d81c60c 100644
--- a/integration-configuration-concepts.mdx
+++ b/integration-configuration-concepts.mdx
@@ -35,4 +35,11 @@ import { IntegrationTile } from '/snippets/integration-tile.mdx';
-
\ No newline at end of file
+
+
+## LMS (Learning Management Systems)
+
+
+
+
+
diff --git a/integration-configuration-concepts/lms/auth0-sso-configuration.mdx b/integration-configuration-concepts/lms/auth0-sso-configuration.mdx
new file mode 100644
index 0000000..bde1b75
--- /dev/null
+++ b/integration-configuration-concepts/lms/auth0-sso-configuration.mdx
@@ -0,0 +1,417 @@
+---
+title: "Auth0 SSO Configuration for LMS Integration"
+description: "Configure Auth0 to provide custom SSO attributes for Learning Management System integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx"
+
+
+This configuration requires admin access to your Auth0 tenant and should be tested thoroughly before production deployment.
+
+
+This guide walks you through configuring Auth0 as your Identity Provider to include custom user attributes (like `lms_user_id`) needed for Learning Management System integrations.
+
+## Overview
+
+Auth0 provides flexible user attribute management and can include custom claims in SAML assertions or OIDC tokens to support Learning Management System integrations. This enables seamless user mapping between your Auth0 user store and LMS platforms.
+
+## Prerequisites
+
+- Admin access to Auth0 dashboard
+- Understanding of the specific `lms_user_id` value required by your target LMS
+- Basic knowledge of SAML 2.0 or OIDC protocols
+
+## SAML Configuration
+
+
+
+ Log into your Auth0 dashboard and navigate to **Applications** > **Applications**.
+
+
+
+ - Click **Create Application**
+ - Enter application name (e.g., "LMS Integration")
+ - Select **Regular Web Applications**
+ - Click **Create**
+
+ Then switch to SAML2 Web App:
+ - Go to **Settings** tab
+ - Scroll to **Application Type**
+ - Select **SAML2 Web App**
+
+
+
+ In the **Settings** tab, configure:
+
+ **Application Callback URL**: Your LMS's Assertion Consumer Service URL
+ **Settings** (JSON format):
+ ```json
+ {
+ "audience": "your-service-provider-entity-id",
+ "recipient": "your-acs-url",
+ "destination": "your-acs-url",
+ "lifetimeInSeconds": 3600,
+ "signResponse": false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+ "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+ ]
+ }
+ ```
+
+
+ 
+
+
+
+
+ - Scroll to **Advanced Settings**
+ - Click **Endpoints** tab
+ - Copy the **SAML Metadata URL** or download the metadata
+ - Note the **SAML Identity Provider URL**
+
+
+
+ Navigate to **Auth Pipeline** > **Rules** and create a new rule:
+
+ ```javascript
+ function addCustomClaims(user, context, callback) {
+ // Add custom lms_user_id claim
+ const namespace = 'https://your-domain.com/';
+
+ // Set lms_user_id based on user attribute
+ if (user.app_metadata && user.app_metadata.lms_user_id) {
+ context.samlConfiguration.mappings = {
+ 'https://schemas.auth0.com/lms_user_id': user.app_metadata.lms_user_id
+ };
+ } else if (user.user_metadata && user.user_metadata.employee_id) {
+ context.samlConfiguration.mappings = {
+ 'https://schemas.auth0.com/lms_user_id': user.user_metadata.employee_id
+ };
+ } else {
+ // Fallback to user_id or email
+ context.samlConfiguration.mappings = {
+ 'https://schemas.auth0.com/lms_user_id': user.email
+ };
+ }
+
+ callback(null, user, context);
+ }
+ ```
+
+
+
+ For newer Auth0 tenants, use Actions instead of Rules:
+
+ Navigate to **Actions** > **Flows** > **Login**:
+ - Click **Custom** tab and create new Action
+ - Add the following code:
+
+ ```javascript
+ exports.onExecutePostLogin = async (event, api) => {
+ if (event.client.name === 'LMS Integration') {
+ // Add custom SAML attribute
+ if (event.user.app_metadata?.lms_user_id) {
+ api.samlResponse.setAttribute('lms_user_id', event.user.app_metadata.lms_user_id);
+ } else if (event.user.user_metadata?.employee_id) {
+ api.samlResponse.setAttribute('lms_user_id', event.user.user_metadata.employee_id);
+ } else {
+ api.samlResponse.setAttribute('lms_user_id', event.user.email);
+ }
+
+ // Add other attributes as needed
+ api.samlResponse.setAttribute('department', event.user.user_metadata?.department || '');
+ api.samlResponse.setAttribute('job_title', event.user.user_metadata?.job_title || '');
+ }
+ };
+ ```
+
+
+
+## OIDC Configuration Alternative
+
+
+
+ - Create a new **Single Page Application** or **Regular Web Application**
+ - Configure the **Allowed Callback URLs**
+ - Set **Allowed Web Origins** if needed
+
+
+
+ Create an Action for the Login flow:
+
+ ```javascript
+ exports.onExecutePostLogin = async (event, api) => {
+ if (event.client.client_id === 'your-lms-client-id') {
+ // Add custom claims to ID token
+ const namespace = 'https://your-domain.com/';
+
+ if (event.user.app_metadata?.lms_user_id) {
+ api.idToken.setCustomClaim(`${namespace}lms_user_id`, event.user.app_metadata.lms_user_id);
+ } else if (event.user.user_metadata?.employee_id) {
+ api.idToken.setCustomClaim(`${namespace}lms_user_id`, event.user.user_metadata.employee_id);
+ }
+
+ // Add to access token if needed
+ api.accessToken.setCustomClaim(`${namespace}lms_user_id`, event.user.app_metadata.lms_user_id);
+ }
+ };
+ ```
+
+
+
+ In your application settings:
+ - Set **JsonWebToken Signature Algorithm** (RS256 recommended)
+ - Configure **Token Expiration** settings
+ - Enable **OIDC Conformant** mode
+
+
+
+## Managing User Attributes
+
+
+
+ Auth0 supports two types of metadata:
+
+ **user_metadata**: Data that the user can modify
+ **app_metadata**: Data that only the application can modify
+
+ For LMS integration, typically use `app_metadata` for `lms_user_id`:
+
+ ```json
+ {
+ "app_metadata": {
+ "lms_user_id": "EMP123456",
+ "lms_role": "student",
+ "department": "Engineering"
+ },
+ "user_metadata": {
+ "preferences": {
+ "language": "en"
+ }
+ }
+ }
+ ```
+
+
+
+ You can set user metadata via:
+
+ **Management API**:
+ ```javascript
+ const auth0 = require('auth0');
+ const management = new auth0.ManagementClient({
+ domain: 'your-domain.auth0.com',
+ clientId: 'your-client-id',
+ clientSecret: 'your-client-secret'
+ });
+
+ management.updateUser(
+ { id: 'auth0|userId' },
+ { app_metadata: { lms_user_id: 'EMP123456' } }
+ );
+ ```
+
+ **Auth0 Dashboard**: Manual entry in user profiles
+ **Bulk Import**: Using Auth0's user import functionality
+ **Database Connections**: Sync from external databases
+
+
+
+ Use Rules/Actions to dynamically assign attributes based on user properties:
+
+ ```javascript
+ exports.onExecutePostLogin = async (event, api) => {
+ // Assign lms_user_id based on email domain
+ const domain = event.user.email.split('@')[1];
+ let lms_user_id;
+
+ if (domain === 'company.edu') {
+ // For students, use the email prefix
+ lms_user_id = event.user.email.split('@')[0];
+ } else if (domain === 'staff.company.edu') {
+ // For staff, use employee_id from user_metadata
+ lms_user_id = event.user.user_metadata.employee_id;
+ }
+
+ if (lms_user_id) {
+ api.user.setAppMetadata('lms_user_id', lms_user_id);
+ }
+ };
+ ```
+
+
+
+## Database Connection Configuration
+
+If you're using a custom database connection:
+
+
+
+ - Go to **Authentication** > **Database**
+ - Create or configure your custom database connection
+ - Implement the **Login** script to return user profile with custom attributes
+
+
+
+ ```javascript
+ function login(email, password, callback) {
+ // Your authentication logic here
+ const query = 'SELECT * FROM users WHERE email = ?';
+
+ mysql.query(query, [email], function(err, results) {
+ if (err) return callback(err);
+ if (results.length === 0) return callback(new WrongUsernameOrPasswordError(email));
+
+ const user = results[0];
+
+ // Verify password
+ if (!bcrypt.compareSync(password, user.password)) {
+ return callback(new WrongUsernameOrPasswordError(email));
+ }
+
+ // Return user profile with custom attributes
+ return callback(null, {
+ user_id: user.id,
+ email: user.email,
+ name: user.name,
+ app_metadata: {
+ lms_user_id: user.employee_id,
+ department: user.department,
+ role: user.role
+ }
+ });
+ });
+ }
+ ```
+
+
+
+## Common LMS User ID Patterns
+
+| LMS Platform | Recommended Attribute Source | Auth0 Configuration |
+|--------------|----------------------------|-------------------|
+| Canvas | Employee ID or Email | `app_metadata.employee_id` or `email` |
+| Blackboard | Username or Email | `app_metadata.username` or `email` |
+| Moodle | Student/Employee ID | `app_metadata.lms_user_id` |
+| Docebo | Employee ID or Email | `app_metadata.employee_id` or `email` |
+| Cornerstone | Employee ID | `app_metadata.employee_id` |
+
+## Testing Your Configuration
+
+
+
+ Use Auth0's SAML tester:
+ - Go to your application's **Addons** tab
+ - Enable **SAML2 Web App**
+ - Use the **Debug** URL with a test user
+ - Verify custom attributes appear in the SAML response
+
+
+
+ Monitor your Rules/Actions:
+ - Go to **Monitoring** > **Logs**
+ - Filter by your application
+ - Check for any errors in custom claim processing
+
+
+
+ - Test complete login flow with your LMS
+ - Verify user creation/matching works correctly
+ - Test with different user types and attribute combinations
+
+
+
+## Security Best Practices
+
+- **Namespace Custom Claims**: Always use namespaced claim names to avoid conflicts
+- **Validate User Input**: Sanitize user metadata before using in claims
+- **Secure Secrets**: Store sensitive configuration in Auth0 secrets or environment variables
+- **Token Security**: Use appropriate token expiration times
+- **Audit Logs**: Regularly review Auth0 logs for suspicious activity
+- **Rate Limiting**: Configure appropriate rate limits for your applications
+
+## Advanced Features
+
+### Multi-tenant Support
+
+
+
+ Use Rules/Actions to set different `lms_user_id` formats per tenant:
+
+ ```javascript
+ exports.onExecutePostLogin = async (event, api) => {
+ const tenant = event.user.app_metadata.tenant;
+
+ switch(tenant) {
+ case 'university-a':
+ api.samlResponse.setAttribute('lms_user_id', `UA-${event.user.user_metadata.student_id}`);
+ break;
+ case 'university-b':
+ api.samlResponse.setAttribute('lms_user_id', event.user.email);
+ break;
+ default:
+ api.samlResponse.setAttribute('lms_user_id', event.user.user_id);
+ }
+ };
+ ```
+
+
+
+### Progressive User Attribute Collection
+
+
+
+ Use Auth0's progressive profiling to collect `lms_user_id` after initial signup:
+
+ - Create custom signup/login forms
+ - Add fields for employee ID or student ID
+ - Store in user_metadata or app_metadata
+ - Use Rules/Actions to require completion before LMS access
+
+
+
+## Troubleshooting
+
+### Common Issues
+
+**Custom claim not in SAML assertion:**
+- Check if Rule/Action is executing (review logs)
+- Verify user has the required metadata populated
+- Ensure proper namespace formatting
+
+**Authentication failing:**
+- Verify ACS URL configuration matches exactly
+- Check SAML settings JSON syntax
+- Review certificate configuration
+
+**User attribute format issues:**
+- Some LMS platforms expect specific formats
+- Test with different metadata structures
+- Check for special character handling
+
+### Debugging Tools
+
+
+
+ Use the real-time logs:
+ - **Success Login**: Verify successful authentications
+ - **Failed Login**: Review authentication failures
+ - **Custom**: Check Rule/Action execution logs
+
+
+
+ Use browser extensions to capture SAML traffic:
+ - Install SAML-tracer extension
+ - Capture SAML POST requests
+ - Verify attribute values in assertions
+
+
+
+
+
+## Additional Resources
+
+- [Auth0 SAML Configuration](https://auth0.com/docs/protocols/saml)
+- [Auth0 Actions Documentation](https://auth0.com/docs/actions)
+- [User Metadata Management](https://auth0.com/docs/users/concepts/overview-user-metadata)
\ No newline at end of file
diff --git a/integration-configuration-concepts/lms/azure-ad-sso-configuration.mdx b/integration-configuration-concepts/lms/azure-ad-sso-configuration.mdx
new file mode 100644
index 0000000..9b2d13e
--- /dev/null
+++ b/integration-configuration-concepts/lms/azure-ad-sso-configuration.mdx
@@ -0,0 +1,295 @@
+---
+title: "Azure AD/Entra ID SSO Configuration for LMS Integration"
+description: "Configure Azure Active Directory (Entra ID) to provide custom SSO attributes for Learning Management System integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx"
+
+
+This configuration requires admin access to your Azure Active Directory tenant and should be tested thoroughly before production deployment.
+
+
+This guide walks you through configuring Azure Active Directory (now Entra ID) as your Identity Provider to include custom user attributes (like `lms_user_id`) needed for Learning Management System integrations.
+
+## Overview
+
+Azure AD can provide custom user attributes in SAML tokens or OIDC claims to support Learning Management System integrations. This allows seamless user mapping between your corporate directory and LMS platforms.
+
+## Prerequisites
+
+- Global Administrator or Application Administrator role in Azure AD
+- Understanding of the specific `lms_user_id` value required by your target LMS
+- Basic knowledge of SAML 2.0 or OIDC protocols
+
+## SAML Configuration
+
+
+
+ Navigate to the Azure portal (portal.azure.com) and go to **Azure Active Directory** > **Enterprise applications**.
+
+
+
+ - Click **New application**
+ - Select **Create your own application**
+ - Choose **Integrate any other application you don't find in the gallery (Non-gallery)**
+ - Provide a name for your LMS integration
+
+
+
+ In your application:
+ - Go to **Single sign-on**
+ - Select **SAML** as the single sign-on method
+
+
+ 
+
+
+
+
+ Configure the following settings:
+
+ **Identifier (Entity ID)**: Your service provider entity ID
+ **Reply URL (Assertion Consumer Service URL)**: Your application's SSO endpoint
+ **Sign on URL**: (Optional) Your application's login URL
+ **Relay State**: (Optional) If required by your application
+
+
+
+ In the **User Attributes & Claims** section:
+
+ - Click **Add new claim**
+ - **Name**: Enter `lms_user_id` (or your required attribute name)
+ - **Source**: Select **Attribute**
+ - **Source attribute**: Choose from available options:
+ - `user.employeeid` - For employee ID-based systems
+ - `user.userprincipalname` - For email-based identifiers
+ - `user.mail` - For email addresses
+ - `user.extensionattribute1-15` - For custom attributes
+
+
+ 
+
+
+
+
+ Add other claims as needed:
+
+ - **groups**: For group membership information
+ - **department**: For organizational structure
+ - **jobtitle**: For role-based access
+
+
+
+ In the **SAML Signing Certificate** section:
+ - Download the **Certificate (Base64)** or **Certificate (Raw)**
+ - Note the **Login URL** and **Logout URL**
+
+
+
+ Go to **Users and groups**:
+ - Add individual users or groups who need access
+ - Ensure users have the required attributes populated
+
+
+
+## OIDC Configuration Alternative
+
+For applications using OpenID Connect:
+
+
+
+ In **App registrations**:
+ - Click **New registration**
+ - Enter application name
+ - Select appropriate account types
+ - Configure redirect URI
+
+
+
+ Add required permissions:
+ - `openid` (for OIDC)
+ - `profile` (for user profile information)
+ - `email` (if email claims needed)
+
+
+
+ In **Token configuration**:
+ - Click **Add optional claim**
+ - Select **ID** token type
+ - Add required claims like `employee_id`, `extension_attribute1`, etc.
+
+
+
+ Configure authentication settings:
+ - Set appropriate token lifetimes
+ - Configure access token format (v1.0 or v2.0)
+ - Enable implicit grant if required
+
+
+
+## Custom User Attributes (Extension Attributes)
+
+If your LMS user identifier requires custom attributes:
+
+
+
+ Azure AD provides 15 extension attributes (`extensionAttribute1` through `extensionAttribute15`) for custom data.
+
+ These can be populated via:
+ - Azure AD Connect (from on-premises AD)
+ - Microsoft Graph API
+ - PowerShell commands
+ - Manual entry in user profiles
+
+
+
+ ```powershell
+ # Connect to Azure AD
+ Connect-AzureAD
+
+ # Set extension attribute for a user
+ Set-AzureADUser -ObjectId "user@domain.com" -ExtensionProperty @{"extensionAttribute1"="LMS123456"}
+ ```
+
+
+
+ Use Azure AD's bulk operations:
+ - Go to **Users** > **Bulk operations** > **Bulk update**
+ - Download the CSV template
+ - Add your extension attribute data
+ - Upload the completed CSV
+
+
+
+## Advanced Configuration
+
+### Conditional Access Integration
+
+
+
+ Navigate to **Security** > **Conditional Access**:
+ - Create policy for your LMS application
+ - Configure user/group assignments
+ - Set location, device, or risk-based conditions
+
+
+
+ Set requirements such as:
+ - Multi-factor authentication
+ - Compliant device requirement
+ - Approved client app requirement
+
+
+
+### Group Claims Configuration
+
+
+
+ In your application's **Token configuration**:
+ - Click **Add groups claim**
+ - Select group types to include
+ - Choose between Group ID, sAMAccountName, or other formats
+
+
+
+ For large organizations:
+ - Use security groups assigned to the application
+ - Filter by specific group name patterns
+ - Limit to specific group types
+
+
+
+## Common LMS User ID Mappings
+
+| LMS Platform | Recommended Azure AD Attribute | Alternative Options |
+|--------------|-------------------------------|-------------------|
+| Canvas | `user.employeeid` | `user.extensionattribute1` |
+| Blackboard | `user.userprincipalname` | `user.mail` |
+| Moodle | `user.employeeid` | `user.extensionattribute2` |
+| Docebo | `user.employeeid` | `user.mail` |
+| Cornerstone | `user.employeeid` | `user.extensionattribute1` |
+
+## Testing Your Configuration
+
+
+
+ Use Azure AD's test functionality:
+ - In your application's SSO settings
+ - Click **Test this application**
+ - Select a test user and review the generated SAML token
+ - Verify custom attributes appear correctly
+
+
+
+ Check that your `lms_user_id` claim contains:
+ - Correct value format
+ - Proper case sensitivity
+ - No extra whitespace or characters
+
+
+
+ Perform complete login flow:
+ - Test with multiple user accounts
+ - Verify successful authentication and user mapping
+ - Check that user appears correctly in your LMS
+
+
+
+## Security Best Practices
+
+- **Certificate Management**: Regularly rotate SAML signing certificates
+- **Token Encryption**: Enable token encryption for sensitive data
+- **Conditional Access**: Implement appropriate access policies
+- **Audit Logging**: Monitor sign-in activities and token issuance
+- **Least Privilege**: Only include necessary claims and attributes
+- **Network Security**: Restrict access to trusted networks when possible
+
+## Troubleshooting
+
+### Common Issues
+
+**Custom claim not appearing in token:**
+- Verify the user has the source attribute populated
+- Check claim configuration and source attribute mapping
+- Ensure the application has been assigned to the user/group
+
+**Authentication failures:**
+- Verify Reply URLs match exactly (case-sensitive)
+- Check certificate validity and configuration
+- Review error messages in Azure AD sign-in logs
+
+**User mapping issues:**
+- Confirm `lms_user_id` value format matches LMS expectations
+- Check for case sensitivity requirements
+- Verify user exists in target LMS system
+
+**Token size issues:**
+- Azure AD has token size limits (especially for group claims)
+- Use group filtering to reduce token size
+- Consider using group IDs instead of display names
+
+### Monitoring and Diagnostics
+
+
+
+ Navigate to **Monitoring** > **Sign-in logs**:
+ - Filter by your application
+ - Review successful and failed authentications
+ - Check token details for claim validation
+
+
+
+ Use **Audit logs** to track:
+ - Application configuration changes
+ - User assignments
+ - Certificate updates
+
+
+
+
+
+## Additional Resources
+
+- [Azure AD SAML Documentation](https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol)
+- [Azure AD Custom Claims Documentation](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims)
+- [Extension Attributes Guide](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-feature-directory-extensions)
\ No newline at end of file
diff --git a/integration-configuration-concepts/lms/google-workspace-sso-configuration.mdx b/integration-configuration-concepts/lms/google-workspace-sso-configuration.mdx
new file mode 100644
index 0000000..aa3885e
--- /dev/null
+++ b/integration-configuration-concepts/lms/google-workspace-sso-configuration.mdx
@@ -0,0 +1,317 @@
+---
+title: "Google Workspace SSO Configuration for LMS Integration"
+description: "Configure Google Workspace to provide custom SSO attributes for Learning Management System integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx"
+
+
+This configuration requires Google Workspace admin privileges and should be tested in a non-production environment first.
+
+
+This guide walks you through configuring Google Workspace as your Identity Provider to include custom user attributes (like `lms_user_id`) needed for Learning Management System integrations.
+
+## Overview
+
+Google Workspace can provide custom user attributes in SAML assertions to support Learning Management System integrations. This enables seamless user mapping between your Google Workspace directory and LMS platforms.
+
+## Prerequisites
+
+- Super Admin access to Google Workspace
+- Understanding of the specific `lms_user_id` value required by your target LMS
+- Basic knowledge of SAML 2.0 protocol
+
+## SAML Configuration Steps
+
+
+
+ Go to the Google Admin console (admin.google.com) and navigate to **Apps** > **Web and mobile apps**.
+
+
+
+ - Click **Add app** > **Add custom SAML app**
+ - Enter your application name (e.g., "LMS Integration")
+ - Optionally upload an application logo
+ - Click **Continue**
+
+
+ 
+
+
+
+
+ Google will display the Identity Provider details:
+ - **SSO URL**: Copy this URL
+ - **Entity ID**: Note the entity identifier
+ - **Certificate**: Download the certificate file
+ - **Start URL**: (Optional) Set if needed
+
+ Save this information for your LMS configuration.
+
+
+
+ Enter your LMS service provider information:
+
+ **ACS URL**: Your LMS's Assertion Consumer Service URL
+ **Entity ID**: Your service provider entity ID
+ **Start URL**: (Optional) Your LMS login URL
+ **Name ID format**: Choose appropriate format (typically EMAIL)
+ **Name ID**: Select the user attribute (usually Primary email)
+
+
+
+ In the **Attribute mapping** section, add your custom attributes:
+
+ - Click **Add mapping**
+ - **Google Directory attributes**: Select the source attribute
+ - **App attributes**: Enter `lms_user_id` (or your required attribute name)
+
+ Common mappings:
+ - **Primary email** → `lms_user_id` (for email-based systems)
+ - **Employee ID** → `lms_user_id` (for employee ID-based systems)
+ - **Custom attributes** → `lms_user_id` (for custom fields)
+
+
+ 
+
+
+
+
+ Set access permissions:
+ - **ON for everyone**: All users in your domain
+ - **OFF for everyone, ON for some**: Specific organizational units or groups
+ - Configure based on your LMS access requirements
+
+
+
+ - Click **Test SAML login** to verify the setup
+ - Use a test user account to validate the SAML response
+ - Check that custom attributes appear correctly in the assertion
+
+
+
+## Custom User Attributes Setup
+
+If your LMS requires custom user attributes not available by default:
+
+
+
+ In the Google Admin console:
+ - Go to **Directory** > **Users**
+ - Click **More** > **Manage custom attributes**
+ - Click **Add custom attribute**
+ - Define your custom attribute:
+ - **Name**: `lms_user_id` (or appropriate name)
+ - **Info type**: Text
+ - **Visibility**: Visible to user and admin
+ - **No. of values**: Single value
+
+
+
+ You can populate custom attributes via:
+
+ **Manual Entry:**
+ - Edit individual user profiles
+ - Add the custom attribute value
+
+ **Bulk Upload:**
+ - Use Google Admin SDK
+ - CSV import through third-party tools
+ - Google Apps Script automation
+
+
+
+ Return to your SAML app configuration:
+ - Edit the attribute mapping
+ - Select your custom attribute as the source
+ - Map it to the `lms_user_id` app attribute
+
+
+
+## Advanced Configuration Options
+
+### Organizational Unit-Based Access
+
+
+
+ For granular control:
+ - Turn OFF the app for everyone
+ - Create specific organizational units for LMS users
+ - Turn ON the app only for those OUs
+
+
+
+ Different OUs can have different attribute mappings if needed:
+ - Create separate SAML apps for different user groups
+ - Configure different attribute mappings for each group
+
+
+
+### Group-Based Attribute Mapping
+
+
+
+ Set up groups for different LMS roles:
+ - Navigate to **Directory** > **Groups**
+ - Create groups like "LMS_Students", "LMS_Faculty", "LMS_Admins"
+
+
+
+ In your SAML app attribute mapping:
+ - Add mapping for **Groups** → `groups`
+ - This will include group membership in the SAML assertion
+
+
+
+## OIDC Configuration Alternative
+
+While Google Workspace primarily uses SAML for SSO, you can also configure OAuth 2.0/OIDC:
+
+
+
+ - Go to Google Cloud Console (console.cloud.google.com)
+ - Create or select a project
+ - Enable the Google Workspace APIs
+
+
+
+ - Navigate to **APIs & Services** > **Credentials**
+ - Create OAuth 2.0 Client ID
+ - Configure authorized redirect URIs
+
+
+
+ Request appropriate scopes:
+ - `openid` - For OIDC authentication
+ - `profile` - For user profile information
+ - `email` - For email address
+ - Custom scopes for additional attributes
+
+
+
+## Common LMS User ID Mappings
+
+| LMS Platform | Recommended Google Attribute | Configuration Notes |
+|--------------|----------------------------|-------------------|
+| Canvas | Employee ID or Primary email | Use Employee ID if available |
+| Blackboard | Primary email | Email format required |
+| Moodle | Employee ID or Custom attribute | Numeric IDs often preferred |
+| Docebo | Employee ID or Primary email | Support both formats |
+| Cornerstone | Employee ID | Numeric identifier preferred |
+
+## Testing Your Configuration
+
+
+
+ In your SAML app settings:
+ - Click **Test SAML login**
+ - Select a test user
+ - Review the SAML assertion details
+ - Verify `lms_user_id` attribute is present and correct
+
+
+
+ Check that the SAML response includes:
+ - Correct `lms_user_id` value
+ - Proper format (string, number, etc.)
+ - No HTML encoding issues
+ - Expected case sensitivity
+
+
+
+ - Test actual login to your LMS
+ - Verify user is created/matched correctly
+ - Check user profile information in LMS
+ - Test with multiple user types (students, faculty, etc.)
+
+
+
+## User Attribute Sources
+
+Google Workspace provides several built-in attributes you can use:
+
+### Standard Attributes
+- **Primary email**: User's primary email address
+- **Employee ID**: Employee identifier number
+- **First name**: User's first name
+- **Last name**: User's last name
+- **Full name**: Complete display name
+- **Department**: Organizational department
+- **Job title**: User's job title
+- **Manager**: Manager's email address
+- **Cost center**: Organizational cost center
+
+### Custom Attributes
+- **Custom attribute 1-n**: Your custom defined fields
+- **External ID**: External system identifiers
+- **Organizations**: Organizational information
+- **Relations**: Relationship information
+- **Addresses**: Physical address information
+
+## Security Best Practices
+
+- **Certificate Rotation**: Regularly update SAML certificates
+- **Access Review**: Periodically review user access and organizational unit assignments
+- **Audit Logging**: Monitor SAML authentication events in Google Admin console
+- **Network Restrictions**: Consider IP-based access restrictions if needed
+- **Session Management**: Configure appropriate session timeouts
+- **Data Minimization**: Only map necessary user attributes
+
+## Troubleshooting
+
+### Common Issues
+
+**Custom attribute not in SAML assertion:**
+- Verify the custom attribute is populated for the test user
+- Check attribute mapping configuration
+- Ensure the user has access to the SAML app
+
+**SAML authentication failing:**
+- Verify ACS URL matches exactly
+- Check certificate validity
+- Review SAML error messages in browser developer tools
+
+**User not found in LMS:**
+- Confirm `lms_user_id` format matches LMS requirements
+- Check for case sensitivity issues
+- Verify user exists in target system
+
+**Attribute format issues:**
+- Some LMS platforms expect specific formats (email vs. numeric ID)
+- Test different attribute sources
+- Check for special character handling
+
+### Debugging Tools
+
+
+
+ Review SAML authentication events:
+ - Go to **Reporting** > **Audit and investigation**
+ - Filter by SAML application
+ - Review successful and failed authentication attempts
+
+
+
+ Use browser developer tools or SAML debugging tools:
+ - Capture SAML POST requests
+ - Decode Base64 SAML responses
+ - Verify attribute values and formats
+
+
+
+## Migration Considerations
+
+When migrating from other identity providers:
+
+- **User Matching**: Plan how to match existing LMS users
+- **Attribute Mapping**: Ensure consistent attribute values
+- **Gradual Rollout**: Test with small user groups first
+- **Fallback Options**: Maintain alternative authentication methods during transition
+
+
+
+## Additional Resources
+
+- [Google Workspace SAML Documentation](https://support.google.com/a/answer/6087519)
+- [Custom User Attributes Guide](https://support.google.com/a/answer/6208725)
+- [Google Admin SDK Directory API](https://developers.google.com/admin-sdk/directory)
\ No newline at end of file
diff --git a/integration-configuration-concepts/lms/okta-sso-configuration.mdx b/integration-configuration-concepts/lms/okta-sso-configuration.mdx
new file mode 100644
index 0000000..4cecac7
--- /dev/null
+++ b/integration-configuration-concepts/lms/okta-sso-configuration.mdx
@@ -0,0 +1,212 @@
+---
+title: "Okta SSO Configuration for LMS Integration"
+description: "Configure Okta to provide custom SSO attributes for Learning Management System integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx"
+
+
+This configuration requires admin access to your Okta instance and should be tested in a non-production environment first.
+
+
+This guide walks you through configuring Okta as your Identity Provider to include custom user attributes (like `lms_user_id`) needed for Learning Management System integrations.
+
+## Overview
+
+When integrating with Learning Management Systems, you often need to map users between your identity provider and the LMS platform. This requires configuring custom attributes in your SAML or OIDC assertions that contain the user's identifier in the target LMS.
+
+## Prerequisites
+
+- Admin access to Okta
+- Understanding of the specific `lms_user_id` value required by your target LMS
+- Basic knowledge of SAML 2.0 or OIDC protocols
+
+## Configuration Steps
+
+
+
+ Log into your Okta admin console and navigate to **Applications** > **Applications**.
+
+
+
+ Either create a new SAML 2.0 application or select your existing integration application.
+
+ For new applications:
+ - Click **Create App Integration**
+ - Select **SAML 2.0**
+ - Enter your application name and optionally upload a logo
+
+
+
+ In the SAML Settings section:
+
+ **Single Sign-On URL**: Enter your application's SSO endpoint
+ **Audience URI (SP Entity ID)**: Enter your service provider entity ID
+ **Default RelayState**: (Optional) Set if needed by your application
+
+
+ 
+
+
+
+
+ In the **Attribute Statements** section, add your custom attributes:
+
+ - **Name**: `lms_user_id` (or the specific attribute name required)
+ - **Name format**: Choose appropriate format (typically Unspecified)
+ - **Value**: Select the Okta user attribute that contains the LMS user identifier
+
+ Common mappings:
+ - `user.login` - For email-based identifiers
+ - `user.employeeNumber` - For employee ID-based systems
+ - `user.customAttribute` - For custom user attributes
+
+
+ 
+
+
+
+
+ If your LMS requires group or role information:
+
+ - **Name**: `groups` or `roles`
+ - **Name format**: Unspecified
+ - **Filter**: Choose appropriate group filter
+ - **Value**: `Starts with`, `Equals`, `Contains`, or `Regex`
+
+
+
+ In the **Assignments** tab:
+ - Assign individual users or groups who should have access
+ - Ensure assigned users have the required custom attributes populated
+
+
+
+ From the **Sign On** tab, either:
+ - Download the metadata XML file, or
+ - Copy the Identity Provider metadata details:
+ - Identity Provider Single Sign-On URL
+ - Identity Provider Issuer
+ - X.509 Certificate
+
+
+
+## OIDC Configuration Alternative
+
+If your integration uses OIDC instead of SAML:
+
+
+
+ - Select **OIDC - OpenID Connect** when creating the application
+ - Choose **Web Application** as the application type
+
+
+
+ Enable the appropriate grant types:
+ - Authorization Code (recommended)
+ - Implicit (if required by your application)
+
+
+
+ In the **Claims** tab of your authorization server:
+ - Add a custom claim named `lms_user_id`
+ - Set the value to the appropriate user attribute
+ - Include in ID token and/or access token as needed
+
+
+
+ Ensure your application includes the necessary scopes:
+ - `openid` (required)
+ - `profile` (for user information)
+ - Custom scopes if your claims require them
+
+
+
+## Custom User Attributes Setup
+
+If your LMS user identifier isn't a standard Okta attribute:
+
+
+
+ Navigate to **Directory** > **Profile Editor**
+ - Select the **User (default)** profile
+ - Click **Add Attribute**
+ - Define your custom attribute (e.g., `lms_user_id`)
+
+
+
+ You can populate custom attributes via:
+ - Manual entry in user profiles
+ - CSV import during user provisioning
+ - API updates using Okta's REST API
+ - Directory integration (Active Directory, LDAP)
+
+
+
+## Testing Your Configuration
+
+
+
+ Use Okta's built-in SAML assertion preview:
+ - Go to your application's **Sign On** tab
+ - Click **Preview the SAML Assertion**
+ - Select a test user and verify the custom attributes appear correctly
+
+
+
+ Perform a test login with a user account that has the required attributes populated to ensure the integration works end-to-end.
+
+
+
+## Common LMS User ID Patterns
+
+Different LMS platforms typically expect different identifier formats:
+
+| LMS Platform | Common `lms_user_id` Format | Okta Mapping |
+|--------------|----------------------------|--------------|
+| Canvas | Student/Employee ID | `user.employeeNumber` |
+| Blackboard | Username | `user.login` |
+| Moodle | Username or ID number | `user.login` or custom attribute |
+| Docebo | Employee ID or email | `user.employeeNumber` or `user.email` |
+| Cornerstone | Employee ID | `user.employeeNumber` |
+
+## Security Best Practices
+
+- **Encrypt Assertions**: Always enable assertion encryption in production
+- **Sign Assertions**: Configure assertion and response signing
+- **Validate Certificates**: Ensure proper certificate validation
+- **Minimal Attributes**: Only include necessary attributes in assertions
+- **Regular Rotation**: Rotate signing certificates regularly
+- **Monitor Access**: Review SAML/OIDC logs regularly for suspicious activity
+
+## Troubleshooting
+
+### Common Issues
+
+**Custom attribute not appearing in assertion:**
+- Verify the user has the attribute populated
+- Check attribute mapping configuration
+- Ensure proper name format is selected
+
+**Authentication failing:**
+- Verify SSO URLs and entity IDs match exactly
+- Check certificate validity and configuration
+- Review RelayState configuration if used
+
+**User not found in LMS:**
+- Verify the `lms_user_id` value matches the LMS user identifier exactly
+- Check for case sensitivity issues
+- Confirm the user exists in the target LMS
+
+**Attribute format issues:**
+- Some LMS platforms expect specific formats (email vs. ID)
+- Test with different name formats in attribute statements
+- Verify the LMS platform's expected attribute requirements
+
+
+
+## Additional Resources
+
+- [Okta SAML 2.0 Documentation](https://developer.okta.com/docs/concepts/saml/)
+- [Okta OIDC Documentation](https://developer.okta.com/docs/reference/api/oidc/)
+- [Custom User Attributes Guide](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-about-profiles.htm)
\ No newline at end of file
diff --git a/integration-configuration-concepts/lms/sso-user-id-configuration.mdx b/integration-configuration-concepts/lms/sso-user-id-configuration.mdx
new file mode 100644
index 0000000..c24b90b
--- /dev/null
+++ b/integration-configuration-concepts/lms/sso-user-id-configuration.mdx
@@ -0,0 +1,258 @@
+---
+title: "SSO User ID Configuration for LMS Integrations"
+description: "Overview of configuring Identity Providers to include custom user identifiers for Learning Management System integrations."
+---
+
+import IntegrationFooter from "/snippets/integration-footer.mdx"
+
+## Overview
+
+Learning Management System (LMS) integrations often require mapping users between your Identity Provider (IdP) and the LMS platform. This mapping is typically achieved through a custom SSO attribute called `lms_user_id` that contains the user's identifier in the target LMS system.
+
+This document provides an overview of the concepts and links to specific Identity Provider configuration guides.
+
+## Key Concepts
+
+### User Identity Mapping
+
+When a user logs into an LMS through SSO, the system needs to:
+
+1. **Authenticate the user** through your Identity Provider
+2. **Receive user attributes** in the SAML assertion or OIDC claims
+3. **Map the user** to an existing LMS account using the `lms_user_id` attribute
+4. **Grant access** to the appropriate LMS resources
+
+### Common User ID Patterns
+
+Different LMS platforms expect different identifier formats:
+
+| ID Type | Description | Example | Common LMS Platforms |
+|---------|-------------|---------|---------------------|
+| **Email Address** | User's email address | `john.doe@company.edu` | Blackboard, some Canvas instances |
+| **Employee ID** | Numeric employee identifier | `123456` | Cornerstone, Docebo, Workday Learning |
+| **Student ID** | Academic student identifier | `STU789123` | Canvas, Moodle (academic) |
+| **Username** | Login username | `jdoe` | Moodle, custom LMS platforms |
+| **External ID** | External system identifier | `EXT_ABC123` | Multi-system integrations |
+
+### SSO Protocols
+
+Most LMS integrations use one of two SSO protocols:
+
+**SAML 2.0 (Recommended)**
+- More secure for enterprise environments
+- Better support for custom attributes
+- Standard protocol across most enterprise IdPs
+
+**OpenID Connect (OIDC)**
+- Modern OAuth 2.0-based protocol
+- Good for cloud-native applications
+- Flexible claim structure
+
+## Identity Provider Configuration Guides
+
+Choose your Identity Provider for detailed configuration instructions:
+
+### Enterprise Identity Providers
+
+
+
+ Configure Okta to provide custom user attributes for LMS integrations using SAML 2.0 or OIDC.
+
+
+
+ Set up Microsoft Azure Active Directory with extension attributes and custom claims.
+
+
+
+ Configure Google Workspace with custom user attributes and SAML mappings.
+
+
+
+ Set up Auth0 with user metadata and custom claims using Rules or Actions.
+
+
+
+### Other Popular Identity Providers
+
+If your Identity Provider isn't listed above, the general principles remain the same:
+
+1. **Create/configure** a SAML application or OIDC client
+2. **Add custom attributes** or claims for `lms_user_id`
+3. **Map user attributes** to the LMS identifier
+4. **Test the configuration** with sample users
+5. **Deploy to production** with proper access controls
+
+## Planning Your Implementation
+
+### Step 1: Identify LMS User Identifiers
+
+Before configuring your IdP, determine:
+
+- **What identifier format** does your LMS use?
+- **Where is this identifier stored** in your user directory?
+- **Is the identifier unique** across all users?
+- **Does it change over time** (avoid changing identifiers)?
+
+### Step 2: Choose User Attribute Source
+
+Common sources for `lms_user_id`:
+
+**Existing Attributes:**
+- Employee ID (for staff/faculty)
+- Student ID (for academic institutions)
+- Email address (universal but may change)
+- Username (if stable and unique)
+
+**Custom Attributes:**
+- LMS-specific identifiers
+- External system IDs
+- Composite identifiers
+
+### Step 3: Configure Identity Provider
+
+Follow the appropriate guide above to:
+
+1. Set up the SSO application
+2. Configure custom attributes/claims
+3. Map to your chosen user identifier
+4. Set up user access and permissions
+
+### Step 4: Test Configuration
+
+Always test your configuration:
+
+1. **Validate SSO response** contains the correct `lms_user_id`
+2. **Test user mapping** in the LMS
+3. **Verify edge cases** (new users, missing attributes, etc.)
+4. **Check error handling** for failed mappings
+
+## Security Considerations
+
+### Attribute Security
+
+- **Minimize sensitive data** in SSO attributes
+- **Use stable identifiers** that don't change frequently
+- **Encrypt assertions** when possible (SAML)
+- **Validate user input** before using in attributes
+
+### Access Control
+
+- **Limit application access** to authorized users only
+- **Use organizational units** or groups to control access
+- **Implement conditional access** policies where supported
+- **Monitor authentication events** regularly
+
+### Data Privacy
+
+- **Only include necessary attributes** in SSO responses
+- **Follow data protection regulations** (GDPR, CCPA, etc.)
+- **Document attribute usage** and retention policies
+- **Provide user transparency** about data sharing
+
+## Common Implementation Scenarios
+
+### Scenario 1: University Environment
+
+**Users**: Students, Faculty, Staff
+**Identifier**: Student ID for students, Employee ID for staff
+**Implementation**:
+- Use organizational units or groups to differentiate user types
+- Map different attributes based on user type
+- Include role/group information in SSO response
+
+### Scenario 2: Corporate Training
+
+**Users**: All employees
+**Identifier**: Employee ID
+**Implementation**:
+- Single attribute mapping for all users
+- Include department/role information
+- Sync with HR systems for user lifecycle management
+
+### Scenario 3: Multi-Tenant SaaS
+
+**Users**: Multiple customer organizations
+**Identifier**: Tenant-specific user ID
+**Implementation**:
+- Include tenant information in attributes
+- Use composite identifiers (tenant + user ID)
+- Separate SSO applications per tenant if needed
+
+## Troubleshooting Common Issues
+
+### User Not Found in LMS
+
+**Causes:**
+- `lms_user_id` doesn't match LMS user identifier
+- Case sensitivity issues
+- User doesn't exist in LMS yet
+- Identifier format mismatch
+
+**Solutions:**
+- Verify identifier format and case
+- Check LMS user provisioning
+- Review attribute mapping configuration
+- Test with known working users
+
+### Custom Attribute Not Appearing
+
+**Causes:**
+- User doesn't have the attribute populated
+- Incorrect attribute mapping
+- IdP configuration issues
+- SSO application not assigned to user
+
+**Solutions:**
+- Verify user attribute data
+- Check IdP attribute mapping
+- Review application assignments
+- Test SSO response directly
+
+### Authentication Failures
+
+**Causes:**
+- Incorrect SSO URLs or certificates
+- SAML configuration mismatch
+- Token/assertion format issues
+- Network or firewall blocks
+
+**Solutions:**
+- Verify SSO configuration details
+- Check certificate validity
+- Review error messages and logs
+- Test network connectivity
+
+## Best Practices
+
+### Configuration Management
+
+- **Use version control** for IdP configurations when possible
+- **Document attribute mappings** and business logic
+- **Maintain staging environments** for testing
+- **Plan for disaster recovery** and backup configurations
+
+### User Experience
+
+- **Provide clear error messages** for failed logins
+- **Offer alternative authentication** methods as fallback
+- **Test user journeys** regularly
+- **Monitor authentication performance**
+
+### Maintenance
+
+- **Regularly review user attributes** for accuracy
+- **Monitor for deprecated features** in your IdP
+- **Update certificates** before expiration
+- **Review access permissions** periodically
+
+
+
+## Next Steps
+
+1. **Choose your Identity Provider** from the guides above
+2. **Review your LMS documentation** for specific requirements
+3. **Plan your user attribute mapping** strategy
+4. **Configure and test** in a development environment
+5. **Deploy to production** with proper monitoring
+
+For LMS-specific requirements and examples, refer to the individual integration guides in your LMS category documentation.
\ No newline at end of file