===== SSO Azure AD 365 =====

Cette page decrit comment configurer un IDP shibboleth (v4.1.2) pour assurer une authentification SSO avec Azure AD

===== Azure AD =====

le SSO avec Azure AD suppose que les comptes de l'AD "on-premise" soient pre-provisionnés sur l'Azure AD "online". Ceci est le role de AzureAD Connect 

  * https://docs.microsoft.com/fr-fr/azure/architecture/reference-architectures/identity/azure-ad
  * https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies

===== References IDP shibboleth =====

references 

  * https://wiki.shibboleth.net/confluence/display/KB/Office+365
  * https://github.com/zckb/azuread-shibboleth-docs/blob/master/azuread-sso-shibboleth-idp-20180607.docx?raw=true

{{ :docpublic:systemes:shibboleth:azuread-sso-shibboleth-idp-20180607-2.docx |}}

===== Parametrages IDP shibboleth =====

nous realisons cette configuration sur un IDP v4.1.2 

==== Matadata MS online ====

il faut charger les metadata de Microsoft online dans notre IDP au moyen du fichier metadata-provider.xml

<code>
     <!-- Microsoft Azure AD Metadata -->
<MetadataProvider id="AAD" xsi:type="FileBackedHTTPMetadataProvider"
             metadataURL="https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml"
             backingFile="%{idp.home}/metadata/AAD-FederationMetadata.xml" />
</code>

==== Configuration du relying party override ====

Azure AD ne gere pas les requetes d'authentification chiffrées, il faut donc declarer une exeption (ovverride) pour cet ServiceProvider / Entity ID de valeur "urn:federation:MicrosoftOnline" afinde lui positionner encryptAssertions="false"

<code>
<util:list id="shibboleth.RelyingPartyOverrides">
  <!-- Microsoft Azure AD -->
        <bean parent="RelyingPartyByName" c:relyingPartyIds="urn:federation:MicrosoftOnline">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO" p:encryptAssertions="false" />
                </list>
            </property>
        </bean>

    </util:list>
</code>



==== attribute resolver =====

il faut que l'IDP envoit au SP MS-online un attribut "pivot" et identifiant unique entre le referentiel local (on-premise) et l'Azure AD.
Pour cela on utilise l'attribut mS-DS-ConsistencyGuid qui est généré dans l'AD on-premise suite a la premiere synchronisation avec Azure AD via l'outil de synchro Azure AD Connect .

 https://docs.microsoft.com/fr-fr/azure/active-directory/hybrid/plan-connect-design-concepts

"//Utiliser ms-DS-ConsistencyGuid en tant qu’attribut sourceAnchor pour les objets utilisateur. ObjectGUID est utilisé pour d’autres types d’objets.//"

On va nommer cet attribut ImmutableID dans les assertion SAML , mais il s'appuiera dans notre attribute-Resolver sur la valeur de mS-DS-ConsistencyGuid qu'il faut s'arrurer de disposer dans le referentiel ldap sur lequel s'appui l'IDP . Si l'IDP interroge directement un AD c'estdirectement disponible, autrement i lfaut le repliquer dans LDAP . C'est l'object de la tache LSC (synchro AD -> Ldap )  qui suit .

Ensuite un identifiant plus lisible / userfirandly est utilisé pour l'affichage du nom de compte passé sur l'UPN (format mail) via l'attribut SAML UserId.

Notre synchro AD -> LDAP reproduit la valeur de AD mS-DS-ConsistencyGuid dans l'attribut SupannRefId avec l'etiquette {AZUREADMDSGUIDB64}

il faut donc dans l'attribute resolver (attribute-resolver-ldap.xml) definir un npouvel attribut id="ImmutableID" de type "Mapped" qui va chercher grace a une Regexp la valeur($1) base64 du supannRefID etiquette {AZUREADMDSGUIDB64}

<code>
    <AttributeDefinition id="ImmutableID" xsi:type="Mapped">
            <InputDataConnector ref="myLDAP" attributeNames="supannRefId" />
            <DefaultValue passThru="false"/>
    <ValueMap>
        <ReturnValue>$1</ReturnValue>
        <SourceValue>\{AZUREADMDSGUIDB64\}(.+)</SourceValue>
    </ValueMap>
 </AttributeDefinition>

 <AttributeDefinition xsi:type="Simple" id="UserId" >
        <InputDataConnector ref="myLDAP" attributeNames="mail"/>
    </AttributeDefinition>

</code>

on a aussi definit le 2eme attribut qui est une simple reprise de attributeNames="mail" depuis LDAP

il faut evidement recuperer ces attributs (mail et supannRefId) depuis le dataConnector "myldap" 

<code>
  <DataConnector id="myLDAP" xsi:type="LDAPDirectory"
        ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
        baseDN="%{idp.attribute.resolver.LDAP.baseDN}" 
        principal="%{idp.attribute.resolver.LDAP.bindDN}"
        principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
        useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}"
        connectTimeout="%{idp.attribute.resolver.LDAP.connectTimeout}"
        trustFile="%{idp.attribute.resolver.LDAP.trustCertificates}"
        responseTimeout="%{idp.attribute.resolver.LDAP.responseTimeout}"
        connectionStrategy="%{idp.attribute.resolver.LDAP.connectionStrategy}"
        noResultIsError="true"
        multipleResultsIsError="true"
        excludeResolutionPhases="c14n/attribute"
        exportAttributes="mail displayName cn sn givenName departmentNumber employeeNumber uid eduPersonAffiliation supannRefId ">
        <FilterTemplate>
            <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
        </FilterTemplate>
</code>


==== aacli resolver ====

on peux tester la resolution d'attribut vers le SP MSOnline avec le script aacli.sh 

<code>
[root@idpx shibboleth-idp]# ./bin/aacli.sh --requester=urn:federation:MicrosoftOnline --configDir=conf/ --principal=testuser
 {
    "name": "mail",
    "values": [
        "user.test@domain.fr"
    ]
  },
  

  {
    "name": "cn",
    "values": [
        "TEST User"
    ]
  },
  

  {
    "name": "ImmutableID",
    "values": [
        "m20WX2efJUarbMor/iewhQ=="
    ]
  },

</code>