May, 2011

  • Avec Windows

    Kit de démarrage “Protocole d’Echanges Standard et Ouvert” (PRESTO) 2 pour Microsoft Windows Server AppFabric et Microsoft Windows Azure

    • 0 Comments

     

    La page de téléchargement est disponible à l’adresse suivante:

    http://www.microsoft.com/downloads/fr-fr/details.aspx?FamilyID=440c353a-09bc-422a-9748-00ac950176d5

     

    Le kit de démarrage « PRotocole d’Echanges Standard et Ouvert » (PRESTO) 2 propose, à destination des environnements Microsoft Windows Server AppFabric et Microsoft Windows Azure, des exemples de service conformes à la version 2.0.1 du protocole PRESTO. Ce kit est publié sous le contrat de licence de logiciel libre CeCILL-B.
    La modernisation de l’administration pour faire de l’e-administration une réalité suppose de disposer, à la base, d’une infrastructure interopérable d’échange de confiance au service de l’administration électronique. Face à ce constat, la DGME (Direction Générale pour la Modernisation de l’État) a développé en 2006, dans le cadre d’une démarche d’informatisation et d’urbanisation des échanges électroniques, le PRotocole d’Echanges STandard Ouvert de l’Administration (PRESTO) 1.0, un protocole d’échange de données, afin de répondre à la majorité des besoins et avec le but de véhiculer les messages informatiques entre les applications des SI des autorités administratives. La spécification PRESTO 1.0/1.1 vise à fournir protocole d’échange de haut niveau de l’administration électronique qui s’apparente à une enveloppe technique d’échange de message générique afin de pouvoir échanger potentiellement n’importe quels messages au sein de l’administration publique électronique entre les différents acteurs concernés par l’Ordonnance n°2005-1516 sur les échanges électroniques.
    PRESTO 1.x propose un profil de communication permettant de répondre aux exigences d’ouverture, de modularité (adaptation d’un même protocole aux différents cas d’utilisation), et d’interopérabilité, dans le respect des standards internationaux, et définit pour cela, sur la base des services Web SOAP, l’une des traductions possibles de l’approche orientée services (Service Oriented Architecture en anglais ou SOA en abrégé), une enveloppe technique d’échange de données répondant. Pour atteindre les objectifs, le protocole de PRESTO est construit sur la fondation de la pile standardisée WS-* (STAR pour Secured, Transacted, Asynchronous and Reliable), ensemble de recommandations W3C et de standards OASIS. Pour une compréhension de la pile WS-* et de la façon dont les différentes spécifications se composent les unes avec les autres, cliquer ici.
    La version 2.0.1 de PRESTO, objet de ce Kit de démarrage pour les environnements d'exécution Microsoft Windows Server AppFabric et Microsoft Windows Azure, reprend PRESTO 1.0/1.1 (aux versions près des standards concernés) sous la forme d’un profil de services Web dénommé « PRESTO 2 core ». Ce profil s’accompagne d’un ensemble d’extensions permettant de répondre à des problématiques particulières telles que l’envoi de pièce(s) jointe(s), la disponibilité d’un mécanisme d’acquittement, le routage de messages, la corrélation de messages, etc.
    L’interopérabilité vise à favoriser le dialogue des systèmes d’information en utilisant notamment des protocoles et des formats reposant sur des standards ouverts. Mais le recours exclusif à des standards ne saurait suffire, la recherche d’interopérabilité doit être conduite dans un esprit de dialogue, d’échange et de pluralisme des choix équivalents. La volonté des concepteurs de PRESTO 2 est non seulement de définir un protocole sur la base de standards internationaux reconnus, mais également de démontrer que la dite spécification peut être implémentée sur des environnements et langages divers et que les implémentations résultantes tiennent les promesses d’interopérabilité des orientations retenues. Le kit de démarrage PRESTO 2 pour Microsoft Windows Server AppFabric et Microsoft Windows Azure résulte du code de test PRESTO 2 développé par Microsoft France pour les tests d'interopérabilité qui ont été conduits, à l’« Interop Lab » du Microsoft Technology Center (MTC) Paris avec les implémentations Apache Axis 2 et Oracle WebLogic du protocole PRESTO 2. Il propose, à ce titre, des exemples de service pour le rôle Mandataire récepteur.
    Dans ce laboratoire, clients, partenaires et compétiteurs testent des configurations techniques hétérogènes afin d’élaborer les solutions répondant à leurs besoins en termes d’interopérabilité opérationnelle. Ceci est particulièrement important dans le contexte d’un protocole d’échanges comme PRESTO 2 où les implémentations proposées se doivent d’être interopérables par défaut. Nous remercions à ce titre les sociétés Logica France, Oracle France et Petals Link d’avoir consacré le temps et les ressources nécessaires aux tests d’interopérabilité entre les différentes implémentations ainsi que la DGME pour l’organisation de ces tests.
    Ce kit de démarrage PRESTO 2 est destiné aux architectes, aux développeurs ainsi qu'à toutes les personnes qui intéressés par consommer ou exposer des services qui " parlent " PRESTO 2 depuis les environnements d'exécution Microsoft Windows Server AppFabric dans l'entreprise (on-premise) et Microsoft Windows Azure dans le Cloud. Les services proposés dans le cadre du kit de démarrage sont conçus pour être interopérables avec d'autres implémentations qui se conforment aux spécifications PRESTO 2 publiées publiquement. Dans cette version, tous les services Mandataire récepteur sont écrits avec le langage C# avec Microsoft .NET Framework 4.
    Ce kit de démarrage est disponible également sur la plate-forme de développement coopératif Fusion Forge de l’ADULLACT (Association des Développeurs et des Utilisateurs de Logiciels Libres pour l'Administration et les Collectivités Territoriales) qui héberge le projet PRESTO de la DGME.

  • Avec Windows

    [Windows Phone 7] Un site sur l'interopérabilité et à destination des développeurs des plateformes concurrentes

    • 0 Comments

    Une ressource spécifique Windows Phone 7 à suivre, un site dédié à l’interopérabilité avec Windows Phone 7… Le mot “interopérabilité” étant à prendre avec des pincettes, car il ne s’agit pas ici d’ouverture de spécifications de l’OS, mais plutôt des manières de profiter, pour les développeurs Android, iPhone, etc, du travail qu’ils ont fait sur leurs plateformes de prédilection pour en profiter lors du portage de leur(s) applications(s) sur Windows Phone 7. On y retrouve notamment l’excellent tutorial de Jesse Liberty (le Windows Phone 7 Guide for iPhone Application Developers) et on verra très vraisemblablement du contenu similaire sur Android arriver. Gageons qu’il y aura aussi très vite du contenu HTML5 étant donné que la future version d’Internet Explorer 9 pour Windows Phone 7 devrait en avoir un support exemplaire…

    Un article très détaillé sur le sujet, sur le blog officiel de l’équipe de dev Windows Phone 7

  • Avec Windows

    Développer une application Windows Azure en Java avec Eclipse

    • 0 Comments

    Dans ce screencast, je vous montre comment développer une application basique en Java pour Windows Azure, avec les composants suivants:

    Cette application me servira de base pour démontrer par la suite le déploiement de l'application dans Windows Azure.

  • Avec Windows

    Hadoop sur Azure

    • 0 Comments

    Dans un billet récent (en anglais), Mario Kosmiskas montre comment on peut utiliser Hadoop sur Windows Azure.

    http://blogs.msdn.com/b/mariok/archive/2011/05/11/hadoop-in-azure.aspx

  • Avec Windows

    Web SSO SharePoint à l’aide de Yahoo!, Google, Facebook, Open ID…

    • 0 Comments

    Dans un billet précédent, nous avons montré comment se connecter à SharePoint avec un utilisateur de la fédération de test RENATER utilisée dans le monde de l’éducation recherche.

    En s’appuyant sur la même plateforme, on montre ici une authentification avec des fournisseurs Internet que sont Yahoo!, Google, Facebook, ou encore myOpenID. Dans cette implémentation, SharePoint fait confiance à ADFS V2 (ADFS = Active Directory Federation Services) qui fait confiance à Azure ACS (ACS=Access Control Services) qui fait lui-même confiance à divers fournisseurs d’identité classiques d’Internet.

    On trouvera plus d’informations et pointeurs sur la fédération d’identité sur la plateforme Microsoft à http://idmgt.archims.fr.

    Lors du dernier billet, on a utilisé Internet Explorer 9. On utilise ici aussi Firefox, Chrome, et Safari, de façon à aussi montrer que SharePoint est compatible avec ces navigateurs. NB: On utilise la navigation privée qui n’enregistre pas les cookies de façon à pouvoir recommncer les tests en redémarrant le navigateur.

    Dans tous les scénarios, on commence par naviguer vers https://sharepoint.demo.idmgt.archims.fr (NB: adresse non accessible depuis Internet) puis ADFS V2 demande le fournisseur d’identité qu’on veut utiliser.image
    image

    On arrive alors sur la page de choix par défaut d’Azure ACS qui demande quel fournisseur d’identité on veut utiliser. Comme pour ADFS V2, cette page de choix peut être masquée (si on a suffisamment d’information pour choisir à la place de l’utilisateur) ou personnalisée. Ici les pages par défaut ont été laissées pour des raisons pédagogiques.

    On montre ensuite quelques authentifications avec divers fournisseurs et divers navigateurs. l’identifiant qui apparaît en haut à droite n’est pas nécessairement une adresse e-mail. Il s’agit d’un identifiant unique fournit par le fournisseur d’identité. Cela est un choix au niveau de la configuration de la plateforme.

    Yahoo! avec Chrome:
    image

    image

     

    Google avec Firefox:
    image

    image

    image

    image

     

    Facebook avec Safari.
    image

    image

    MyOpenID avec Internet Explorer
    image

    image

    image

     

    Si vous avez des questions sur ces scénarios, ou souhaiteriez en voir d’autres, n’hésitez pas à vous exprimer via les commentaires.

     

    Smile

    Benjamin

  • Avec Windows

    Web SSO SharePoint à l’aide de Shibboleth

    • 0 Comments

    SharePoint Server 2010 permet l’authentification à base de revendications, ce qui permet de nouveau scénarios d’authentification. L’un de ces scénarios est d’avoir des comptes pour lesquels on obtient un jeton à travers Shibboleth. Shibboleth est une implémentation open source basée sur le protocole SAML2. Elle est particulièrement utilisée dans le monde de l’éducation, et en particulier par la fédération RENATER (https://federation.renater.fr/).

    Une plateforme de démonstration au MTC paris met cela en oeuvre. On trouvera plus d’informations sur la fédération d’identité sur la plateforme Microsoft à http://idmgt.archims.fr, où la plateforme de démonstration y est décrite. Dans notre cas, SharePoint 2010 fait confiance à ADFS V2 (ADFS = Active Directory Federation Services) qui fait lui-même confiance à la fédération Renater (et d’autres fournisseurs tels qu’un Shibboleth local, ou encore Azure Access Control Service). A chaque niveau de confiance, on a laissé sur cette plateforme de démonstration les écrans de choix par défaut pour des raisons pédagogiques, mais il est possible de les modifier ou de les rendre invisibles si on peut disposer des informations suffisantes pour ne rien demander à l’utilisateur.

    Des livres blancs ont été écrits sur la théorie et la façon de mettre cela en oeuvre, qu’on trouvera dans le dossier Microsoft France | Interopérabilité.

    On montre ici quelques copies d’écrans de ce que cela donne.

    Connexion à https://sharepoint.demo.idmgt.archims.fr (NB: cette adresse n’est pas accessible depuis Internet). SharePoint redirige le navigateur vers ADFS V2 car on est arrivé sans jeton:
    image

    On choisit la fédération de test RENATER:
    image

    image

    ADFS V2 redirige alors le naviagteur vers le serveur Shibboleth de la fédération de test RENATER qui, afin de délivrer un jeton SAML, doit d’abord authentifier l’utilisateur.
    image

    image

    Le service Shibboleth de test de la fédération RENATER fournit alors un jeton SAML authentifiant etudiant1 à destination d’ADFS V2 et redirige le navigateur vers ADFS V2 qui, à l’aide de ce jeton, émet lui-même un jeton à destination de SharePoint et redirige le navigateur vers SharePoint:
    image

    On peut également ouvrir le document en cliquant dessus.
    image
    image

    image

    image

    image

     

    Il est à noter que si l’on ferme Word et qu’on ouvre à nouveau le document, le contexte de sécurité a été conservé et l’authentification n’est pas redemandée:
    image

    image

    image

    Si vous avez des questions sur ce scénario ou des scénarios similaires, n’hésitez pas à commenter ce billet.

Page 1 of 1 (6 items)