Azure AD同时作为IdP与SP实现本地SAML应用SSO的可行性及流程问询

Great question! The short answer is yes, you can use Azure AD to act as both the Identity Provider (IdP) and Service Provider (SP) for on-premises SAML-integrated apps to enable Single Sign-On (SSO). Let me break down how this works, including the feasibility and step-by-step authentication flow.

Azure AD is a robust IdP by design, but it also supports configuring SP-like capabilities through its enterprise application registration system. In this scenario, Azure AD doesn’t act as a standalone SP—instead, it acts as the trusted IdP for your on-premises app while handling the SAML protocol interactions that a typical SP would manage. This lets your local app offload most SAML complexity to Azure AD, using it as a single centralized service for both identity verification and protocol handshakes.

Here’s a detailed walkthrough of how the SSO process works when Azure AD handles both IdP and SP roles for your on-premises app:

1. User Initiates Access

   • A user tries to access your on-premises SAML app. The app detects an unauthenticated user and redirects them to Azure AD’s login endpoint (where Azure AD acts as the IdP).

2. Azure AD Authenticates the User

   • Azure AD presents its login interface. The user enters their credentials (username/password, MFA if enabled), and Azure AD validates their identity against its directory.

3. Azure AD Generates & Signs SAML Assertion

   • After successful authentication, Azure AD generates a SAML assertion containing the user’s identity attributes (like email, display name, etc.). Since it’s configured to trust your on-premises app, Azure AD signs and encrypts this assertion (per your SAML settings) and redirects the user back to your app’s assertion consumer endpoint.

4. On-Premises App Validates the Assertion

   • Your local app receives the SAML assertion, uses the pre-shared Azure AD public key to verify the signature and encryption, and confirms the assertion’s validity. Once verified, the app creates a user session and grants access to its resources.

5. SSO for Subsequent Access

   • If the user accesses the same app or another Azure AD-integrated app later, Azure AD leverages the existing SSO session to generate a new assertion automatically—no need for the user to re-enter credentials.

To set this up, you’ll need to complete these core tasks:

• Register your on-premises app in Azure AD: Create an enterprise application (choose "Non-gallery application"), then configure SAML-based SSO. Enter your app’s SP details (assertion consumer URL, entity ID, etc.).
• Import Azure AD’s IdP metadata to your app: Download Azure AD’s IdP metadata file and import it into your on-premises app’s SAML configuration, so the app trusts Azure AD as its IdP.
• Configure attribute mapping: In Azure AD, define which user attributes (e.g., userprincipalname, mail) should be included in the SAML assertion to match your app’s requirements.
• Ensure network connectivity: Make sure your on-premises app can reach Azure AD’s public endpoints (login, metadata) via the internet, VPN, or ExpressRoute.

• While Azure AD handles SP-like protocol interactions, it’s still primarily functioning as the IdP for your app. This setup is ideal if you want to simplify your local app’s SAML implementation by offloading protocol management to Azure AD.
• If your on-premises app is already a fully functional SAML SP, you can skip the "Azure AD as SP" part and just configure it to trust Azure AD as its IdP—this is the more common approach, but the combined role setup works perfectly for scenarios where you want a single centralized service handling all SSO logic.

内容的提问来源于stack exchange，提问作者James