Security Standard 08: Single Sign-On (SSO) Integration Levels
Standard Details
The purpose of this standard is to establish a consistent method for classifying applications integrated with Indiana Wesleyan University's Microsoft Entra ID environment based on the depth of identity integration, authorization centralization, and access control capabilities.
Not all SSO integrations provide the same level of security. Some applications use Entra ID only for authentication, while others leverage centralized authorization, role management, and continuous access enforcement.
This standard defines four SSO Integration Levels that allow Information Security, IT Governance, and application owners to:
- Evaluate identity-related risk consistently.
- Determine whether an application's authorization model aligns with data sensitivity.
- Identify opportunities to centralize access management.
- Establish minimum identity requirements for regulated or high-risk systems.
- Support future Zero Trust initiatives.
The SSO Level designation becomes part of the application's official security review and risk assessment documentation.
Corresponding Policy
The official Identity, Single Sign-On (SSO), and Application Authorization Policy that governs identity and access management serves as the parent policy for this standard.
The official Information Security Policy that is the parent to this standard is located in the Official IWU Policy Warehouse
Standard Statements
Scope
This standard applies to:
- All applications integrated with IWU Microsoft Entra ID.
- SaaS platforms using SAML, OIDC, OAuth, or SCIM.
- Internally developed applications utilizing Entra ID authentication.
- Applications requiring institutional SSO approval.
- Applications storing, processing, or transmitting institutional data.
This standard does not apply to:
- Applications using local authentication only.
- Applications not approved for institutional SSO.
- Consumer services not integrated with IWU identity systems.
Requirements
1. SSO Level Classification
1.1 Classification Requirement
Every application integrated with Microsoft Entra ID shall be assigned an SSO Integration Level during the security review process.
The designated level must be documented in:
-
Application inventory records
-
Security review documentation
-
Risk assessment records
-
Identity governance documentation
1.2 Review Requirement
The assigned level must be reviewed whenever:
-
The application's identity architecture changes.
-
Authorization methods change.
-
New Entra integration capabilities are implemented.
-
Significant vendor upgrades occur.
2. SSO Level Definitions
Level 1 — Authentication Only
Definition
Microsoft Entra ID performs user authentication only.
Authorization decisions, permissions, and role assignments remain entirely within the application.
The application receives identity information but does not consume group memberships, application roles, or centralized authorization claims.
Characteristics
- SSO provides login convenience.
- User lifecycle is partially centralized.
- Authorization remains decentralized.
- Administrative effort remains high.
- Access reviews must often occur inside the application.
Authorization Ownership
Application Administrator
Typical Indicators
- No App Roles configured in Entra.
- No group claims utilized.
- Roles assigned manually in the SaaS interface.
- Entra group membership changes do not affect permissions.
Examples
- Zoom (basic SAML)
- Slack (basic SSO)
- SurveyMonkey
- Many higher education SaaS platforms
Risk Considerations
Risks include:
- Manual role administration increases the likelihood of excessive or inappropriate access.
- User deprovisioning may not automatically remove permissions within the application.
- Access reviews often require separate administration within the SaaS platform.
- Authorization decisions lack centralized visibility and auditability.
Real-World Test
Ask: Who controls the permissions?
If the answer is: The application administor assigns them manually the application is likely Level 1.
Level 2 — Attribute Aware
Definition
Microsoft Entra ID authenticates users and provides identity attributes or group claims.
The application consumes those attributes and maps them to internal permissions.
Authorization still resides within the application, but authorization decisions are influenced by centrally managed identity data.
Characteristics
- Centralized group management.
- Partial automation of authorization.
- Reduced administrative overhead.
- Improved consistency.
Authorization Ownership
Application + Entra Groups
Typical Indicators
- Group claims enabled.
- Security groups mapped to application roles.
- Role changes occur based on group membership.
- Application still contains authorization logic.
Examples
- ServiceNow
- Workday
- Canvas LMS
- Atlassian Cloud
- Salesforce (group mapping)
Risk Considerations
Risks include:
- Incorrect group membership can automatically grant elevated privileges.
- Authorization visibility is split between Entra ID and the application.
- Group sprawl and poor group governance can lead to permission creep.
- Authorization depends on the vendor correctly consuming and enforcing group claims.
Real-World Test
Ask: Do users receive permissions based on Entra group membership?
If the answer is: If yes, the application is generally Level 2.
Level 3 — Role Centric (Federated Authorization)
Definition
Authorization is centrally defined within Microsoft Entra ID through App Roles.
Applications consume role claims and enforce permissions based entirely upon centrally managed role assignments.
Characteristics
- Centralized authorization.
- Reduced administrative complexity.
- Strong governance visibility.
- Improved auditability.
- Supports least privilege models.
Authorization Ownership
Microsoft Entra ID
Typical Indicators
- App Roles defined in App Registration.
- Users or groups assigned directly to App Roles.
- Application consumes role claims.
- Minimal local authorization administration.
Examples
- Custom Azure applications
- Modern cloud-native applications
- Advanced SaaS platforms supporting App Roles
Risk Considerations
Risks include:
- Misconfigured App Roles can impact access across multiple users or applications.
- Poor role design may create excessive privileges or role overlap.
- Centralized authorization requires mature governance and approval processes.
- Incorrect role assignments can result in broad privilege escalation.
Real-World Test
Ask: Can I determine who has administrative privileges without logging into the application?
If the answer is: If the answer is yes and can be answered entirely within Entra ID, the application is Level 3.
Level 4 — Continuous / Policy-Driven Access
Definition
Identity is continuously evaluated throughout the user's session.
Access decisions incorporate:
-
Conditional Access
Device compliance
User risk
Session risk
Continuous Access Evaluation (CAE)
Authorization becomes dynamically enforced based on real-time security signals rather than solely at login.
Characteristics
- Zero Trust aligned.
- Continuous verification.
- Real-time access enforcement.
- Immediate response to risk conditions.
Authorization Ownership
Entra ID + Continuous Security Signals
Typical Indicators
- Continuous Access Evaluation enabled.
- Conditional Access enforced during active sessions.
- Device compliance affects live access.
- Risk events can terminate active sessions.
Examples
- Microsoft Teams
- SharePoint Online
- Exchange Online
- OneDrive
Risk Considerations
Risks include:
- Complex Conditional Access policies may create unintended access disruptions.
- False-positive risk detections can interrupt legitimate business activities.
- Access decisions depend on the accuracy of device compliance and risk signals.
- Identity infrastructure failures may affect application availability and user access.
Real-World Test
Ask: Can access be revoked immediately while the user is still logged in?
If the answer is: If yes, the application is likely Level 4.
3. Minimum SSO Requirements by Data Classification
| Data Sensitivity | Minimum SSO Level |
|---|---|
| Public | Level 1 |
| Internal | Level 1 |
| Institutional | Level 2 |
| Confidential | Level 2 |
| HR Data | Level 3 |
| Financial Data | Level 3 |
| PCI Data | Level 3 |
| HIPAA Data | Level 3 |
| Privileged Administrative Systems | Level 3 |
| Zero Trust / High Assurance Systems | Level 4 |
4. Risk Assessment Guidance
During application reviews, reviewers shall determine:
4.1 Classification
- Assigned SSO Level
- Evidence supporting classification
- Authorization model
4.2 Alignment
Determine whether:
- The assigned level aligns with data sensitivity.
- Additional controls are required.
- Remediation is necessary.
4.3 Exceptions
Applications operating below the recommended level may require:
- Documented risk acceptance
- Compensating controls
- Annual review by Information Security
5. Quick Decision Matrix
| Observation | SSO Level |
|---|---|
| Roles assigned manually in application | Level 1 |
| Group membership influences permissions | Level 2 |
| App Roles managed in Entra ID | Level 3 |
| Access can be revoked during active session | Level 4 |
Additional Control Recommendations
Level 1 Applications
- Quarterly access reviews
- Enhanced administrative oversight
- Manual role audits
Level 2 Applications
- Standardized group naming
- Group ownership assignments
- Automated provisioning where feasible
Level 3 Applications
- Role governance process
- Periodic entitlement reviews
- Privileged role monitoring
Level 4 Applications
- Conditional Access enforcement
- Device compliance requirements
- Continuous Access Evaluation
- Risk-based authentication policies
Publication Tracking
| Author | Michael Madl , Chief Information Security Officer |
|---|---|
| Revision Date: | Wed, 24 Jun 2026 - ver.8 |
| Notes: | Final Version - |