Single Sign-On (SSO)

Single Sign-On (SSO) allows users to authenticate using their organization’s central authentication service rather than maintaining separate Inventory Pro credentials. Once linked, users automatically log in when accessing the system through their organization’s network or authentication provider.

SSO eliminates password management overhead while improving security through centralized authentication policies and automatic session management.

Access: Framework → Link SSO Account (after initial login with Inventory Pro credentials)

Understanding Single Sign-On

SSO integrates with your organization’s authentication infrastructure to provide seamless access. Users log in once to their network/domain, and Inventory Pro automatically recognizes them based on linked credentials.

Screen Components:

• Current User: Displays logged-in Inventory Pro account
• SSO Credential: Shows detected network credential (domain account, certificate subject, or unique ID)
• Link Confirmation: Button to associate accounts
• Status Messages: Confirmation or error information

Key Operations:

• Link Account: Associate Inventory Pro user with SSO credential
• Auto-Login: Automatic authentication on subsequent visits
• Credential Detection: System reads authentication from server variables
• Session Management: Standard timeout and security policies apply

SSO Flow:

1. User authenticates to organization’s network/domain
2. User navigates to Inventory Pro
3. System detects SSO credential from browser/server
4. If linked: Automatic login
5. If not linked: Prompt for Inventory Pro credentials, then offer to link
6. Future access: Automatic authentication

SSO Methods

Linking SSO Accounts

Associates an existing Inventory Pro user account with organizational SSO credentials. This one-time setup enables automatic future logins.

Required:

• Existing Inventory Pro user account
• Active organizational authentication (domain login, smart card, or CAC)
• Security ID 163 permission

When to Link SSO:

• Migrating from password-based authentication to enterprise SSO
• Onboarding new users in SSO-enabled environments
• After directory changes (name changes, new certificates, etc.)
• When password management becomes burdensome

When NOT to Link SSO:

• Shared accounts or generic logins (SSO requires individual credentials)
• External users without organizational authentication
• Testing environments without domain trust
• Mobile-only users without smart card readers

Workflow:

1. Log in to Inventory Pro with username/password
2. System detects available SSO credential
3. Navigate to Framework → Link SSO Account
4. Review displayed SSO credential (verify it matches your organizational account)
5. Click Link Account to confirm association
6. System updates user record with SSO credential identifier
7. Confirmation message displays
8. Log out and test automatic login

What Happens:

• User record (zwUser table) updated with SSO credential
• Field AD_USER stores credential identifier:
  • Active Directory: Full domain account (e.g., DOMAIN\username)
  • Smart Card: Certificate subject (first 50 characters)
  • CAC: Unique ID from certificate (last 10 characters)
• Subsequent logins bypass password prompt
• Standard security and permissions continue to apply

Active Directory Authentication

Authenticates users based on Windows domain credentials. Users who have logged into their Windows domain automatically gain access without additional passwords.

Required Admin Options:

• Option 3: ActiveDirectoryLogon = True (enables AD authentication)

Server Requirements:

• IIS configured for Windows Authentication
• Domain trust relationship between web server and user domain
• LOGON_USER server variable populated

When to Use Active Directory:

• Corporate environments with Windows domains
• Users accessing from domain-joined computers
• Integrated Windows Authentication (IWA) requirements
• Organizations with established AD infrastructure

Technical Details:

• Credential Source: Request.ServerVariables("LOGON_USER")
• Format: DOMAIN\username
• Storage: zwUser.AD_USER field
• Validation: Checks for non-empty LOGON_USER variable
• IIS Settings: Windows Authentication enabled, Anonymous disabled

Security Considerations:

• Uses Windows security tokens
• Respects domain password policies
• Supports group memberships (future enhancement)
• Session timeout based on activity, not domain session

Smart Card Authentication

Certificate-based authentication using PKI smart cards. Users insert their smart card, enter PIN, and system validates certificate to grant access.

Required Admin Options:

• Option 3: SmartCardLogon = True (enables smart card authentication)

Server Requirements:

• IIS configured for client certificate authentication
• Certificate trust chain configured
• Smart card readers on client computers
• CERT_SUBJECT server variable populated

When to Use Smart Cards:

• High-security environments requiring two-factor authentication
• Organizations with existing PKI infrastructure
• Compliance requirements for certificate-based access
• Users with issued smart cards or hardware tokens

Technical Details:

• Credential Source: Request.ServerVariables("CERT_SUBJECT")
• Format: First 50 characters of certificate subject
• Storage: zwUser.AD_USER field
• Validation: Checks for non-empty CERT_SUBJECT variable
• IIS Settings: Client certificates required or accepted

Certificate Subject Example:

CN=John Doe,OU=Users,O=Organization,C=US

Server Configuration

Prerequisites

• Active Inventory Pro Installation
• Windows Server 2012 or greater
• IIS 8.0 or greater
• Active Directory domain (for AD authentication)
• DOD PKI certificates (for CAC authentication)
• Certificate authority trust chain (for Smart Card authentication)

Windows Server Setup - Active Directory

Configure Windows Authentication module on the web server:

1. On the taskbar, click Server Manager
2. In Server Manager, click the Manage menu, then Add Roles and Features
3. In the Add Roles and Features wizard, click Next
4. Select the installation type and click Next
5. Select the destination server and click Next
6. On the Server Roles page, expand Web Server (IIS) → Web Server → Security
7. Select Windows Authentication, click Next
8. On the Select features page, click Next
9. On the Confirm installation selections page, click Install
10. On the Results page, click Close

IIS Configuration - Active Directory

Enable Windows Authentication for the Inventory Pro application:

1. Open IIS Manager
2. Navigate to your Inventory Pro site
3. In the IIS section of Features View, open Authentication
4. Right-click “Anonymous Authentication” and select “Disable”
5. Right-click “Windows Authentication” and select “Enable”

Verification: Access the site - you should be prompted for domain credentials or automatically authenticated if on the domain.

IIS Configuration - CAC/Smart Card

Enable client certificate authentication:

1. Open IIS Manager
2. Navigate to your Inventory Pro site
3. In the IIS section of Features View, open Authentication
4. Select “Active Directory Client Certificate Authentication”
5. Right-click and select “Enable”
6. Configure SSL Settings:
   • Open SSL Settings for the site
   • Set Client certificates to Require or Accept
   • Click Apply

Certificate Trust Configuration:

• Install trusted root CA certificates in server’s Trusted Root Certification Authorities store
• For CAC: Install DOD PKI root and intermediate certificates
• For Smart Cards: Install organizational PKI certificate chain
• Restart IIS after certificate installation

Inventory Pro Configuration

Configure SSO authentication methods in global.asa:

Active Directory Configuration:

1. Open Inventory Pro directory and select global.asa for editing
2. Change Application("ActiveDirectoryLogon") = False to Application("ActiveDirectoryLogon") = True
3. Optional: Enable forced AD (no password fallback):
   • Change Application("ActiveDirectoryForce") = False to Application("ActiveDirectoryForce") = True
4. Save changes

Smart Card Configuration:

1. Open global.asa for editing
2. Change Application("SmartCardLogon") = False to Application("SmartCardLogon") = True
3. Optional: Enable forced Smart Card:
   • Change Application("SmartCardForce") = False to Application("SmartCardForce") = True
4. Save changes

CAC Configuration:

1. Open global.asa for editing
2. Change Application("CACCardLogon") = False to Application("CACCardLogon") = True
3. Note: This automatically implies SmartCardLogon = True
4. Save changes

User Field Configuration (enable AD_USER field for linking):

1. Open Inventory Pro in web browser
2. Navigate to System → Accounts → System Users
3. Select any user account
4. Click Customize link at bottom right of page
5. If AD_USER field exists:
   • Toggle Visible option on
   • Click Save
6. If AD_USER field doesn’t exist:
   • Click Add New
   • Select AD_USER as the column
   • Name it “SSO Credential” or similar
   • Enable Visible, Add, and Modify options
   • Set field type to Text
   • Click Save

Restart Application:

• Recycle the IIS application pool or run iisreset to apply global.asa changes
• Test SSO authentication after restart

CAC Authentication

Common Access Card authentication for government and military installations. Uses the unique identifier from CAC certificates for access control.

Required Admin Options:

• Option 3: CACCardLogon = True (enables CAC authentication)
• Automatically implies SmartCardLogon = True

Server Requirements:

• Same as Smart Card authentication
• DOD PKI certificates trusted
• CAC-specific certificate format recognition

When to Use CAC:

• Department of Defense installations
• Federal contractors with CAC requirements
• Government facilities using CAC infrastructure
• NIST 800-53 compliance requirements

Technical Details:

• Credential Source: Request.ServerVariables("CERT_SUBJECT")
• Format: Last 10 characters of certificate subject (unique EDIPI)
• Storage: zwUser.AD_USER field
• Validation: Checks for non-empty CERT_SUBJECT, extracts unique ID
• EDIPI: Electronic Data Interchange Personal Identifier

CAC vs Standard Smart Card:

• CAC uses unique 10-digit identifier (EDIPI) from end of subject
• Standard smart cards use beginning of subject (CN, OU, etc.)
• Both use same technical infrastructure
• Separate configuration options allow targeting specific certificate types

Validation and Business Rules

Credential Validation

• SSO credential must be detected by server before linking
• User must have valid Inventory Pro account
• Cannot link one SSO credential to multiple user accounts
• Re-linking updates credential (useful after certificate renewal or name changes)

Permission Requirements

• Security ID 163 required to access Link SSO page
• Standard login permissions apply after SSO authentication
• SSO does not bypass existing security model
• Warehouse, read-only, and feature permissions unchanged

Session Management

• SSO creates standard user session
• Timeout based on inactivity (configurable via admin options)
• Logout terminates session but not organizational authentication
• Re-authentication happens automatically if session expires

Fallback Authentication

• If SSO credential not detected, standard login prompt appears
• Users can still log in with username/password if SSO fails
• Helpful for troubleshooting or accessing from non-domain computers
• No loss of functionality if SSO misconfigured

Admin Options

Configuration Notes:

• Multiple SSO methods can be enabled simultaneously
• System attempts SSO authentication in order: CAC → Smart Card → Active Directory
• First available credential is used
• Admin options configured in global.asa or via Options interface

Best Practices

SSO Implementation. Plan SSO rollout carefully to ensure infrastructure readiness. Test with small user groups before organization-wide deployment. Verify IIS authentication settings, certificate trust chains, and domain relationships. Document the linking process for users and provide assistance during transition. Maintain password-based access as fallback during initial implementation. Monitor for authentication errors and adjust timeout settings based on user workflows.

Certificate Management. Establish clear procedures for certificate renewal and expiration. Users should re-link accounts after certificate changes to avoid access disruption. Set calendar reminders before certificate expiration dates. For CAC environments, coordinate with issuing authorities for renewal timing. Test certificate updates in non-production environment first. Maintain documentation of certificate requirements and trusted root authorities.

Security Considerations. SSO does not reduce security requirements within Inventory Pro. Continue enforcing least-privilege access, regular permission audits, and security training. Monitor session activity for unusual patterns. Configure appropriate session timeouts balancing security and usability. Disable unused SSO methods to reduce attack surface. Coordinate with IT security team for compliance verification and security testing. Ensure audit logs capture SSO authentication events.

Troubleshooting

Issue: Link SSO button not appearing

Problem: User logged in but no option to link SSO account. Solution: Verify admin option (ActiveDirectoryLogon, SmartCardLogon, or CACCardLogon) enabled in global.asa. Check that IIS authentication configured correctly. Confirm server variable (LOGON_USER or CERT_SUBJECT) being populated. Review error logs for detection failures. Prevention: Test SSO configuration with administrative account before user rollout. Create standard operating procedure for SSO verification.

Issue: SSO credential not detected

Problem: System shows “SSO credential not available” or empty credential. Solution: For Active Directory: Verify Windows Authentication enabled in IIS and Anonymous disabled. Confirm user logged into domain. For Smart Cards/CAC: Check client certificate requirement in IIS. Verify smart card reader connected and card inserted. Test certificate installation in browser. Prevention: Document required IIS authentication settings. Provide user checklist for smart card access requirements.

Issue: Access denied after linking SSO

Problem: Account linked successfully but login fails. Solution: Verify user account permissions unchanged. Check that domain account format matches exactly (case-sensitive). For certificate authentication, confirm certificate not expired. Review session timeout settings. Check that user not disabled or marked read-only. Prevention: Test linking process end-to-end before production use. Monitor authentication logs for failures.

Issue: SSO works on some computers but not others

Problem: User can authenticate via SSO on certain computers only. Solution: For AD: Verify all computers domain-joined and trusting web server. For Smart Cards: Confirm card readers installed with proper drivers. Check browser certificate settings consistent across computers. Verify network connectivity to domain controllers and certificate services. Prevention: Standardize computer configurations. Document minimum requirements for SSO access.

Issue: Certificate subject not matching

Problem: Smart card inserted but wrong certificate detected. Solution: User may have multiple certificates. Check certificate store in browser. Select correct certificate when prompted. Remove expired or invalid certificates. For CAC, verify correct EDIPI extracted (last 10 characters). Prevention: Train users on certificate selection. Implement certificate cleanup procedures.

Issue: Session timeout too aggressive

Problem: Users logged out during active work. Solution: Adjust session timeout in admin options. Balance security requirements with user workflow needs. Consider extending timeout for users with long-duration tasks. Prevention: Survey users on typical session lengths. Set timeouts based on actual usage patterns.

Issue: Cannot unlink SSO credential

Problem: User needs to revert to password authentication. Solution: Clear AD_USER field in zwUser table via database query or admin interface. User can then log in with password. Useful when certificate expires or user changes domains. Prevention: Provide administrative interface for SSO credential management.

Key Reports

SSO-specific reporting is limited as authentication occurs at infrastructure level. Standard user activity reports capture SSO logins:

Authentication Logging: System logs all authentication events including SSO credential detection, link operations, and login success/failure. Review logs regularly to identify configuration issues or security concerns.

Related Topics

• User Management - Creating and configuring user accounts that can be linked to SSO
• Security - Permission management and security policies that apply after SSO authentication
• API - API authentication also supports SSO-based token generation
• Admin Options - SSO configuration settings and global authentication policies