Kim Cameron nous présente une session d’introduction à la gestion d’identité, commençant par un rappel : chaque communication entre deux entités commence par

Qui es-tu ?

La discussion file vers la façon la plus naturelle de régler le problème : une base login/password. Il continue en passant sur Active Directory, puis OTP pour des accès externes, puis des audits de sécurité, puis … Bref.

Ensuite, il prend une comparaison avec la gestion des entrées/sorties en montrant qu’un flux d’octets est le bon niveau d’abstraction, et complète son analogie en introduisant la notion de Claims pour porter une information d’identité.

Il développe  les grandes notions de façon un peu désordonnée : le besoin d’adoption du système par les utilisateurs, le besoin de définir des standards, le besoin de transformer d’un mode de représentation à un autre.. Bref, il nous faut un méta-système pour englober les spécificités de chaque système et permettre l’unification des formats, transports et responsabilités.

D’où :  Geneva, un framework simplifiant l’implémentation de tout ça

Qui es-tu ?

insertion dans le App.Config d’une directive

<federatedAuthentication enabled=”true”>

  wsFederation issuer =”” realm=”” passiveRedirectenabled=”true”

<federatedAuthentication >

Que peux-tu faire ?

IclaimsIdentity caller = Thread.CurrentPtincpal.Identity as IClaimsIdentity

string role = (from c in caller.claims where c.ClaimType = myClaimstype.Roles

select c.Vaue).Single

Geneva en détail :

Le FW

pour créer des applis orientées claims

Le Serveur Geneva

Un STS intégré à AD

Supporte Cardspace

 

Windows Cardspace Geneva

Client de fédération (un nouveau client Cardspace)

Ensuite, on va regarder ce qui se passe côté client : l’autre entreprise, l’autre utilisateur.

Les arguments sont : le FW supporte WS-Federation, WS-Trust, SAML 2.0, et peut donc fonctionner avec toute offre logicielle reposant sur l’un de ces standards.

DogFooding ?

Nous (MS) utilisons la même architecture en interne, et chaque application chez nous devient accessible via la Microsoft Federation Gateway, conforme à Ws-Fed et WS-trust

Live-ID ?

Conforme au sens où nous savons l’intégrer dans le système de fédération.

Nous lançons Mic’osoft Services Connector qui connecte AD à Mictrosoft Federation Gateway, download gratuit, pour les clients qui ont besoin d’un accès à la Gateway et pas plus, c’est bien sûr compatible avec Cardspace.

Faut-il impérativement reposer sur une ressource type Cloud, la Federation Gateway, pour tourner ? On peut tout à fait travailler en deux couches : un Geneva Server en local, qui sera capable daccepter des communications en provenance de la Gateway si nécessaire.

Encore du neuf : .Net access control service : c’est un service (un STS) qui prend des claims d’authentification et renvoie des claims d’autoirisation (en gros, on lui donne des règles et des rôles, et à partir de l’identité il renvoie les rôles auxquels appartient l’utilisateur). Ce service n’a rien de compliqué à écrire, c’est un peu l’AzMan du monde de lidentité fédérée

Après ces 30 minutes assez intenses (un vrai déluge d’annonces), Kim passe la parole à Vittorio Bertocci pour une série de démos. Je ne vais sans doute pas les reprendre dans ce compte-rendu, mais voilà quand même mes notes

--

La méga-démo reprend tous les éléments. Les forces en présence : une entreprise classique (ADatum), un éditeur qui fait du SaaS, et le Microsoft Services Identity Backbone avec tous les blocs derrière

La démo commence avec un empoloyé d’Adtum (l’entreprise) qui se loggue sur sa bécane et file sur une application CRM Online. La partie surprenante : on a eu un SSO entre adatum (le client initial) et l’application hostée par Microsoft

Traduction : l’appli hostée chez MS a eu besoin d’un token, ce token a été délivré par la Microsoft Federation Gateway qui est en fédération avec lo’AD de ADatum.

Il continue en disant “très bien, on sait le faire chez MS, et si vous voulez être l’hébergeur ?” En d’autres termes, pouvons-nous dynamiquement assirer la fédération ? Il montre que ça fonctionne, et présente dans les pages de l’application SaaS des données qui viennent de l’yutilisateur et expliquèe que ces données ont été trannsmises dynamiquement

Il lance un Geneva Server (enfin, la MMC associée) et montrre qu’on peut administrer des relying parties : à qui puis-je délivrer des tokens. La MMC permet de définir des claims s’appuyant sur l’Active Directory.

On file ensuite sur Fabrikam pour voir comment ils consomment les claims émises par le serveur Geneva

Il part d’une appli ASP.Net classique (au passage : Zermatt est dans Geneva maintenant).

Il montre qu’il accepte les caims de adatumcorporation, et qu’on fait ensuite des requêtes LINQ sur les claims

firstname = from c in claims …

Fin du scénario : à la fin de la journée, l’employé rentre chez lui. Il ouvre son portable, retourne sur son applicatyion, mais ce coup-ci il n’y a pas de sso actif puisque son AD n’est pas là. Donc on lui propose de s’identifier (Geneva et le connector ont des pages type pour ça, qui proposent CardSpace et un autre que j’ai pas vu)

Il montre le nouveau Cardspace : interfae très lég_re, qui lui demande de fournir es credentials de domaine, et hop ça passe

le cheminement : de chez moi je file vers l’AD de mon entreprise, qui me délivre un jeton consommable par l’appli SaaS

Il termine en montrant une modification : refusée, il n’est pas manager. Mais ici on montre qu’on peut rendre magique ce déblocage d’accès : il utilise .Net Access Control Service

Il montre une appli qui utilise les APIS de gestion d’Azure et montre de façon graphique les règles qui présiednt à la transformation des claims donnant les claims d’autorisation

La fin : comment raccordement à LiveId, puis interop avec Tivoli d’IBM, avec le protocole SAML 2

11h56 : passe la parole à Kim

Oh : LiveId est maintenant BootStrappé sur OpenId (j’ai pas plus d’infos pour le moment, pas de lien )

Donc pour vos sites et applis : soit Live Framework (LiveId-based?), soit Framework Geneva, soit OpenId

Geneva Server :

Genevca RTM H2 CY09

13h45 : Geneva server Overview

3h30 : cpo,ecting AD to %ocrosoft Services

J’ai réinstallé récemment ma machine sous Windows Server 2008, pour profiter un peu d’Hyper-V notamment, et j’ai découvert à  mon grand dam qu’hyper-V est incompatible avec la mise en veille.  Moi qui redémarre ma machine une à deux fois par trimestre, c’est un peu dur.

Bref, après des recherches un peu longues, j’ai trouvé un contournement simple : ne pas lancer hyper-V tant que je n’en ai pas besoin. Ca se fait à coup de base de registre :

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hvboot]

Là-dedans, passez Start à 3 au lieu de 1, et vous récupérez la mise en veille de votre belle machine.

Lorsque vous avez besoin d’Hyper-V, un petit command prompt et  net start hvboot réactive Hyper-V. Ensuite il faudra arrêter le portable au lieu de le mettre en veille, mais du coup je peux descendre à 4 reboots par semaine, beaucoup plus agréable que 20..

Pour les maniaques du clavier, j’ai aussi remappé les touches qui entourent les flèches de direction. Par défaut elles font Précédent/Suivant dans IE, je préfère PageUp et PageDown. Pour ça, copiez ceci dans un fichier .reg :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,69,00,51,00,6A,00,49,00,\
  00,00,00,00

Puis double-cliquez dessus et rebootez.

Pour les curieux, voilà ce que ça dit : les données hexa se lisent par paquets de 4. Les deux  premiers sont décoratifs (lire : réservés pour usage ultérieur), le 3e indique le nombre de touches à remapper, les trois  suivants sont les scancodes de la touche à remplacer et de la touche qui la remplace, le dernier remplace rien par rien, c’est comme ça qu’on indique qu’on a terminé le remappage.

Que se passe-t-il lorsque le temps de traitement sur un serveur dépasse le rythme d'envoi par les clients ? Si le rythme moyen dépasse la capacité de traitement, il faut un plus gros serveur, mais 9 fois sur 10 c'est le rythme en pic qui pose problème. Microsoft fournit une solution depuis NT4 : Message Queue Server (ou MSMQ), un serveur de messagerie applicative.

Si MSMQ est installé sur votre serveur, et que la communication entre les clients et le serveur est faite en WCF, vous pouvez très simplement vous appuyer sur MSMQ pour absorber les pics de charge.

Pour fixer les idées, imaginez le problème suivant : Votre serveur permet d'envoyer des SMS, mais il est limité à un message/seconde. Vos clients envoient le matin des vagues de SMS. Qu'un SMS mette 15 minutes à parvenir à destination n'est pas dramatique, mais il est impératif que chaque SMS soit transmis à son destinataire.

En termes techniques, le serveur expose le contrat de service suivant :

[ServiceContract]
interface ICommunicationsDiverses
{ [OperationContract (IsOneWay=true) ] void EnvoieSMS(string numero, string sms);
} 

Puisque nous allons stocker les demandes d'exécution en file d'attente, l'opération d'envoi de SMS ne peut pas renvoyer directement de message, il faut donc une signature void dans l'implémentation et un attribut IsOneWay dans le contrat.

La communication met maintenant en jeu trois acteurs : les clients, le serveur, et la file d'attente qui s'intercale entre les deux. Cette dernière doit être déclarée sur le poste serveur.

La suite est un simple travail de configuration, consistant à préciser aux clients et au serveur qu'ils doivent passer par la file d'attente pour se passer les messages :

          <?
          xml
          version
          ="1.0"
          encoding
          ="utf-8" ?><configuration><system.serviceModel><bindings><netMsmqBinding><bindingname="monBindingMSMQ"><securitymode="None"><transportmsmqAuthenticationMode="None"msmqProtectionLevel="None"/><messageclientCredentialType="None"/></security></binding></netMsmqBinding></bindings><client><endpointname="nomDuEndPoint"address="net.msmq://localhost/Private/MaFile"binding="netMsmqBinding"contract="ICommunicationsDiverses"bindingConfiguration="monBindingMSMQ"></endpoint></client></system.serviceModel></configuration>

<?xmlversion="1.0"encoding="utf-8" ?><configuration><system.serviceModel><bindings><netMsmqBinding><bindingname="monBindingMSMQ"><securitymode="None"><transportmsmqAuthenticationMode="None"msmqProtectionLevel="None"/><messageclientCredentialType="None"/></security></binding></netMsmqBinding></bindings><services><servicename="MonAppliSuperCompliquee.ClasseImplementantLInterface"><endpointaddress="net.msmq://localhost/Private/MaFile"binding="netMsmqBinding"bindingConfiguration="monBindingMSMQ"name="nomEndPointServeur"contract="ICommunicationsDiverses"/></service></services></system.serviceModel></configuration>

C'est tout. A partir de maintenant, les appels fonctionneront même si le serveur est arrêté, puisqu'ils sont stockés dans la file d'attente, et le serveur les traitera un à un quel que soit le nombre d'appels en attente.

J'ai récupéré ce matin le code source de SharpSTS (un toolkit pour cardspace), et il m'a fallu quelques recherches pour réussir à récupérer le code source depuis CodePlex, voilà le résultat de mes pérégrinations.

1/ Installez un client SubVersion

Récupérez un client subversion. TortoiseSVN est simple d'emploi, maintenu, et en plus il a des icônes rigolotes.

http://tortoisesvn.net/

2/ Installez et lancez SvnBridge

CodePlex fonctionne en réalité sous Team Foundation Server, vous allez donc installer sur votre machine un petit proxy SVN <=> TFS

http://www.codeplex.com/SvnBridge/

Le port est ce que vous voulez de disponible sur votre machine, l'adresse du serveur TFS est indiquée sur la page du projet CodePlex qui vous intéresse :

3/ Récupérez le code source

Faites-vous un répertoire là où vous voulez une copie des sources, un clic droit, et c'est tout :

4/ Et pour les commits ?

Il vous faudra un compte avec les droits de mise à jour sur le projet. Attention, le compte n'est pas directement votre login CodePlex : c'est snd\votreusername_cp

Comme annoncé, voici quelques notes et réflexions sur l'implémentation de CardSpace sans SSL

Pour quelles utilisations ?

Lorsque vous allez sur un site Web utilisant Cardspace, il vous demande de choisir une carte. Lorsque vous avez fait ce choix, un ensemble d'informations est transmis au site Web (sous la forme d'un document XML). Si vous utilisez CardSpace sans SSL, ces données transitent en clair entre le client et le serveur, et l'identité du serveur n'est pas vérifiable. Pour ces raisons, vous ne pourrez échanger que des cartes auto-proclamées, qui comportent un sous-ensemble des informations suivantes :

• Identifiant unique sur le site concerné
• Prénom
• Nom
• Email
• Adresse (rue)
• Adresse (Ville)
• Adresse (Département/province)
• Code Postal
• Pays/Région
• Téléphone
• Téléphone 2
• Téléphone mobile
• Date de naissance
• Sexe

En d'autres termes, vous pouvez pré-remplir une fiche utilisateur avec ces informations, et reposer sur l'identifiant unique en remplacement d'un login/mot de passe. Ces informations sont relativement peu sensibles et ne serviront pas à grand-chose si elles sont interceptées pendant la communication avec le serveur.

En résumé : l'utilisation de CardSpace sans SSL est adaptée au login sur un site Web ne manipulant pas d'informations sensibles sur votre compte.

Que se passe-t-il lorsque j'utilise une carte personnelle sur un site Web ?

Au lieu d'utiliser une demande de login / mot de passe, le site Web vous demande d'envoyer les informations vous concernant.

Dans un premier temps, le site web vous demande de sélectionner une carte vous représentant, et vous indique quelles sont les données qu'il va demander :

Dans cet exemple, le site a juste besoin de mon prénom (pour personnaliser les pages) et de mon identifiant sur le site (pour remplacer un login et un mot de passe).

Lorsque vous envoyez les données demandées, voici ce qui est transmis au site Web :

Les données transmises sont manifestement très simples à décoder, puisqu'une requête XPath donne directement accès aux informations voulues :

          Public
          Function RecupereAttribut(ByVal jeton AsString, ByVal claimName AsString) AsStringDim x AsNew System.Xml.XmlDocument()
x.LoadXml(jeton) Dim xns AsNew XmlNamespaceManager(x.NameTable)
xns.AddNamespace("saml", "urn:oasis:names:tc:SAML:1.0:assertion") Dim xn As System.Xml.XmlNode
xn = x.SelectSingleNode("/saml:Assertion/saml:AttributeStatement/saml:Attribute[@AttributeName='" &
claimName & "']", xns) Return xn.InnerText End Function

Il y cependant quelques précautions à prendre pour garantir que personne ne pourra  se faire passer pour un de vos utilisateurs.

Que doit faire un site Web quand vous lui envoyez vos informations ?

La première chose à faire est de vérifier que le XML envoyé n'a pas été modifié par un utilisateur malveillant. Comme le document XML contient une balise <Signature>, il suffit de vérifier que la signature correspond bien au document transmis. Voici comment faire en VB.Net :

          Public
          Function JetonValide(ByVal token AsString) AsBoolean'
charger le jetonDim x AsNew XmlDocument()
x.LoadXml(token) Dim s AsNew SamlSignedXml(x) '
renseigner les namespacesDim xns AsNew XmlNamespaceManager(x.NameTable)
xns.AddNamespace("sig", "http://www.w3.org/2000/09/xmldsig#") 'vérifier
la signature s.LoadXml(x.SelectSingleNode("//sig:Signature",
xns)) Return s.CheckSignature EndFunction

Ce code repose sur une classe SamlSignedXml qui est *presque* fournie par le Framework .Net (voir code source joint à la fin de cet article). Si vous n'êtes pas en .Net sur votre serveur Web il vous suffit de trouver un bout de code vérifiant une signature XML.

Une fois que vous êtes certain que le document XML n'a pas été modifié avant d'arriver sur le serveur, vous allez en extraire l'identifiant utilisateur qui remplace le login / mot de passe. Cet identifiant est en fait composé de deux parties : d'une part l'information PrivatePersonalIdentifier transmise dans le document XML, et l'information Modulus qui garantit que l'information vient bien du bon utilisateur. Pour ne pas avoir à stocker deux informations distinctes, le plus simple est de les combiner et d'en faire votre identifiant utilisateur :

          Public
          Function IDUtilisateur(ByVal jeton AsString) AsString'
Récupération du PPIDDim PPID AsString =
RecupereAttribut(jeton, "privatepersonalidentifier") '
Récupération de la cléDim x AsNew XmlDocument()
x.LoadXml(jeton) Dim xns AsNew XmlNamespaceManager(x.NameTable)
xns.AddNamespace("sig", "http://www.w3.org/2000/09/xmldsig#") Dim ClePublique AsString =
x.SelectSingleNode("//sig:Modulus", xns).InnerText 'Combinaison
des deux données en une seuleDim hacheur As SHA1
= SHA1.Create("SHA1") Dim OctetsPPID() AsByte =
Convert.FromBase64String(PPID) Dim OctetsCle() AsByte =
Convert.FromBase64String(ClePublique) Dim OctetsAHacher(OctetsPPID.Length
+ OctetsCle.Length) AsByte OctetsPPID.CopyTo(OctetsAHacher,
0) OctetsCle.CopyTo(OctetsAHacher, OctetsPPID.Length) 'Transformation
en chaine de caractèresReturn Convert.ToBase64String(hacheur.ComputeHash(OctetsAHacher)) EndFunction

Et pour les plus flemmards...

Vous trouverez dans CardSpaceSansSSL.Zip 4 fichiers :

PageNormale.html et ic_image.jpg : l'image et l'exemple de code HTML nécessaires pour utiliser Cardspace sur n'importe quel site.

decodejeton.aspx et decodejeton.aspx.vb : une page de test qui affiche les informations transmises après avoir vérifié leur validité.

Avec la sortie de .Net 3.5, le sélecteur d'identité CardSpace est utilisable sur des sites ne disposant pas de SSL.

Cette modification se traduit techniquement par une modification du format des jetons transmis au site Web de destination. Au lieu d'être chiffré avec la clé publique du serveur Web, il transite en clair.

On ne perd pas pour autant toute forme de sécurité : le jeton est toujours signé avec une clé privée connue uniquement du sélecteur d'identité, clé qui change pour chaque site Web.

Le travail du site Web est par contre considérablement simplifié : il ne reste plus qu'à vérifier la signature du jeton avant de pouvoir le manipuler.

Vous pouvez tester dès aujourd'hui sur http://bridge2.grognon.com/, et je posterai prochainement le code du sample.

Si vous avez regardé une démonstration ou deux sur Cardspace vous avez probablement été conquis par la technologie et vous voudriez l’expérimenter un peu. Ce tutorial vous explique comment configurer tous les éléments nécessaires au développement Cardspace sous Windows Vista FR.

Pour Windows 2003 ou Windows XP la démarche est identique, j’explique les différences les plus importantes au fur et à mesure de l’article.

Je ne rentrerai pas dans le détail de l’installation de Visual Studio ou Visual Web developer dans ce pas à pas. Sachez simplement que pour bien fonctionner sous Vista vous devrez installer le SP1 puis un patch (l’adresse est donnée lors du lancement de Visual Studio SP1, ainsi que les conseils d’utilisation). Il vous faudra également sous XP ou 2003 installer .Net 3.0 et IE7.

Installation d’IIS sous Vista

Allez dans le panneau de configuration, dans la zone Programmes, et sélectionnez « Activer ou désactiver des fonctionnalités Windows ».

N’oubliez pas d’activer les options de compatibilité IIS6, Visual Web Express en aura besoin pour se connecter au site web local.

Lancer ensuite un command prompt en mode administrateur, et enregistrez ASP.Net :

Génération et installation du certificat SSL.

A moins de déjà disposer d’un certificat SSL, vous voudrez certainement générer un certificat de test. La solution la plus simple consiste à télécharger le Kit de ressources d’IIS 6 (fonctionne pour Vista, 2003, et longhorn server), que vous trouverez en faisant une recherche sur « IIS Resource Kit ». Lors de l’installation du kit, demandez uniquement l’installation de SelfSSL.

Relancez un command prompt en mode administrateur et générez votre certificat :

La commande à exécuter est en surbrillance, pour les amateurs de copier/coller il s’agit de
SelfSSL /N:CN=www.test.com /V:3650

Nota bene pour les utilisateurs de XP :

Cette étape de génération de certificat est plus délicate sous Windows XP, SelfSSL n’étant pas disponible. Sans entrer dans les détails, voici les principaux écueils à franchir :

1/ Récupérez l’exécutable MakeCert dans les SDKs

2/ Générez un certificat avec la commande barbare suivante :

makecert.exe -a SHA1 -ss my -sr LocalMachine -n "CN=www.test.com" -b 01/01/2000 -e 01/01/2050  -eku 1.3.6.1.5.5.7.3.1 -sky exchange  -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

3/ Allez dans les propriétés de votre serveur Web, dans l’onglet sécurité, et attribuez le certificat à votre site. Vous êtes maintenant arrivés au même point que les utilisateurs de 2003 ou Vista.

Post scriptum de nota bene

Je tiens à présenter toutes mes excuses aux légitimes détenteurs du domaine test.com pour distraire d'honnêtes développeurs d'un site probablement plein d'intérêt.

Modification du fichier Hosts

Pour que votre certificat soit reconnu, vous devrez faire pointer le site http://www.test.com/ sur votre machine de développement. Pour ce faire, il vous faudra modifier le fichier HOSTS situé dans

C:\windows\system32\drivers\etc

ATTENTION : il s’agit d’un fichier protégé, il est donc impératif de lancer Notepad en tant qu’administrateur si vous voulez le modifier.

Lancez un navigateur et allez sur https://www.test.com/

Comme le certificat n’a pas été délivré par une autorité de confiance, IE nous bloque. Nous allons remédier à cela.

1/ Lancez une console d’administration (en tapant mmc)

2/ Dans le menu Fichier, demandez l’ajout d’un composant enfichable. Dans la liste qui apparaît, double-cliquez sur Certificats et choisissez Compte de l’ordinateur dans la boite de dialogue qui apparaît.

3/ Vous devriez maintenant pouvoir accéder au certificat que vous venez de générer :

Copiez maintenant ce certificat dans les certificats des Autorités de certification racine. De cette façon ce certificat sera considéré comme valide par Internet Explorer. Rafraichissez maintenant IE, vous devriez parvenir au résultat escompté :

Paramétrage du certificat pour CardSpace.

Il nous reste une dernière manipulation à effectuer : notre application Web aura tôt ou tard besoin de lire la clé privée du certificat que nous venons de générer. Par défaut, cette clé est protégée et aucune application Web ne peut s’en servir directement. Il existe des méthodes plus élégantes que celle que je vais vous donner maintenant, mais elles demandent des outils supplémentaires.

Relancer un command prompt en mode administrateuret rendez-vous dans le répertoire \ProgramData\Microsoft\Crypto\RSA\MachineKeys

Puis tapez Explorer . (n’oubliez pas le point)

Si aucun fichier n’apparaît modifiez vos options d’affichage pour voir les fichiers système.

(nota : le chemin pour XP/2003 est C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys)

Sélectionnez maintenant le fichier le plus récent (il représente le certificat que vous venez d’ajouter), et modifiez sa sécurité pour donner au compte SERVICE RÉSEAU les droits de lecture sur le fichier.

Attention, le compte est bien SERVICE RÉSEAU avec un é en majuscules (faites un copier/coller depuis cet article si vous ne savez pas faire un É avec votre clavier). Il s’agit du compte qui fait tourner votre site web, vous pouvez bien sûr le modifier en allant dans la console d’administration d’IIS.

(nota : sous XP le compte est probablement ASPNET)

Tester l’installation

Placez le fichier test.aspx dans c:\inetpub\wwwroot et naviguez sur https://www.test.com/test.aspx

Le bouton Déclencher le sélecteur devrait faire apparaître le sélecteur d’identité où vous pourrez sélectionner une carte personnelle.

Elle servira à générer un jeton chiffré consultable dans la textbox (enfin, vous n’apprendrez pas grand-chose puisqu’il est chiffré) ? Le bouton Envoyer au serveur déclenchera le décodage du jeton et l’affichage de son contenu.

Comment proposer une alternative à FTP sous Windows 2003 ? Aujourd'hui, j'ai trouvé trois grandes directions de recherche

SSH + sFTP

BITS

WebDAV + SSL

SSH sous Windows : je n'ai pas épuisé le sujet, mais je n'ai pas trouvé d'implémentation standard, simple de mise en oeuvre, et stable sous Windows 2003. La piste la plus prometteuse pour le moment est un portage Win32 de OpenSSH (http://sourceforge.net/projects/sshwindows), mais le forum et la liste des bugs sont dissuasifs : pas d'activité depuis longtemps, et des problèmes récurrents de stabilité.

BITS : l'implémentation est robuste et l'intégration serveur est bonne, il manque encore un client disponible pour mes utilisateurs. Pour le moment on trouve un utilitaire en ligne de commande pour XP, et quelques wrappers .Net pour la manipulation des jobs, mais il reste quelques ennuyeux problèmes de sécurité (notamment comment protéger un login et un password dans l'application cliente). Exit donc pour quelque temps.

WebDAV + SSL : plus intéressant, puisque la couche de sécurité est robuste et qu'un client WebDav est intégré à l'explorateur Windows. C'est cette solution que je retiens pour le moment. Il reste encore quelques écueils à surmonter, principalement côté serveur. En deux mots, je me refuse à utiliser WebDAV sans SSL.

Ma roadmap :

1/ Installation de  WebDAV

Simple, WebDAV est planqué dans l'install de Windows

2/ Création d'un AppPool avec un compte spécifique. Ce compte est destiné à limiter les privilèges des sites manipulant WebDAV

3/ Création d'une zone disque et d'un site web destiné aux transferts

4/ Pose de SSL sur le site.

cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:<host header>"

cscript.exe adsutil.vbs set /w3svc/<site identifier>/AccessSSL TRUE

Voilà, SSL est posé et seul SSL est utilisable.

Vista est sur le point de sortir, alors esayons d'y voir clair en matière de développement. Malgré tout ce que vous avez pu entendre ou lire ces derniers mois, Vista est beaucoup plus qu'un relookage de Windows XP. Pour vous en convaincre, allez donc lire http://en.wikipedia.org/wiki/Windows_Vista, qui déroule en une seule page concise la liste des nouveautés.

Dans l'ensemble, les applications Windows conçues pour XP tournent directement sur Vista. Dans l'ensemble seulement, puisque les nombreuses modifications liées à la sécurité bloquent certaines fonctionnalités des programmes. Les applications .Net sont bien évidemment peu concernées par ces modifications, puisqu'elles reposent sur un framework conçu et adapté par Microsoft. Pour les applications Win32 classiques tout dépend de ce que fait votre programme, et plus vous tentiez de prendre la main sur le fonctionnement normal de l'OS plus vous risquez de mauvaises surprises en exécution dans un environnement normal sous Vista (vous pouvez bien sûr détacher les ceintures de sécurité et désactiver un certain nombre de protections, mais c'est à vos risques et périls).

Visual Studio est l'une des applications les plus intrusives sur le système d'exploitation : intégration d'un débogueur capable de prendre la main dans tous les environnements, de JavaScript à VB6 en passant pas SQL Server et .Net, accès aux services, déboguage à distance, développement de drivers, etc. En pratique, Visual Studio (2002, 2003, et 2005) ne fonctionne pas complètement sous Vista : en tant qu'éditeur de code et environnement de compilation il donne satisfaction, mais certaines fonctionnalités avancées seront vraisemblablement bloquées par le système d'exploitation.

Quelles sont les possibilités offertes au développeur pour se prémunir contre les mauvaises surprises ? Pour Visual Studio 2005, le SP1 devrait combler la plupart des lacunes, et les éventuels bugs résiduels seront corrigés au fur et à mesure de leur découverte. Pour Visual Studio 2003 le problème est plus délicat, et pour le moment Microsoft ne supporte pas Visual Studio 2003 sous Vista, même si la plupart des scénarios d'utilisation fonctionnent. Il reste alors deux possibilités. Soit faire tourner Visual Studio 2003 sous Windows XP (éventuellement dans une VPC) ou Windows 2003, soit utiliser MSBuild pour éditer et compiler des projets .Net 1.1.

Cette possibilité n'est pas offerte nativement par MSBuild, mais vous trouverez sur CodePlex la solution (http://www.codeplex.com/Wiki/View.aspx?ProjectName). MSBee, puisque c'est son nom, est un add-on à MSBuild permettant de faire de la compilation .Net 1.1 depuis MSBuild, et donc d'utiliser le même outil pour .Net 1, 2 et 3 dans vos développements.