Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reverted from v. 4
  1. Configure your IdP to load the Azure metadata. Further information on loading metadata can be found here.

  2. Configure your IdP to respond to ECP profile requests.  More information can be found here

  3. Add relying party specific configuration.  Azure requires that encryption be turned off and that only assertions be signed.  It will also be necessary to set a name identifier precedence so that the ECP endpoint responds with a format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent".  The following bean definition can be used verbatim in your configuration.

     

    Code Block
    languagexml
    titleExcerpt: relying-party.xml
            <bean parent="RelyingPartyByName" c:relyingPartyIds="urn:federation:MicrosoftOnline">
                <property name="profileConfigurations">
                    <list>
                        <bean parent="SAML2.SSO" p:encryptAssertions="false" p:signAssertions="true" p:signResponses="false" />
                        <bean parent="SAML2.ECP" p:encryptAssertions="false" p:signAssertions="true" p:signResponses="false" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
                    </list>
                </property>
            </bean>
  4.  

    Configure the necessary attribute definitions and filter policy.  Only one SAML attribute, entitled "IDPEmail," should be sent.  Another attribute definition is typically required in order to send the Azure ImmutableID in the SAML Subject.  The ImmutableID attribute is site dependent, but most frequently maps to the "objectGuid" in Active Directory.  The following configuration examples are for reference only and must be modified as appropriate to your environment.

     

    Code Block
    languagexml
    titleExcerpt: attribute-resolver.xml
      <!-- Needed Office365 Integration. Used for NameID value. (No encoder necessary) -->
      <resolver:AttributeDefinition id="uMemphisAdObjectGuid" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="uMemphisAdObjectGuid">
        <resolver:Dependency ref="directory" />
      </resolver:AttributeDefinition>
    
      <!-- UserPrincipalName for Office365. -->
      <resolver:AttributeDefinition id="UserId" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="testssotenant.memphis.edu"  sourceAttributeID="uid">
          <resolver:Dependency ref="directory" />
          <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="IDPEmail" />
      </resolver:AttributeDefinition>
    Code Block
    languagexml
    titleExcerpt: attribute-filter.xml
      <afp:AttributeFilterPolicy id="azureAD">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline"/>
        <afp:AttributeRule attributeID="UserId">
          <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="uMemphisAdObjectGuid">
          <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
      </afp:AttributeFilterPolicy>
  5. Since Azure requires use of a proprietary identifier in conjunction with the standard NameID format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent," you will need to create activation conditions to send that value to Azure only. The following configuration example is for reference purposes and must be modified as appropriate to your environment.

...