Traversée du trafic de conférence Web

Dernière rubrique modifiée : 2009-03-10

L'activation de conférences Web auxquelles participent des utilisateurs externes requiert un service Edge d'accès capable de gérer la signalisation SIP nécessaire pour initialiser et mettre fin à une conférence. En outre, un service Edge de conférence Web doit servir de proxy pour le transfert du contenu de réunion tel que les diapositives, le tableau blanc et les questions-réponses entre les utilisateurs internes et externes. Un proxy inverse HTTP est également nécessaire pour le téléchargement des diapositives et le déchiffrement. La séquence d'appel, illustrée à la Figure 1, se présente comme suit :

Figure 1. Séquence d'appel pour la conférence Web avec des utilisateurs externes

1. Un utilisateur externe reçoit un courrier électronique l'invitant à joindre une conférence Web. Le message électronique contient une clé de conférence et un URI de lien vers la conférence. La clé et l'URI sont spécifiques à la réunion.
   L'URL de réunion n'est pas un URI HTTP. Par conséquent, un utilisateur ne peut pas joindre la conférence en copiant et collant l'URI dans un navigateur. Le format de l'URI est le suivant : meet:sip:Organisateur@domaine;ms-app=conf;ms-conf-id=1234. Lorsque l'utilisateur qui a reçu l'invitation clique sur l'URI de la réunion, la console Live Meeting démarre et tente de se connecter au serveur, conformément à la configuration de la console (manuelle ou automatique).
2. L'utilisateur externe lance la procédure qui va lui permettre de joindre la réunion en cliquant sur l'URI de réunion qui figure dans l'invitation électronique. La console Live Meeting démarre et envoie une requête SIP INVITE contenant les informations d'identification de l'utilisateur. Un utilisateur fédéré ou distant se joint à une conférence à l'aide de ses informations d'identification d'entreprise. Dans le cas d'un utilisateur fédéré, la requête SIP INVITE est d'abord envoyée à son serveur central. Ce dernier authentifie l'utilisateur puis achemine la requête INVITE à l'entreprise hébergeant la conférence. Un utilisateur anonyme doit être authentifié à l'aide de la méthode Digest. Pour plus d'informations sur la méthode d'authentification Digest, consultez Authentification pour Office Communications Server 2007 R2.
3. Un directeur ou un serveur frontal authentifie l'utilisateur distant ou anonyme, puis notifie le client. (Comme mentionné à l'étape 2, les utilisateurs fédérés joignant une conférence sont authentifiés par leur entreprise.)
4. Le client envoie une requête INFO pour ajouter l'utilisateur à la conférence Web.
5. Le serveur de conférence Web envoie une réponse add User contenant le jeton à inclure aux informations à présenter au service Edge de conférence Web.
   Notez que tout le trafic SIP antérieur transitait via le service Edge d'accès.
6. Le client se connecte au serveur de conférence Web qui valide le jeton et achemine par proxy la requête contenant un autre jeton d'autorisation vers le serveur de conférence Web interne. Le serveur de conférence Web valide le jeton d'autorisation qu'il avait émis initialement via le canal SIP, pour s'assurer que l'utilisateur qui rejoint la conférence est valide.
7. Le serveur de conférence Web envoie l'URL de diapositive de la réunion à l'utilisateur externe, avec la clé qui lui permettra de déchiffrer la diapositive.
   L'URL de contenu de diapositive est générée de manière aléatoire et elle n'est pas visible à l'utilisateur. Elle ne figure pas dans le courrier électronique initial et elle ne peut pas être détectée sur le client. Par ailleurs, l'exploration des répertoires est interdite sur le serveur de composants Web. La clé associée aux diapositives est différente de la clé de conférence. Elle est spécifique à cette ressource de conférence et à cette réunion. L'utilisateur reçoit cette clé après avoir été authentifié sur le canal SIP uniquement.
8. L'utilisateur externe télécharge les diapositives, puis les déchiffre à l'aide de la clé de diapositive unique fournie.
   Les diapositives et autres ressources de conférence sont chiffrées à l'aide d'AES 128 bits. Avec ce mode de chiffrement, seule la force peut éventuellement permettre de déchiffrer le contenu. Toutefois, compte tenu du nombre très élevé de clés possibles, aucun ordinateur ne parviendra à lancer une attaque en force brute dans le délai très court disponible. Notez que le contenu de la réunion et la clé sont stockés dans le processus uniquement ; ils ne sont pas physiquement enregistrés sur le disque dur de l'utilisateur final.