Merge pull request #230879 from janicericketts/patch-66

Adding University multilateral federation

Author: Stacyrch140

articles/active-directory/fundamentals/media/multilateral-federation-baseline/typical-baseline-environment.png

@@ -0,0 +1,79 @@
+---
+title: University multilateral federation baseline design
+description: Baseline design for a multilateral federation solution for universities.
+services: active-directory
+author: janicericketts
+manager: martinco
+ms.service: active-directory
+ms.workload: identity
+ms.subservice: fundamentals
+ms.topic: conceptual
+ms.date: 04/01/2023
+ms.author: jricketts
+ms.custom: "it-pro"
+ms.collection: M365-identity-device-management
+---
+
+# Baseline architecture overview
+
+Microsoft frequently speaks with research universities that operate in hybrid environments in which applications are either cloud-based or hosted on-premises. In both cases, applications can use different authentication protocols. In some cases, these protocols are reaching end-of-life or are not providing the required level of security.
+
+[![Diagram of a typical university architecture including cloud and on-premises areas with trust, synchronization, and credential validation paths.](media/multilateral-federation-baseline/typical-baseline-environment.png)](media/multilateral-federation-baseline/typical-baseline-environment.png#lightbox)
+
+Applications drive much of the need for different authentication protocols and different identity management mechanisms (IdM).
+
+In research university environments, research apps often drive IdM requirements. A federation provider, such as Shibboleth, might be used as a primary identity provider (IdP). If this is the case, Azure AD is often configured to federate with Shibboleth. If Microsoft 365 apps are also in use, Azure AD enables you to configure integration.
+
+Applications used in research universities operate in various portions of the overall IT footprint:
+
+* Research and multilateral federation applications are made available through InCommon and EduGAIN.
+
+* Library applications provide access to electronic journals and other e-content providers.
+
+* Some applications use legacy authentication protocols such as Central Authentication Service (CAS) to enable single sign-on.
+
+* Student and faculty applications often use multiple authentication mechanisms. For example, some are integrated with Shibboleth or other federation providers, while others are integrated with Azure AD.
+
+* Microsoft 365 applications are integrated with Azure AD.
+
+* Windows Server Active Directory (AD) might be in use and synchronized to Azure AD.
+
+* Lightweight Directory Access Protocol (LDAP) is in use at many universities that might have an external LDAP directory or Identity Registry. These registries are often used to house confidential attributes, role hierarchy information, and even certain types of users, such as applicants. 
+
+* On-premises AD, or an external LDAP directory, is often used to enable single-credential sign-in for non-web applications and various non-Microsoft operating system sign-ins. 
+
+## Baseline architecture challenges
+
+Often, baseline architectures evolve over time, introducing complexity and rigidness to the design and ability to update. Some of the challenges with using the baseline architecture include:
+
+* **Hard to react to new requirements** - Having a complex environment makes it hard to quickly adapt and keep up with the most recent regulations and requirements. For example, if you have apps in lots of different locations and these apps are all connected in different ways with different IdMs, you run into the problem of where to locate multi-factor authentication (MFA) services and how to enforce MFA. Higher education also experiences fragmented service ownership. The people responsible for key services such as enterprise resource planning (ERP), learning management system (LMS), division, and department solutions might resist efforts to change or modify the systems they operate.
+
+* **Can't take advantage of all Microsoft 365 capabilities for all apps** (Intune, Conditional Access, passwordless, etc.) - Many universities want to move towards the cloud and leverage their existing investments in Azure AD. However, with a different federation provider as their primary IdP, universities can't take advantage of all the Microsoft 365 capabilities for the rest of their apps.
+
+* **Complexity of solution** - There are many different components to manage, with some components in the cloud and some on-premises or in IaaS instances. Apps are operated in many different places. From a user perspective, this can be a disjointed experience. For example, sometimes users see a Shibboleth login page and other times an Azure AD login page.
+
+We present three different solutions, designed to solve these challenges, while also addressing the following requirements:
+
+* Ability to participate in multilateral federations such as InCommon and eduGAIN
+
+* Ability to support all types of apps (even those that require legacy protocols)
+
+* Ability to support external directories and attribute stores
+
+These three solutions are presented in order from most preferred to least preferred. Each satisfies requirements but introduces tradeoff decisions expected in a complex architecture. Based on your requirements and starting point, select the one that best suits your environment. A decision tree is provided to help aid in this decision.
+
+
+## Next steps
+
+See these related multilateral federation articles:
+
+[Multilateral federation introduction](multilateral-federation-introduction.md)
+
+[Multilateral federation solution one - Azure AD with Cirrus Bridge](multilateral-federation-solution-one.md)
+
+[Multilateral federation solution two - Azure AD to Shibboleth as SP Proxy](multilateral-federation-solution-two.md)
+
+[Multilateral federation solution three - Azure AD with ADFS and Shibboleth](multilateral-federation-solution-three.md)
+
+[Multilateral federation decision tree](multilateral-federation-decision-tree.md)
+

articles/active-directory/fundamentals/media/multilateral-federation-decision-tree/tradeoff-decision-matrix.png

@@ -0,0 +1,49 @@
+---
+title: University multilateral federation decision tree
+description: Use this decision tree to help design a multilateral federation solution for universities.
+services: active-directory
+author: janicericketts
+manager: martinco
+ms.service: active-directory
+ms.workload: identity
+ms.subservice: fundamentals
+ms.topic: conceptual
+ms.date: 04/01/2023
+ms.author: jricketts
+ms.custom: "it-pro"
+ms.collection: M365-identity-device-management
+---
+
+# Decision tree
+
+Use this decision tree to help you determine the solution best suited for your environment.
+
+[![Diagram that shows decision matrix with key criteria to help choose between solutions one, two, and three.](media/multilateral-federation-decision-tree/tradeoff-decision-matrix.png)](media/multilateral-federation-decision-tree/tradeoff-decision-matrix.png#lightbox)
+
+## Migration resources
+
+The following are resources to help with your migration to the solutions covered in this content.
+
+| Migration Resource   | Description           | Relevant for  migrating to... |
+| - | - | - |
+| [Resources for migrating applications to Azure Active Directory (Azure AD)](../manage-apps/migration-resources.md) | List of resources to help you migrate application access and authentication to Azure AD | Solution 1, Solution 2, and Solution 3 |
+| [Azure AD custom claims provider](../develop/custom-claims-provider-overview.md)|This article provides an overview to the Azure AD custom claims provider | Solution 1 |
+| [Custom security attributes documentation](../fundamentals/custom-security-attributes-manage.md) | This article describes how to manage access to custom security attributes | Solution 1 |
+| [Azure AD SSO integration with Cirrus Identity Bridge](../saas-apps/cirrus-identity-bridge-for-azure-ad-tutorial.md) | Tutorial to integrate Cirrus Identity Bridge for Azure AD with Azure AD | Solution 1 |
+| [Cirrus Identity Bridge Overview](https://blog.cirrusidentity.com/documentation/azure-bridge-setup-rev-6.0) | Link to the documentation for the Cirrus Identity Bridge | Solution 1 |
+| [Configuring Shibboleth as SAML Proxy](https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1467056889/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD) | Link to a Shibboleth article that describes how to use the SAML proxying feature to connect Shibboleth IdP to Azure AD | Solution 2 |
+| [Azure MFA deployment considerations](../authentication/howto-mfa-getstarted.md) | Link to guidance for configuring multi-factor authentication (MFA) using Azure AD | Solution 1 and Solution 2 |
+
+## Next steps
+
+See these additional multilateral federation articles:
+
+[Multilateral federation introduction](multilateral-federation-introduction.md)
+
+[Multilateral federation  baseline design](multilateral-federation-baseline.md)
+
+[Multilateral federation solution one - Azure AD with Cirrus Bridge](multilateral-federation-solution-one.md)
+
+[Multilateral federation solution two - Azure AD to Shibboleth as SP Proxy](multilateral-federation-solution-two.md)
+
+[Multilateral federation solution three - Azure AD with ADFS and Shibboleth](multilateral-federation-solution-three.md)

articles/active-directory/fundamentals/media/multilateral-federation-solution-one/azure-ad-cirrus-bridge.png

@@ -0,0 +1,57 @@
+---
+title: University multilateral federation solution design
+description: Learn how to design a multilateral federation solution for universities.
+services: active-directory
+author: janicericketts
+manager: martinco
+ms.service: active-directory
+ms.workload: identity
+ms.subservice: fundamentals
+ms.topic: conceptual
+ms.date: 04/01/2023
+ms.author: jricketts
+ms.custom: "it-pro"
+ms.collection: M365-identity-device-management
+---
+
+# Introduction to multilateral federation solutions
+
+Research universities need to collaborate with one another. To accomplish collaboration, they require multilateral federation to enable authentication and access between universities globally. 
+
+## Challenges with multilateral federation solutions
+
+Universities face many challenges. For example, one university might use one identity management system and a set of protocols while other universities use a  different set of technologies, depending on their requirements. In general, universities can:
+
+* Use different identity management systems
+
+* Use different protocols
+
+* Use customized solutions
+
+* Require support for a long history of legacy functionality
+
+* Need to support solutions that are built in different IT generations
+
+Many universities are also adopting the Microsoft 365 suite of productivity and collaboration tools. These tools rely on Azure Active Directory (Azure AD) for identity management, which enables universities to configure:
+
+* Single sign-on (SSO) across multiple applications
+
+* Modern security controls, including passwordless authentication, MFA, adaptive conditional access, and Identity Protection
+
+* Enhanced reporting and monitoring
+
+Because Azure AD doesn't natively support multilateral federation, this content describes three solutions for federating authentication and access between universities with typical research university architecture. In these scenarios, non-Microsoft products are mentioned for illustrative purposes only and represent the broader class of product. For example, Shibboleth is used as an example of a federation provider.
+
+## Next steps
+
+See these other multilateral federation articles:
+
+[Multilateral federation  baseline design](multilateral-federation-baseline.md)
+
+[Multilateral federation solution one -  Azure AD with Cirrus Bridge](multilateral-federation-solution-one.md)
+
+[Multilateral federation solution two - Azure AD to Shibboleth as SP Proxy](multilateral-federation-solution-two.md)
+
+[Multilateral federation solution three - Azure AD with ADFS and Shibboleth](multilateral-federation-solution-three.md)
+
+[Multilateral federation decision tree](multilateral-federation-decision-tree.md)

articles/active-directory/fundamentals/media/multilateral-federation-solution-three/shibboleth-adfs-azure-ad.png

@@ -0,0 +1,96 @@
+---
+title: University multilateral federation design scenario one
+description: First scenario design considerations for a multilateral federation solution for universities.
+services: active-directory
+author: janicericketts
+manager: martinco
+ms.service: active-directory
+ms.workload: identity
+ms.subservice: fundamentals
+ms.topic: conceptual
+ms.date: 04/1/2023
+ms.author: jricketts
+ms.custom: "it-pro"
+ms.collection: M365-identity-device-management
+---
+
+# Solution 1: Azure AD with Cirrus Bridge
+
+In Solution 1, Azure AD is used as the primary IdP for all applications while a managed service provides multilateral federation. In this example, Cirrus Bridge is the managed service used for integration of CAS and multilateral federation apps.
+
+[![Diagram showing Azure AD integration with various application environments using Cirrus to provide CAS bridge and SAML bridge.](media/multilateral-federation-solution-one/azure-ad-cirrus-bridge.png)](media/multilateral-federation-solution-one/azure-ad-cirrus-bridge.png#lightbox)
+
+If on-premises Active Directory is also being used, then [AD is configured](../hybrid/whatis-hybrid-identity.md) with hybrid identities. Implementing this Azure AD with Cirrus Bridge solution provides:
+
+* **A Security Assertion Markup Language (SAML) bridge** - Enables you to configure multilateral federation and participation in InCommon and EduGAIN. The SAML bridge also enables you to configure Azure AD conditional access policies, app assignment, governance, and other features for each multilateral federation app.
+
+* **CAS bridge** - Enables you to provide protocol translation to support on-premises CAS apps to authenticate with Azure AD. The CAS bridge enables you to configure Azure AD conditional access policies, app assignment, and governance for all CAS apps, as a whole.
+
+Implementing Azure AD with Cirrus bridge enables you to take advantage of more capabilities available in Azure AD:
+
+* **External attribute store support** - [Azure AD custom claims provider](../develop/custom-claims-provider-overview.md) enables you to use an external attribute store (like an external LDAP Directory) to add additional claims into tokens on a per app basis. It uses a custom extension that calls an external REST API to fetch claims from external systems.
+
+* **Custom security attributes** - Provides you with the ability to add custom attributes to objects in the directory and control who can read them. [Custom security attributes](../fundamentals/custom-security-attributes-overview.md) enable you to store more of your attributes directly in Azure AD.
+
+## Advantages
+
+The following are some of the advantages of implementing Azure AD with Cirrus bridge:
+
+* **Seamless cloud authentication for all apps**
+
+  * Elimination of all on-premises identity components can lower your operational effort and potentially reduce security risks.
+
+  * You may realize cost savings resulting from not having to host on-premises infrastructure.
+
+  * This managed solution may help you save on operational administration costs and improve security posture and free up resources for other efforts.
+
+* **Streamlined configuration, deployment, and support model**
+
+  * [Cirrus Bridge](../saas-apps/cirrus-identity-bridge-for-azure-ad-tutorial.md) is registered in the Azure AD app gallery.
+
+  * You benefit from an established process for configuring and setting up the bridge solution.
+
+  * Cirrus Identity provides 24/7 support.
+
+* **Conditional Access (CA) support for multilateral federation apps**
+
+  * You receive support for [National Institutes of Health (NIH)](https://auth.nih.gov/CertAuthV3/forms/help/compliancecheckhelp.html) and Research and Education FEDerations group (REFEDS).
+
+  * This solution is the only architecture that enables you to configure granular Azure AD CA for multilateral federation apps.
+
+  * Granular CA is supported for both multilateral federation apps and CAS apps. Implementation of CA controls enables you to comply with the [NIH](https://auth.nih.gov/CertAuthV3/forms/help/compliancecheckhelp.html) and [REFEDS](https://refeds.org/category/research-and-scholarship) requirements.
+
+* **Enables you to use other Azure AD-related solutions for all apps** (Intune, AADJ devices, etc.)
+
+  * Enables you to use Azure AD Join for device management.
+
+  * Azure AD Join provides you with the ability to use Autopilot, Azure AD Multi-Factor Authentication, passwordless features, and supports achieving a Zero Trust posture.
+
+> [!NOTE]
+> Switching to Azure AD Multi-Factor Authentication may allow you to realize significant cost savings over other solutions you have in place.
+
+## Considerations and trade-offs
+
+The following are some of the trade-offs of using this solution:
+
+* **Limited ability to customize your authentication experience** - This scenario provides a managed solution. Therefore, this solution might not offer you the flexibility or granularity to build a custom solution using federation provider products.
+
+* **Limited third-party MFA integration** - You might be limited by the number of integrations available to third-party MFA solutions.
+
+* **One time integration effort required** - To streamline integration, you need to perform a one-time migration of all student and faculty apps to Azure AD, as well as set up the Cirrus Bridge.
+
+* **Subscription required for Cirrus Bridge** - An annual subscription is required for the Cirrus Bridge. The subscription fee is based on anticipated annual authentication usage of the bridge.
+
+## Next steps
+
+See these other multilateral federation articles:
+
+[Multilateral federation introduction](multilateral-federation-introduction.md)
+
+[Multilateral federation  baseline design](multilateral-federation-baseline.md)
+
+[Multilateral federation solution two - Azure AD to Shibboleth as SP Proxy](multilateral-federation-solution-two.md)
+
+[Multilateral federation solution three - Azure AD with ADFS and Shibboleth](multilateral-federation-solution-three.md)
+
+[Multilateral federation decision tree](multilateral-federation-decision-tree.md)