Managing Enterprise Application Access

Managing Enterprise Application Access

In the modern workplace, the traditional network perimeter has effectively disappeared. Employees no longer sit behind a corporate firewall accessing only local resources; instead, they use dozens, if not hundreds, of Software-as-a-Service (SaaS) applications, cloud platforms, and internal web apps from various locations and devices. This shift has made identity the new security perimeter. Microsoft Entra ID (formerly Azure Active Directory) serves as the central hub for managing this complexity through "Enterprise Applications."

Managing enterprise application access is about more than just giving a user a username and password. It is about creating a centralized, secure, and observable environment where you can control exactly who has access to what, under what conditions, and for how long. When you integrate an application into Entra ID, you gain the ability to enforce Multi-Factor Authentication (MFA), apply Conditional Access policies, and automate the provisioning of user accounts. This lesson will dive deep into the mechanics of how Entra ID handles these applications, the configuration of Single Sign-On (SSO), and the governance strategies required to keep your environment secure.

Understanding the Architecture: App Registrations vs. Enterprise Applications

One of the most common points of confusion for administrators is the distinction between an "App Registration" and an "Enterprise Application." While they are two sides of the same coin, they serve distinct purposes in the Entra ID ecosystem.

An App Registration is the global definition of the application. Think of it as the blueprint or the template. When a developer creates an application that needs to use Entra ID for identity, they register it in their home tenant. This registration defines the application's identity (Application ID), the redirect URIs where tokens are sent, and the API permissions the application requires to function.

An Enterprise Application, on the other hand, is a local representation—or an "instance"—of that application within your specific tenant. When you add an application from the Entra ID Gallery or grant consent to a multi-tenant application, a Service Principal is created in your tenant. This Service Principal is what we see under the "Enterprise Applications" blade. It is the object you use to assign users, configure Single Sign-On settings, and monitor sign-in logs.

Callout: The Blueprint vs. The House

To visualize the difference, imagine a set of architectural blueprints for a specific model of a house. The App Registration is the blueprint; it defines where the doors are, how the wiring works, and what the house looks like. An Enterprise Application is the actual house built in your neighborhood based on those blueprints. You can have many houses (Enterprise Applications in different tenants) built from a single set of blueprints (one App Registration), but each house has its own specific set of occupants (assigned users) and its own unique security system (Conditional Access policies).

Methods of Single Sign-On (SSO)

The primary goal of managing enterprise applications is to provide a smooth Single Sign-On experience. SSO allows users to sign in once with their primary corporate credentials and gain access to all their assigned applications without being prompted to enter their password again. Entra ID supports several SSO methods, each suited for different types of applications.

SAML-Based SSO

Security Assertion Markup Language (SAML) is the industry standard for web-based SSO. In a SAML flow, Entra ID acts as the Identity Provider (IdP), and the application acts as the Service Provider (SP). When a user tries to access the app, the app redirects them to Entra ID. After the user authenticates, Entra ID sends a SAML token (an XML document) back to the app containing "claims" about the user, such as their email address, name, and group memberships.

OpenID Connect (OIDC) and OAuth 2.0

OIDC is a newer standard built on top of the OAuth 2.0 protocol. It uses JSON Web Tokens (JWT) instead of XML. This is the preferred method for modern web applications and mobile apps because it is more lightweight and developer-friendly. Most modern SaaS applications found in the Entra Gallery use OIDC.

Password-Based SSO

Sometimes you encounter "legacy" applications that do not support SAML or OIDC. These apps usually have a simple HTML sign-in page with a username and password field. With Password-Based SSO, Entra ID securely stores the credentials for the application and "injects" them into the sign-in page on behalf of the user. While not as secure as federation (SAML/OIDC), it allows you to bring these older apps under the umbrella of Entra ID security policies.

Header-Based SSO

Many older on-premises applications use HTTP headers for authentication. To support these, Entra ID uses the Application Proxy or integrations with third-party controllers like F5 or Citrix. The proxy authenticates the user via Entra ID and then passes the user's identity to the application in the HTTP header.

SSO Comparison Table

Implementing Application Access: Step-by-Step

Adding an application to your tenant usually begins in the Entra ID Gallery. Microsoft maintains a massive library of pre-configured integrations for popular services like Salesforce, Slack, and AWS.

Step 1: Adding the Application

1. Navigate to the Microsoft Entra admin center.
2. Go to Identity > Applications > Enterprise applications.
3. Select New application.
4. Search for the application in the gallery. If it is a custom-built internal app, you would select "Create your own application."
5. Click Create. This process creates the Service Principal in your tenant.

Step 2: Configuring User Assignment

By default, many applications allow any user in your directory to sign in if they have the URL. To secure the application, you should change the "Assignment required?" setting to Yes in the application's properties.

1. Within the Enterprise Application, go to Properties.
2. Toggle Assignment required? to Yes.
3. Go to Users and groups and add the specific individuals or security groups who should have access.

Tip: Always prefer group-based assignment over individual user assignment. It makes auditing easier and allows you to use Dynamic Groups to automate access based on user attributes like "Department" or "Job Title."

Step 3: Setting up SSO (SAML Example)

If you are configuring a SAML application, you will need to exchange metadata between Entra ID and the application.

1. Select Single sign-on from the application menu and choose SAML.
2. You will see the Basic SAML Configuration section. Here, you enter the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL) provided by the application vendor.
3. In the Attributes & Claims section, define what information Entra ID sends to the app (e.g., user.principalname).
4. Download the Federation Metadata XML or copy the Login URL and Microsoft Entra Identifier to paste into the application's admin console.

The Role of Application Proxy

Not all applications live in the cloud. Many organizations still maintain critical web applications on-premises. Historically, accessing these required a VPN, which can be cumbersome for users and a security risk if the VPN allows broad network access.

The Microsoft Entra Application Proxy provides a secure way to publish on-premises web applications to the cloud. It involves installing a small agent (the Connector) on a Windows Server within your internal network. The Connector maintains an outbound connection to the Entra service.

When a user tries to access the internal app via its public URL, Entra ID authenticates the user, applies Conditional Access policies, and then tunnels the request through the outbound connection to the on-premises Connector, which then talks to the web server.

Note: The beauty of the Application Proxy is that you do not need to open any inbound ports on your firewall. This significantly reduces the attack surface of your internal network.

Managing Permissions and Consent

When an application wants to interact with data in your tenant (like reading a user's calendar or sending an email), it requires permissions. This is handled through the "Consent" framework.

User Consent

By default, users can grant apps permission to access their own data. For example, if a user signs into a productivity tool, the tool might ask for permission to "Read your profile." If user consent is allowed, the user can click "Accept," and the app gains access.

Admin Consent

Some permissions are too sensitive for a standard user to grant. These are "Tenant-wide" permissions, such as "Read all users' full profiles" or "Modify directory settings." These require a Global Administrator or a specialized admin role to grant consent on behalf of the entire organization.

Callout: Risk-Based Step-Up Consent

To balance security and usability, Microsoft uses "Risk-based step-up consent." If an application looks suspicious (e.g., it was recently registered or has a low reputation), Entra ID will block the user from consenting and require an administrator to review the request, even if the permission itself is relatively minor.

Configuring Consent Settings

To prevent users from accidentally giving a malicious app access to corporate data, you should configure consent settings:

1. Go to Enterprise applications > Consent and permissions > User consent settings.
2. The recommended setting is Allow user consent for apps from verified publishers, for selected permissions. This ensures that users can only grant access to "low impact" permissions to apps made by known, verified companies.

Securing Access with Conditional Access

Simply assigning a user to an application is only half the battle. You also need to define the conditions under which that access is granted. This is where Conditional Access (CA) comes in. CA acts as an "If-Then" engine.

• IF a user is in the Finance group...
• AND they are connecting from an unmanaged device...
• AND the sign-in risk is "Medium"...
• THEN require MFA and limit their session to 4 hours.

For every Enterprise Application, you should evaluate the sensitivity of the data it contains. A public lunch menu app might not need MFA, but your HR system or AWS console certainly does.

Example: Enforcing MFA for a Sensitive App

You can create a policy specifically targeting an Enterprise Application:

1. Go to Protection > Conditional Access.
2. Create a New policy.
3. Under Users, select the group assigned to the app.
4. Under Target resources, select the specific Enterprise Application.
5. Under Grant, select Require multi-factor authentication.
6. Set the policy to On and save.

Automating Management with PowerShell and Microsoft Graph

For organizations with hundreds of applications, manual configuration in the portal is not feasible. The Microsoft Graph API is the primary tool for automating application management. You can use the Microsoft.Graph PowerShell module to audit and modify enterprise applications.

Example: Listing all Enterprise Applications and their IDs

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Application.Read.Write.All"

# Get all Service Principals (Enterprise Applications)
$allApps = Get-MgServicePrincipal -All

# Display the DisplayName and AppId
$allApps | Select-Object DisplayName, AppId, Id | Format-Table

Example: Assigning a User to an Application

To programmatically assign a user, you need the ID of the Service Principal, the ID of the User, and the ID of the App Role (usually the "Default Access" role).

$userId = "user-guid-here"
$servicePrincipalId = "sp-guid-here"
$appRoleId = "00000000-0000-0000-0000-000000000000" # Default Access Role ID

New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $servicePrincipalId `
    -PrincipalId $userId `
    -ResourceId $servicePrincipalId `
    -AppRoleId $appRoleId

Governance and Access Reviews

Access to applications should never be "set it and forget it." Over time, users change roles or leave the company, yet they often retain permissions to applications they no longer need. This is known as "permission creep."

Access Reviews (part of Entra ID Governance) allow you to automate the periodic review of application access. You can configure a review so that every 90 days, a manager must confirm that their team members still need access to a specific application. If the manager doesn't respond or denies the access, Entra ID can automatically remove the user from the application.

Warning: Be careful when setting up "Auto-apply results" in Access Reviews. If a manager misses the notification and the system is set to "Remove access" if the reviewer doesn't respond, you could accidentally lock an entire department out of a critical tool. Always start with "Manual" application of results until you trust the process.

Common Pitfalls and How to Avoid Them

1. Forgetting the "Assignment Required" Toggle

The most common mistake is leaving "Assignment required?" set to "No." This effectively makes the application available to everyone in your company. While they still need to authenticate, you lose the ability to control the specific audience for the app. Always toggle this to "Yes" for sensitive applications.

2. Over-privileged Service Principals

When developers create App Registrations, they often request more permissions than they actually need (e.g., Directory.ReadWrite.All instead of User.Read). Regularly audit the "Permissions" tab in your Enterprise Applications to see what has been granted and revoke anything that isn't strictly necessary for the app to function.

3. Hardcoding Redirect URIs

When configuring SSO, ensure that the Redirect URIs are specific and secure (using HTTPS). Avoid using "localhost" or generic HTTP addresses in production, as these can be exploited in token-theft attacks.

4. Ignoring the Sign-in Logs

The Sign-in logs for an Enterprise Application are a goldmine of information. They tell you not just who is logging in, but why they were blocked. If a user complains they can't access an app, the "Conditional Access" tab within the sign-in log will tell you exactly which policy blocked them and which requirement (like MFA or a compliant device) they failed to meet.

Best Practices for Enterprise Application Management

1. Centralize on Entra ID: Whenever possible, use Entra ID as the single source of truth for all application identities. Avoid creating "siloed" accounts within individual SaaS apps.
2. Use the Gallery: Always check the Entra ID Gallery first before creating a "Custom" application. Gallery apps have pre-validated configurations and often support automated user provisioning (SCIM).
3. Implement Least Privilege: Only grant the minimum permissions required for an application. Use Admin Consent Workflow to allow users to request access to apps, which an admin can then review.
4. Enforce MFA Everywhere: There is no excuse for a modern enterprise application to not have MFA. Use Conditional Access to make it mandatory.
5. Monitor and Audit: Regularly review the "Audit logs" to see who changed application configurations and the "Sign-in logs" to detect suspicious access patterns.
6. Automate Lifecycle: Use SCIM (System for Cross-domain Identity Management) to automatically create, update, and deactivate user accounts in the SaaS application when their status changes in Entra ID.

Quick Reference: Key Roles for App Management

• Global Administrator: Can manage all aspects of the directory, including all applications.
• Application Administrator: Can create and manage all aspects of app registrations and enterprise applications, but cannot manage Conditional Access.
• Cloud Application Administrator: Similar to Application Administrator but cannot manage Application Proxy.
• Application Owner: A non-admin user assigned to a specific application. They can manage the users and groups for that specific app but cannot change tenant-wide settings.

Summary and Key Takeaways

Managing Enterprise Application access is the cornerstone of a modern security strategy. By centralizing identity, you move away from the chaos of fragmented credentials and toward a structured, policy-driven environment.

• Distinguish between App Registrations and Enterprise Applications: Understand that the App Registration is the definition, and the Enterprise Application (Service Principal) is the local instance where you apply security controls.
• Prioritize Federation: Use SAML or OIDC whenever possible. These protocols are more secure and provide a better user experience than password-based methods.
• Use Conditional Access as your Gatekeeper: Don't just rely on passwords. Use location, device health, and risk signals to decide whether to grant access.
• Bridge the Gap with App Proxy: Bring your legacy on-premises applications into the modern era by publishing them through the Entra Application Proxy.
• Control Consent: Prevent "Data Exfiltration by Consent" by restricting what permissions users can grant to third-party applications.
• Automate and Govern: Use Microsoft Graph for repetitive tasks and Access Reviews to ensure that permissions don't linger longer than they are needed.

By following these principles, you ensure that your organization's data remains secure while providing employees with the flexible, easy access they need to stay productive in a cloud-first world.