Overview 

The Shibboleth IdP can be a proxy to EntraID leveraging its features while keeping in alignment to R&E federation's multi-lateral trust model. The steps can be applied to any V5+ base install and are platform neutral. When done the IdP will be capable of being a full pass-through proxy with Attributes originating from EntraID as well as the ability to take advantage of MFA and REFEDS-MFA authentication contexts.

...

Acknowledgements: Thanks to contributors  from JISC, other US higher ed institutions, the Shibboleth team, and others for guidance and input on the material.

IdP Proxying Concepts: Appearances and Perspectives

Proxying techniques are confusing at times and helpful to understand the perspectives:

...

• The entity registered in the R&E federation is the Shibboleth IdP, built for and by the R&E community and should meet all technical requirements as does any other Shibboleth IdP
• Alignment to any federation baseline expectations is not just software but also how it's operated and managed and is in the hands of the IdP operator like any other IdP. 

IdP Proxying Concepts: What a Proxy Flow Looks Like

When the user initiates sign-on the following usually happens:

• 1. An Authentication request arrives at Shibboleth IdP

  2. The Shibboleth IdP observes it's configured for SAML sign on and redirects to an upstream IdP (EntraID). Settings for this are controlled in

     1. idp.properties
     2. authn/authn.properties
  3. User Authenticates or has an existing session at upstream IdP (EntraID)
  4. The upstream IdP (EntraID) constructs a SAML Assertion with one or more attributes and is sent with the user to the Shibboleth IdP 
  5. The Shibboleth IdP receives the assertion and:

     1. verifies that the assertion arrives from an entity it trusts as configured in metadata-providers.xml

     2. filters the assertion according to rules in attribute-filter.xml
     3. Extracts the real user as configured in attribute-based subject c14n.
        1. Looks through list of AttributesToResolve in the resolver, resolves each one.
        2. Applies a idp admin configured regular expression  to the EntraID name claim
     4. Resulting trusted real username is used as $resolutionContext.principal (eg. existing LDAP data connector, etc.) during "standard" attribute resolution process

Implementing the Solution

Prerequisites

Be sure to have these assets in place and appropriate access to them before you start:

1. A working Shibboleth Identity Provider at V5 or above running somewhere.
2. An active EntraID tenant that you have administrative control in
3. The ability in EntraID to create an enterprise Non-Gallery SAML App
4. A suitable attribute available to both IdPs to use as a "joining" attribute used in local lookups if necessary.

Terms and Settings 

This document refers to some key settings and terms described here. For your installation have these on hand to speed up configuration:

• Your original IdP EntityID: https://idp.example.com/idp
• Your Upstream IdP EntityID which is EntraID Identifier: https://sts.windows.net/<sts_tenant_id>/ (Finding your tenantID)
• The Proxy Joining attribute common to both services:
  • SamAccountName is often a good choice and appears as 'name' in claims.
    • will exist as a 'scoped' username
    • the scope being that of the domain used on-premises and is usually internet friendly (not something.local or something.int)
• Relying Party/Service Provider Microsoft will use "Relying Party" at times to mean "Service Provider"

Steps and Tasks

Step 1. Configuring Trust Between EntraID and the Shibboleth IdP

There are 3 main trust-related configurations to adjust:

...

3. the EntraID trust to the Shibboleth IdP as a Relying Party

Trust Task: 1. Update your IdP's metadata

As your IdP will need act as an SP, you'll need extra blocks in your entity's metadata.

...

<EntityDescriptor entityID="https://idp.example.com/idp" ...>

    <!-- Already present IdP data -->
    <IDPSSODescriptor ...>
        ...
    </IDPSSODescriptor>

    <AttributeAuthorityDescriptor>
        ...
    </AttributeAuthorityDescriptor>


    <!-- New SP block -->
    <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

        <KeyDescriptor use="signing">
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                    ...Signing Certificate from IdP...
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <KeyDescriptor use="encryption">
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                    ...Encryption Certificate from IdP...
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>

    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.example.com/idp/profile/Authn/SAML2/POST/SSO" index="0"/>
</SPSSODescriptor>

</EntityDescriptor>

Trust Task: 2. Register your IdP with EntraID

An EntraID Enterprise Application needs to be created of type 'Non-Gallery Application' and configured for SAML.

...

Keep this Relying Party editing environment open for the next step.

Trust Task: 3. Register the upstream IdP's metadata locally

Your Shibboleth IdP doesn't know of the EntraID IdP so you need to register it locally. This is handled just like any other metadata and can be included in your metadata-providers.xml as a new <MetadataProvider> element. For example:

...

Trust Task: 4. Configure EntraID Attribute Release to the Shibboleth IdP

While still in the edit mode of the Relying Party, configure the necessary attributes needed for the Shibboleth IdP operation.

• For a pass-through proxy approach
  • All attributes originate from EntraID and must be released to this Relying Party for the Shibboleth IdP to marshall downstream
• For a hybrid proxy approach
  • Technically the single attribute you want to use for user lookup is required.

Step 2. Configure the IdP for Proxing Behaviour

The following changes are needed to adjust the IdP to proxying behaviour:

1. Changing the authentication flow to SAML authentication
2. Configuring which Entity to delegate to for the flow
3. Update attribute filter to allow incoming attributes to be ingested
4. Set up attribute extraction through Subject Canonicalisation (c14n and resolver)

Proxy Task 1. Change the IdP authentication flow to SAML

There are three steps for this task that embody some of the existing Authentication Configuration and  SAMLAuthnConfiguration guidance:

...

     idp.authn.SAML.proxyEntityID = https://sts.windows.net/00BC123-TENANTID-INCLUDING-TRAILING-SLASH/

Proxy Task 2. Update Your Attribute Filter

The IdP will not ingest attributes from the EntraID Upstream IdP unless they're allowed in by a filter.

...

<AttributeFilterPolicy id="FilterPolicyObject-Proxy-FromAzure-byIssuer-Type">
    <PolicyRequirementRule xsi:type="Issuer" value="https://sts.windows.net/00BC123-TENANTID-INCLUDING-TRAILING-SLASH/" />
         
    <AttributeRule attributeID="azureDisplayname" permitAny="true" />
    <AttributeRule attributeID="azureGivenname" permitAny="true" />
    <AttributeRule attributeID="azureSurname" permitAny="true" />
    <AttributeRule attributeID="azureAuthnmethodsreferences" permitAny="true" />
    <AttributeRule attributeID="azureIdentityprovider" permitAny="true" />
    <AttributeRule attributeID="azureTenantid" permitAny="true" />
    <AttributeRule attributeID="azureEmailaddress" permitAny="true" />
    <AttributeRule attributeID="azureObjectidentifier" permitAny="true" />
    <AttributeRule attributeID="azureName">
        <PermitValueRule xsi:type="ScopeMatchesShibMDScope" />
    </AttributeRule>
</AttributeFilterPolicy>

Proxy Task 3. Enable IdP to Recognize EntraID Claims 

EntraID issues SAML assertions, however they are presented in an Azure/WS-Fed-centric naming convention (as "claims").

...

Now that we have the the IdP able to interpret claims from EntraID, we need to turn our attention to using them for user canonicalization and for populating our attributes.

Proxy Task 4. Subject Canonicalisation

Much simplified, this step extracts the canonical (authoritative/normalized) username during a SAML proxying flow, and uses the subject-c14n.properties and subject-c14n.xml to guide the IdP on what to do.

...

At this point you should have a valid, locally understood username to pass into the "normal" resolver that already works, usually available as: $resolutionContext.principal

Proxy Task 5. Configuring Attribute pass-through and/or hybrid resolving

Attributes originating from EntraID are referenced in attribute-resolver.xml through a  SubjectDataConnector  and then referencing them in the AttributeDefinition

...

	<AttributeDefinition xsi:type="Simple" id="userPrincipalName">
        <InputDataConnector ref="passthroughAttributes" attributeNames="azureName" />
    </AttributeDefinition>


	<AttributeDefinition xsi:type="Simple" id="sn">
        <InputDataConnector ref="passthroughAttributes" attributeNames="azureSurname" />
    </AttributeDefinition>
	
<AttributeDefinition xsi:type="Simple" id="givenName">
        <InputDataConnector ref="passthroughAttributes" attributeNames="azureGivenname" />
    </AttributeDefinition>

<AttributeDefinition xsi:type="Simple" id="mail">
        <InputDataConnector ref="passthroughAttributes" attributeNames="azureEmailaddress" />
    </AttributeDefinition>

<AttributeDefinition xsi:type="Simple" id="displayName">
        <InputDataConnector ref="passthroughAttributes" attributeNames="azureDisplayname" />
    </AttributeDefinition>

<AttributeDefinition xsi:type="Simple" id="cn">
        <InputDataConnector ref="passthroughAttributes" attributeNames="azureDisplayname" />
    </AttributeDefinition>

<DataConnector id="passthroughAttributes" xsi:type="Subject"
   exportAttributes="azureName azureEmailaddress azureDisplayname azureGivenname azureSurname azureTenantid azureObjectidentifier azureIdentityprovider azureAuthnmethodsreferences" />

Proxy Task 6. Handling REFEDS AuthnContext Requests (optional)

Supporting the REFEDS-MFA AuthenticationContext can be handled by instructing the Shibboleth IdP to transform inbound and outbound SAML2 Authentication Contexts during the proxying process.

...

idp.authn.SAML.supportedPrincipals = \
    saml2/https://refeds.org/profile/mfa, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:Password, \
    saml1/urn:oasis:names:tc:SAML:1.0:am:password

Testing

Restart your IdP for your changes before testing.

...