Question

J'utilise les services Web Exchange pour rechercher, créer, mettre à jour et supprimer des rendez-vous des calendriers d'une ou plusieurs personnes. L’application serait utilisée par un responsable pour afficher les vacances de ses employés et attribuer des rendez-vous en fonction des disponibilités.

Pour que tout cela fonctionne, les informations d'identification d'un utilisateur authentifié doivent être envoyées au service Web. Jusqu'ici, les deux méthodes que j'ai trouvées qui permettraient cela sont 1) de transmettre le nom d'utilisateur et le mot de passe de chaque utilisateur et 2) d'emprunter l'identité d'un utilisateur pour utiliser DefaultCredentials. L'option DefaultCredentials ne fonctionne pas pour nous car nous ne permettons pas d'emprunter l'identité des utilisateurs.

Quelqu'un sait-il d'une autre manière?

Était-ce utile?

La solution

Existe-t-il des restrictions de stratégie d'entreprise vous empêchant d'utiliser l'emprunt d'identité? Faites-vous référence à l'emprunt d'identité Windows ou à l'emprunt d'identité Exchange?

En fonction de l'emprunt d'identité que vous ne pouvez pas utiliser, une alternative peut être l'accès délégué.

Si l'objectif est de permettre à un gestionnaire d'afficher plusieurs boîtes aux lettres, voici quelques options:

(1) Accordez au responsable un accès délégué aux boîtes aux lettres de l'employé. Selon le niveau d'accès des délégués, cela permettrait au responsable d'afficher les boîtes aux lettres des employés et de les modifier si nécessaire. Il y a une mise en garde à propos de cette approche, selon le type d'accès accordé, le délégué (employé) peut supprimer l'accès et empêcher le responsable de consulter leurs calendriers.

Pour l'authentification utilisant l'accès délégué, en supposant que l'application utilisant les services Web était exécutée dans le contexte du gestionnaire, vous devriez pouvoir utiliser DefaultCredentials.

(2) Créez un compte de service doté de droits d'emprunt d'identité ou d'un accès délégué aux boîtes aux lettres de l'employé. Puis connectez-vous en tant que compte de service.

De même, voici quelques liens qui pourraient vous être utiles ...

Autres conseils

Si je vous ai bien compris, le responsable utiliserait l'application et s'authentifierait sur le serveur Web personnel en tant que tel. EWS ne pourrait alors pas mettre à jour la boîte aux lettres d'un autre utilisateur en raison d'autorisations insuffisantes.

Pourquoi ne pas donner au responsable un accès à la boîte aux lettres de chaque utilisateur?

(Ou est-ce que je manque une partie substantielle de la question?)

Si l'utilisateur doit être connecté sur son propre ordinateur et que ces informations d'identification sont probablement disponibles dans le cache d'informations d'identification, vous pouvez créer un objet WebCredential à partir de l'objet ICredentials obtenu à partir de cet emplacement:

public static ExchangeService GetService()
{
    var webCredentials = new WebCredentials(CredentialCache.DefaultNetworkCredentials);

    var service = new ExchangeService(ExchangeVersion);
    service.AutodiscoverUrl(Properties.Settings.Default.SmptAccountName);
    service.Credentials = credentials;

    return service;   
}
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top