Gérer l’authentification pour le catalogue de données métiers

Article
06/12/2012

Mise à jour : 2009-04-28

Le catalogue de données métiers de Microsoft Office SharePoint Server 2007 prend en charge deux modèles d’authentification et trois modes d’authentification qui utilisent l’authentification unique pour stocker les informations d’authentification utilisateur.

Dans cet article :

Sélectionner un modèle d’authentification et un mode d’authentification spécifiques
Configurer des comptes pour l’application principale
Activer et configurer le service d’authentification unique
Créer et configurer des définitions d’applications d’entreprise
Modifier et importer la définition de l’application
Conditions requises pour les tâches

Pour gérer l’authentification pour le catalogue de données métiers à l’aide de l’authentification unique, vous devez effectuer les étapes indiquées dans ce document pour chaque base de données ou service Web que vous intégrez à votre déploiement.

Sélectionner un modèle d’authentification et un mode d’authentification spécifiques

Les applications dans le catalogue de données métiers peuvent utiliser différents modes d’authentification pouvant faire appel à l’un des deux modèles d’authentification.

Sélectionner un modèle d’authentification

Les modèles d’authentification utilisés par le catalogue de données métiers sont conceptuels et ne correspondent à aucun paramètre de configuration XML ou autre spécifique. Vous implémentez un modèle d’authentification en configurant le fichier XML de définition d’application de manière à utiliser un compte particulier pour la connexion au serveur principal.

Le catalogue de données métiers prend en charge les modèles d’authentification suivants :

sous-système approuvé ;
emprunt d’identité et délégation.

Dans le modèle de type sous-système approuvé, le niveau intermédiaire (généralement le serveur Web) s’authentifie auprès du serveur principal en tant qu’identité fixe. Dans le modèle de type emprunt d’identité et délégation, le client délègue l’authentification au niveau intermédiaire, qui emprunte l’identité du client et s’authentifie pour le compte de ce dernier auprès du serveur principal. Chaque modèle prend en charge plusieurs modes d’authentification utilisables dans différents scénarios d’intégration.

Le modèle de type sous-système approuvé offre les avantages suivants :

Les connexions de base de données sont regroupées.
L’administration est moins complexe.
Les administrateurs du serveur principal pour l’application doivent gérer les autorisations associées à un seul compte.

Le sous-système approuvé convient pour les nouveaux déploiements. Les administrateurs d’applications n’ont pas besoin de configurer des autorisations sur le serveur principal pour un grand nombre d’utilisateurs. Au lieu de cela, ils peuvent configurer un même compte pour chaque application, puis configurer l’autorisation dans Office SharePoint Server.

Le modèle de type sous-système approuvé utilise un compte de service ou un compte de base de données associé à un compte de groupe dans la définition d’application d’entreprise.

Le modèle de type emprunt d’identité et délégation offre les avantages suivants :

audit sur le serveur principal ;
autorisation par utilisateur sur le serveur principal sans configuration supplémentaire.

Le modèle de type emprunt d’identité et délégation convient pour une application existante configurée pour l’autorisation par utilisateur. Un fois le modèle de type emprunt d’identité et délégation configuré, chaque utilisateur continue à être authentifié à l’aide de la configuration définie sur l’application principale. Cette procédure peut s’avérer lourde pour une organisation qui administre plusieurs applications cœur de métier intégrées à un déploiement d’Office SharePoint Server, chacune possédant ses propres paramètres d’autorisation devant être gérés en continu. À moins que l’audit ne soit requis sur le serveur principal, il est souvent recommandé de n’utiliser le modèle de type emprunt d’identité et délégation que lors du déploiement initial jusqu’à ce qu’un modèle de type sous-système approuvé puisse être configuré.

Le modèle de type emprunt d’identité et délégation utilise d’une part un compte d’utilisateur Windows individuel, d’autre part un compte d’utilisateur de base de données (pour les bases de données uniquement) ou un compte d’utilisateur d’authentification basée sur les formulaires (pour les services Web uniquement) associé à un compte individuel.

Sélectionner et configurer un mode d’authentification

Le tableau suivant décrit les modes d’authentification pris en charge par le catalogue de données métiers et indique s’ils utilisent l’authentification unique.

Mode d’authentification	Description	Utilisation de l’authentification unique
PassThrough	Utilise les informations d’identification de l’utilisateur connecté pour effectuer l’authentification auprès de l’application sur le serveur principal. Ce mode est uniquement disponible pour le modèle authentification de type emprunt d’identité et délégation. L’authentification PassThrough nécessite que la délégation Kerberos soit activée.	Non
RevertToSelf	Utilise le compte d’identité du pool d’applications pour authentifier les utilisateurs auprès du serveur principal. Étant donné qu’un compte de service est toujours utilisé à la place d’un compte individuel, le mode RevertToSelf utilise le modèle d’authentification de type sous-système approuvé.	Non
WindowsCredentials	Utilisé pour les bases de données et les services Web. Le catalogue de données métiers emprunte l’identité d’un compte d’utilisateur Windows à l’aide d’informations d’identification provenant d’une définition d’application d’entreprise et effectue l’authentification Windows.	Oui
Credentials	Utilisé pour les services Web qui utilisent l’authentification de base ou Digest à la place de l’authentification Windows. Pour préserver la sécurité, lors de l’utilisation du mode d’authentification Credentials, il est vivement recommandé de sécuriser le canal entre le catalogue de données métiers et le serveur principal à l’aide de SSL (Secure Sockets Layer) ou d’IPSec (Internet Protocol Security).	Oui
RdbCredentials	Utilisée uniquement pour les bases de données principales. Le catalogue de données métiers utilise des informations d’identification d’une définition d’application d’entreprise pour l’authentification.	Oui

La plupart de ces modes utilisent l’authentification unique pour stocker les informations d’identification de l’application, à l’aide d’une identité individuelle ou de groupe configurée en tant que définition d’application d’entreprise. Le mode PassThrough utilise les informations d’identification de l’utilisateur connecté, tandis que le mode RevertToSelf utilise le compte d’identité du pool d’applications pour authentifier les utilisateurs.

Pour tous les modes d’authentification unique, la définition d’application d’entreprise utilise un compte de groupe pour le modèle de type sous-système approuvé et un compte individuel pour le modèle de type emprunt d’identité et délégation. Pour plus d’informations sur la définition d’application d’entreprise, voir la section « Créer et configurer des définitions d’applications d’entreprise » dans ce document.

Le mode d’authentification que vous sélectionnez a une incidence sur les comptes ou les informations d’identification que vous configurez sur votre serveur principal, ainsi que sur les paramètres d’authentification unique. Les propriétés que vous devez configurer pour le fichier XML de définition d’application sont décrits dans la section « Modifier et importer le fichier XML de définition d’application » plus loin dans ce document.

Pour plus d’informations sur les modèles d’authentification et les modes d’authentification, voir Authentification du catalogue de données métiers (https://go.microsoft.com/fwlink/?linkid=100498&clcid=0x40C).

Configurer des comptes pour l’application

Avant de configurer l’authentification unique ou le fichier XML de définition d’application pour l’application, vous devez configurer les permissions d’une ou plusieurs informations d’identification pour le serveur principal :

Si vous utilisez le modèle d’authentification de type sous-système approuvé, vous devez configurer un seul compte ou jeu d’informations d’identification sur l’application.
Si vous utilisez le modèle d’authentification de type emprunt d’identité et délégation, vous devez configurer l’autorisation pour toutes les informations d’identification dont le catalogue de données métiers emprunte l’identité à partir d’un compte de groupe d’authentification unique. Si une application est déjà en cours d’utilisation par votre organisation, les informations d’identification nécessaires peuvent déjà avoir été configurées et vous pouvez ignorer cette étape.

Les comptes sont configurés dans la base de données ou dans le service Web et les détails de la configuration varient selon les autorisations spécifiques de l’application.

Activer et configurer le service d’authentification unique

Si vous avez sélectionné pour le catalogue de données métiers un mode d’authentification qui utilise l’authentification unique, vous devez activer et configurer le service d’authentification unique Microsoft Single Sign-On (SSOSrv) sur tous les serveurs Web frontaux de la batterie de serveurs. Si vous utilisez également la recherche pour le catalogue de données métiers, vous devez activer SSOSrv sur le serveur d’index.

Le compte d’ouverture de session pour le service doit être :

un compte d’utilisateur de domaine, qui ne peut pas être un compte de groupe ;
un compte de batterie de serveurs Office SharePoint Server ;
membre du groupe local Administrateurs sur le serveur de clés de chiffrement (il s’agit du premier serveur sur lequel vous démarrez le service SSOSrv) ;
membre du rôle Administrateurs de la sécurité et du rôle db_creator sur l’ordinateur exécutant Microsoft SQL Server ;
le même compte que le compte d’administrateur d’authentification unique ou membre du compte de groupe qui est le compte d’administrateur d’authentification unique.

Après avoir configuré le service d’authentification unique, vous devez configurer des paramètres supplémentaires sur la page Administration centrale. Les paramètres de serveur pour l’authentification unique comprennent les informations d’un compte d’administrateur d’authentification unique distinct, le nom du serveur de base de données d'authentification unique et le nom du serveur d'authentification unique, ainsi que les paramètres du délai d’attente et du journal d’audit.

L’utilisateur ou le groupe que vous spécifiez comme compte d’administrateur de l’authentification unique doit être :

Soit un compte de groupe global Windows, soit un compte utilisateur individuel. Ce compte ne peut pas être un compte de groupe local de domaine ou une liste de distribution.
Le même compte que le compte du service d’authentification unique, si un utilisateur est spécifié. Si un groupe est spécifié, le compte du service d’authentification unique doit être membre de ce groupe.
Le même compte que le compte de configuration pour l’authentification unique, si un utilisateur est spécifié. Si un groupe est spécifié, le compte de configuration pour l’authentification unique doit être membre de ce groupe.
Membre du groupe SharePoint Administrateurs de batterie.

Pour plus d’informations sur l’activation et la désactivation du service d’authentification unique, voir Configurer et démarrer le service d’authentification unique de Microsoft. Pour plus d’informations sur la configuration du service d’authentification unique, voir Configurer l’authentification unique (Office SharePoint Server).

Créer et configurer des définitions d’applications d’entreprise

Une fois que vous avez configuré le service d’authentification unique, vous devez créer et configurer des définitions d’applications d’entreprise pour vos applications cœur de métier. Vous créez une définition d’application d’entreprise pour chaque information d’identification stockée utilisée par vos applications cœur de métier, bases de données et services Web. En général, vous créez une définition d’application d’entreprise pour chaque application ou service, bien que, si plusieurs applications utilisent le même jeu d’informations d’identification, vous n’ayez besoin que d’une définition d’application d’entreprise permettant d’établir la connexion à toutes les applications qui utilisent ces informations d’identification.

Remarque :
Une définition d’application d’entreprise pour l’authentification unique diffère du fichier XML de définition d’application importé vers le catalogue de données métier pour chaque application ou service. Vous devez créer une définition d’application d’entreprise et y faire référence séparément dans le fichier XML de définition d’application.

Une fois que vous avez créé une définition d’application d’entreprise, vous devez configurer les informations de compte correspondantes. Vous devez être connecté au serveur en tant qu’administrateur local pour effectuer cette procédure.

Pour plus d’informations sur la création de définitions d’applications d’entreprise, voir Créer une définition d'application métier pour le catalogue de données métier. Pour plus d’informations sur la configuration des définitions d’applications d’entreprise, voir Configurer une définition d’application d’entreprise pour le catalogue de données métiers.

Modifier et importer le fichier XML de définition d’application

Après avoir configuré l’authentification unique, puis créé et configuré des définitions d’applications d’entreprise, vous devez modifier la définition d’application afin d’inclure le mode d’authentification pour l’application, l’implémentation pour l’interface ISsoProvider utilisée par l’application et l’ID d’application d’entreprise de l’application. Ces propriétés sont configurées dans l’objet LOBSystemInstance dans le fichier XML de définition d’application.

Vous pouvez également modifier d’autres propriétés de l’application. Pour obtenir un tableau recensant toutes les propriétés disponibles pour la configuration de l’authentification des bases de données et des services Web, voir LOBSystemInstance (https://go.microsoft.com/fwlink/?linkid=124545&clcid=0x40C) . Des exemples sont également fournis.

Avant de pouvoir utiliser les paramètres d’authentification du catalogue de données métiers, vous devez importer dans celui-ci le fichier XML de définition d’application.

Pour plus d’informations sur la création, la modification et l’importation de définitions d’applications pour le catalogue de données métiers, voir Gérer des définition d'applications.

Les tâches de création courantes pour les fichiers XML de définition d’application sont décrites dans les sous-sections suivantes :

Configuration de l’authentification unique pour une base de données
Configuration de l’authentification unique pour un service Web
Configuration du fournisseur d’authentification unique pour l’application
Configuration de l’authentification RevertToSelf
Configuration de l’authentification PassThrough
Configuration de l’authentification de niveau application pour l’application

Configuration de l’authentification unique pour une base de données

Pour utiliser l’authentification unique avec les systèmes de base de données, vous devez recourir aux propriétés suivantes :

La propriété AuthenticationMode de l’objet LOBSystemInstance est définie sur WindowsCredentials ou RdbCredentials.

La propriété SsoProviderImplementation est définie sur le nom pleinement qualifié de l’interface ISsoProvider.

Remarque :
Si une interface ISsoProvider tierce est utilisée au lieu de l’interface ISsoProvider Office SharePoint Server, vous devez inclure le nom pleinement qualifié de ce fournisseur.

La propriété SsoApplicationId est définie sur la valeur de l’ID de l’application d’entreprise pour l’application. Vous avez fourni le nom de la définition d’application d’entreprise lors de sa création.

Configuration de l’authentification unique pour un service Web

Pour utiliser l’authentification unique avec les systèmes de service Web, vous devez recourir aux propriétés suivantes :

La propriété WebServiceAuthenticationMode de l’objet LOBSystemInstance est définie sur WindowsCredentials ou Credentials.

La propriété SsoProviderImplementation est définie sur le nom pleinement qualifié de l’interface ISsoProvider.

Remarque :
Si une interface ISsoProvider tierce est utilisée au lieu de l’interface ISsoProvider Office SharePoint Server, vous devez inclure le nom pleinement qualifié de ce fournisseur.

La propriété WebServiceSsoApplicationId est définie sur la valeur de l’ID de l’application d’entreprise pour l’application.

Configuration du fournisseur d’authentification unique pour l’application

Les applications cœur de métier qui utilisent l’authentification unique pour authentifier les utilisateurs peuvent définir la propriété SsoProviderImplementation et l’interface ISsoProvider de manière à utiliser n’importe quel fournisseur d’authentification unique tiers. Pour utiliser un fournisseur d’authentification unique autre que le fournisseur d’authentification unique Office SharePoint Server, vous devez configurer ce fournisseur, puis inclure son nom complet dans la définition d’application relative à cette propriété. Pour plus d’informations, voir Membres ISsoProvider (en anglais) (https://go.microsoft.com/fwlink/?linkid=124546&clcid=0x40C).

Configuration de l’authentification RevertToSelf pour l’application

Au lieu d’utiliser l’authentification unique, vous pouvez utiliser le mode d’authentification RevertToSelf pour que l’application s’exécute en tant qu’identité de compte du pool d’applications et authentifie les utilisateurs à l’aide des autorisations de chacun d’eux sur l’application. Pour utiliser le mode d’authentification RevertToSelf, définissez la propriété d’authentification comme suit :

Pour effectuer l’authentification auprès d’une base de données, définissez la propriété AuthenticationMode de l’objet LOBSystemInstance sur RevertToSelf.
Pour effectuer l’authentification auprès d’un service Web, définissez la propriété WebServiceAuthenticationMode de l’objet LOBSystemInstance sur RevertToSelf.

Configuration de l’authentification PassThrough pour l’application

L’authentification PassThrough fait également l’impasse sur l’authentification unique pour stocker les comptes ; à la place, elle authentifie chaque utilisateur directement à l’aide des autorisations de chaque compte de l’application principale. Pour utiliser le mode d’authentification PassThrough, définissez la propriété d’authentification comme suit :

Pour effectuer l’authentification auprès d’une base de données, définissez la propriété AuthenticationMode de l’objet LOBSystemInstance sur PassThrough.
Pour effectuer l’authentification auprès d’un service Web, définissez la propriété WebServiceAuthenticationMode de l’objet LOBSystemInstance sur PassThrough.

Configuration de l’authentification de niveau application pour l’application

Le catalogue de données métiers prend également en charge une authentification de niveau application secondaire. Cette authentification est utilisée parallèlement à l’authentification principale configurée pour le système. Elle est particulièrement utile dans les situations où il est nécessaire pour une application principale que les informations d’identification de sécurité soient transmises dans les appels de méthodes à des fins d’autorisation des utilisateurs, par exemple. Pour activer l’authentification de niveau application, procédez comme suit :

Dans la propriété SecondarySsoApplicationId de l’objet LobSystemInstance, spécifiez l’application d’authentification unique qui contient les informations d’identification.
Définissez les propriétés UsernameCredentialFilter et PasswordCredentialFilter, puis associez chacune d’elles à un paramètre d’entrée.

Configuration de l’accès anonyme

Le Service Pack 1 de Microsoft Office Servers 2007 ajoute une nouvelle propriété AllowAnonymousExecute à la définition d'application afin de permettre l'accès anonyme aux données métiers dans les composants WebPart de données métiers. La définition de cette propriété à true autorise l'accès anonyme. La ligne ci-après est la syntaxe XML de la propriété :

<Properties>

<Property Name="AllowAnonymousExecute" Type="System.Boolean">true</Property>

</Properties>

Pour permettre l'accès anonyme aux données d'un composant WebPart Liste de données métiers ou Élément de données métiers, ajoutez cette propriété à l'instance de méthode utilisée par le composant WebPart.

Par exemple, pour permettre aux utilisateurs anonymes d'exécuter l'instance de la méthode ArtistRead d'un composant WebPart Élément de données métiers affichant des informations sur un musicien :

<MethodInstance Type="SpecificFinder" ReturnParameterName="ArtistRead" Name="ArtistRead">