|
Next revision
|
Previous revision
|
docpublic:systemes:shibboleth:azure365 [2021/07/02 14:18]
adminjp created |
docpublic:systemes:shibboleth:azure365 [2021/07/02 14:52] (current)
adminjp [attribute resolver] |
| * https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies | * https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies |
| |
| ===== Parametrages IDP shibboleth ===== | ===== References IDP shibboleth ===== |
| | |
| nous realisons cette configuration sur un IDP v4.1.2 | |
| |
| references | references |
| {{ :docpublic:systemes:shibboleth:azuread-sso-shibboleth-idp-20180607-2.docx |}} | {{ :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> |
