10.1 Enterprise Applications Integration
Key Takeaways
- Enterprise applications in Microsoft Entra ID are the tenant-local service principal instances you administer for SSO, assignment, provisioning, and permissions—distinct from the multi-tenant application object (app registration).
- Application Administrator and Cloud Application Administrator are the primary Entra roles for managing enterprise apps and app registrations; Global Administrator is broader and should not be the default day-to-day app admin role.
- Gallery SaaS apps are integrated from the Entra enterprise application gallery with SSO modes (SAML, OIDC/OAuth, password-based, linked) and optional automated provisioning where supported.
- User assignment required, group assignment, and app roles control who can access an app and what application-defined roles they receive in tokens.
- Application collections organize enterprise apps in My Apps / the end-user launcher without replacing security controls such as Conditional Access or assignment requirements.
Enterprise applications on the SC-300 map
Domain 3 of SC-300 (Plan and implement workload identities, about 20–25%) does not stop at managed identities and service principal theory. Identity and Access Administrators spend much of their real work in Enterprise applications: integrating SaaS, requiring assignment, mapping groups to app roles, reviewing permissions, and organizing the app launcher. This section is the admin-facing half of the app model; section 10.2 deepens app registrations, API permissions, and app roles from the developer definition side; section 10.3 covers Application Proxy and consent.
Recall the two-layer model from service principal fundamentals:
| Layer | Portal home | What you configure |
|---|---|---|
| Application object | App registrations | Client ID, redirect URIs, credentials, exposed APIs, app role definitions, requested API permissions |
| Service principal | Enterprise applications | Tenant instance: SSO, user/group assignment, provisioning, owners, permissions granted, properties, self-service |
When a multi-tenant SaaS product is consented into Contoso, Contoso gets an enterprise application (SP) without owning the vendor’s app registration. When Contoso builds its own line-of-business app, Contoso usually owns both the registration and the enterprise app in the home tenant.
App-level versus tenant-level settings
SC-300 items often hide the scope of a setting. Train yourself to ask: is this only for one app, or for the whole tenant?
App-level (enterprise application) settings
On a single enterprise application you typically manage:
| Area | Examples |
|---|---|
| Properties | Enabled for users to sign-in; Assignment required?; visible to users; notes; logo |
| Owners | Who can manage this app instance without broader directory roles |
| Users and groups | Direct user or group assignments; app role values |
| Single sign-on | SAML, OIDC, password-based, linked, disabled |
| Provisioning | SCIM automated user provisioning (if supported) |
| Permissions | Admin consents and granted delegated/application permissions |
| Conditional Access | App can be a CA cloud app target (policy lives in CA, not only on the SP blade) |
| Self-service | Allow users to request access (where features apply) |
Assignment required = Yes is a high-yield control: only assigned users/groups can obtain tokens for that app (for apps that honor assignment). Pair it with group-based assignment for scale. Assignment required = No means any user in the tenant who can authenticate may use the app (subject to other controls)—convenient for broadly licensed Microsoft first-party apps, risky for sensitive custom or third-party apps left wide open.
Tenant-level settings that shape all apps
| Tenant control | Why it matters for enterprise apps |
|---|---|
| User consent settings | Whether users can consent to apps and which permission classifications |
| Admin consent workflow | Request/approval path when users cannot self-consent |
| Enterprise application user settings | Whether users can register apps; admin portal access nuances |
| External collaboration / guest settings | How guests appear in assignment and SaaS access |
| Conditional Access | Block, MFA, compliant device, session controls for cloud apps |
| Security defaults / authentication strength | Baseline sign-in requirements for app access |
| Cross-tenant access | B2B collaboration impact on partner use of apps |
Exam trap: fixing “users can consent to risky OAuth apps” is often a tenant consent policy problem, not an SSO toggle on one gallery app. Fixing “only Finance may use Workday” is an assignment + groups problem on that enterprise app (plus CA if device/risk conditions apply).
Entra roles for managing applications
Do not use Global Administrator as the routine role for app onboarding. SC-300 expects least privilege among built-in directory roles:
| Role | Typical app-related power |
|---|---|
| Application Administrator | Create and manage all aspects of enterprise apps and app registrations; can grant consent for delegated and application permissions in many scenarios; broad app management |
| Cloud Application Administrator | Similar application management scope but cannot manage application proxy settings (and related on-premises app proxy configuration)—important distinction |
| Application Developer | Create app registrations they own; more limited than Application Administrator |
| Hybrid Identity Administrator / other roles | Not primary app gallery operators; appear in hybrid or identity infrastructure stems |
| Global Administrator | Full directory; includes app powers but over-privileged for daily SaaS integration |
| Privileged Role Administrator | Assigns directory roles (including app admin roles); does not replace day-to-day app config |
Exam cue: stem says “manage enterprise applications and grant admin consent but should not manage Application Proxy” → Cloud Application Administrator. Stem includes publishing on-premises apps via Application Proxy → need Application Administrator (or Global Admin), not Cloud Application Administrator alone.
Also remember owners on an enterprise app or app registration: owners can manage that object without holding Application Administrator tenant-wide—useful for app-centric delegation and audits.
Integrate SaaS apps from the gallery
Microsoft Entra application gallery lists thousands of pre-integrated SaaS apps. Integration pattern (conceptual steps exam cares about):
- Enterprise applications → New application → Browse Microsoft Entra Gallery.
- Search the SaaS product; select the gallery tile (prefer gallery over non-gallery custom when a tile exists).
- Name the enterprise app instance; create.
- Configure Single sign-on mode the vendor supports:
| SSO mode | When you see it |
|---|---|
| SAML | Classic enterprise SaaS federation (IdP-initiated and/or SP-initiated) |
| OpenID Connect / OAuth | Modern apps using Entra as OIDC provider |
| Password-based | Vaulted forms auth when federation is unavailable (weaker; still better than shared sticky notes) |
| Linked | Deep link to an app already authenticated another way |
| Disabled | App object for provisioning or assignment without Entra SSO |
- Exchange metadata (Entity ID, Reply URL, certificates) with the SaaS admin; download Entra federation metadata or cert as required.
- Set User assignment required and assign pilot groups.
- If the gallery app supports it, configure automatic provisioning (SCIM) with a provisioning identity and attribute mappings; start in incremental mode and monitor provisioning logs.
- Validate with a pilot user: My Apps tile, IdP-initiated SSO, and SP-initiated login from the SaaS side.
- Expand assignment; add Conditional Access targeting the cloud app; document owners.
Non-gallery applications still appear as enterprise apps when you register custom apps or consent to multi-tenant apps. Gallery simply accelerates SAML/OIDC templates and provisioning connectors.
| Integration concern | Entra control |
|---|---|
| Who can launch the app | Assignment required + users/groups |
| Strong authentication | Conditional Access on the cloud app |
| Joiner-mover-leaver in SaaS | App provisioning / SCIM + group assignment |
| Token claims for roles | App roles / SAML claims / optional claims |
| Break access quickly | Disable sign-in on enterprise app; remove assignment |
Assign users, groups, and app roles
Users and groups
Assignment is how identity admins express entitlement to use the app at the service principal:
- Prefer security groups (or assigned Microsoft 365 groups where appropriate) over thousands of direct user assignments.
- Nested group behavior and licensing of features can matter operationally; for exam purposes, group assignment is the scalable pattern.
- Guests can be assigned when B2B collaboration is allowed and the app is appropriate for external users.
- Removing assignment (or disabling the enterprise app) is a primary offboarding control for SaaS that relies on Entra for SSO.
Application roles (assignments)
Many apps define app roles (for example Admin, Reader, Contributor) on the application object. When you assign a user or group to the enterprise app, you can select an app role. That role value is emitted in tokens (e.g., roles claim) so the application can authorize inside its own RBAC.
| Concept | Meaning |
|---|---|
| App role definition | Declared on app registration (“Expose” / App roles) |
| App role assignment | User/group assigned to SP with a role value |
| Directory role | Entra administrative role (Application Administrator)—different plane |
| Azure RBAC | Azure resource authorization for a principal—different plane |
Do not confuse Entra directory roles with application roles. Granting someone Application Administrator does not make them Payroll.Admin inside Workday; assigning Payroll.Admin app role does not let them manage all enterprise apps in the tenant.
Assignment required and first-party apps
Some Microsoft apps are widely used without tight assignment. For sensitive custom line-of-business and many third-party SaaS apps, set User assignment required? to Yes so discovery and token issuance respect your assignments. Combine with My Apps collections for UX, not as a substitute for assignment.
Application collections
Application collections (My Apps collections) let admins group enterprise apps into logical sets users see in the My Apps portal—for example “HR apps,” “Finance,” “All company.” Collections improve findability and navigation; they are not a security boundary by themselves.
| Collections do | Collections do not |
|---|---|
| Organize tiles in My Apps | Replace Conditional Access |
| Help users discover approved apps | Grant permissions or app roles |
| Support admin-curated experiences | Override “assignment required” |
| Reduce clutter versus a flat app list | Substitute for access packages / governance |
Exam trap: choosing “create a collection” as the answer to “only auditors may access the SOX app” is wrong—use assignment, app roles, entitlement management, or CA. Collections answer “users cannot find the right app among fifty tiles.”
Operational checklist for identity admins
- Prefer gallery apps when available; document SSO mode and contacts.
- Set owners on every non-trivial enterprise app.
- Enable assignment required for apps that should not be tenant-wide.
- Assign groups, map app roles, and integrate joiner-mover-leaver via groups or provisioning.
- Apply Conditional Access to the cloud app for MFA, device, location, and session needs.
- Review permissions granted to the SP (especially application permissions).
- Use least-privilege Entra roles (Application Administrator / Cloud Application Administrator) for operators.
- Use collections for My Apps UX after security is correct.
SC-300 scenario drill
- “Integrate Salesforce with SAML and limit to Sales group” → gallery app, SAML SSO, assignment required, assign Sales group.
- “Helpdesk must manage apps but not Application Proxy” → Cloud Application Administrator.
- “Users see too many tiles” → application collections (plus keep assignment hygiene).
- “App needs Manager vs Employee in the token” → define app roles; assign groups to roles on the enterprise app.
- “Vendor multi-tenant app appeared after a user consented” → enterprise app (SP) in your tenant; review permissions and consent policies (section 10.3).
A helpdesk identity operator must create enterprise applications, configure gallery SSO, and manage app registrations, but must not manage Microsoft Entra Application Proxy. Which built-in role best fits least privilege?
You integrate a gallery SaaS app and must ensure only members of the Finance security group can use it. Which configuration is most appropriate on the enterprise application?
In Microsoft Entra ID, what is the enterprise application primarily representing in a tenant?
What is the primary purpose of application collections in Microsoft Entra ID?