C. Scénarios de mise en œuvre 27








télécharger 325.98 Kb.
titreC. Scénarios de mise en œuvre 27
page5/10
date de publication30.03.2017
taille325.98 Kb.
typeScénario
ar.21-bal.com > loi > Scénario
1   2   3   4   5   6   7   8   9   10

c.Scénarios de mise en œuvre


Le succès des situations précédentes et des standards et initiatives qui les sous-tendent dépend grandement de l’adhésion des utilisateurs d’un (méta-)système fédéré et par là même de la confiance que ces derniers portent dans le système pris dans son ensemble.

Pourquoi irais-je donner mes identifiants ? Que va-t-il en être fait ? Autant de questions que l’usager est amené à se poser et ce dernier ne comprend pas pourquoi il doit faire tout cela. La confiance ne se décrète pas, elle se mérite !

Pour autant, le besoin de mécanismes d’authentification forte et de dispositif anti-hameçonnage/vol d’identité est croissant. Les statistiques proposées sur le site de l’Anti-Phishing Working Group51 sont, à ce titre, édifiantes. Les fournisseurs de services sont aujourd’hui beaucoup plus intéressés par la fédération d’identité qu’il y a encore 2 ou 3 ans. Pour l’entreprise désormais étendue, et reposant, le cas échéant en termes d’optimisation de ces coûts, sur des services et solutions dans le nuage, cela devient une obligation !

Encore faut-il que les technologies disponibles permettent de mettre en place facilement ce genre de scénario et de participer ainsi aisément à un tel méta-système d’identité…

c.1Cadre d’illustration avec les technologies Microsoft


Fondée sur les services d'annuaire Active Directory et destinée aussi bien aux développeurs qu'aux professionnels de l’information, Microsoft propose aujourd’hui un ensemble de technologies ouvertes et interopérables permettant de rendre concrète les notions d’identité fondée sur les revendications, de méta-système et mash-up d’identités introduites à la section § a Notions de méta-système et de mash-up d’identités.

Ces technologies pour l’identité et l’authentification unique aide à simplifier l’accès aux applications, aux services Web, et à d’autres systèmes :

  • au sein de l’entreprise,

  • entre organisations,

  • sur le Web et dans le nuage comme avec la plateforme Windows Azure ou Microsoft Online Services.



Ces technologies sont mises en perspectives vis-à-vis de tel ou tel scénario type à mettre en œuvre dans le guide A Guide to Claims–based Identity and Access Control52.

Il s’agit pour l’essentiel, à l’exception des services dans le nuage comme Microsoft Windows Azure AppFabric platform Access Control Services (ACS) 2.0, de composants de la plateforme Windows (Server) et, à ce titre, leur droit d’utilisation est inclus dans le coût des licences associées.

Les sections suivantes présentent ces différentes technologies. Nous vous invitons à consulter à titre de complément le kit de formation Identity Developer Training Kit53 et/ou à visionner les différents webcasts associés54.

c.1.1Microsoft Windows Identity Foundation (WIF) 1.0

c.1.1.1Vue d’ensemble




Windows Identity Foundation (WIF en abrégé) 1.055 constitue un ensemble d'API, ou une bibliothèque d’identité, à destination des développeurs ASP.NET et Windows Communication Foundation (WCF en abrégé) pour la conception respectivement d’applications Web et de services Web à même de consommer directement des revendications et d’établir un cadre de confiance dans un contexte de fédération. WIF supporte également la notion de délégation d’identité. Les guides AD FS 2.0 Federation with a WIF Application Step-by-Step Guide56 et Identity Delegation with AD FS 2.0 Step-by-Step Guide57 illustrent ces fonctionnalités en relation avec AD FS 2.0 (Cf. section éponyme § c.1.2).

A ce titre, WIF propose nativement le support des standards OASIS WS-Federation et WS-Trust. L’extension Windows Identity Foundation Extension for OAuth CTP Version 158 apporte, comme son nom le suggère, le support du protocole OAuth 2.0.

WIF constitue également un socle d’accueil pour des applications existantes nécessitant un contexte de sécurité donné comme Kerberos. Pour cela, WIF permet d’utiliser les revendications obtenues afin de constituer un tel contexte et le transmettre à l’application considérée au travers du service WIF Claims to Windows Token Service (C2WTS en abrégé).

WIF propose enfin une fondation pour l’écriture de STS personnalisés.

Le livre blanc Microsoft Windows Identity Foundation (WIF) Whitepaper for Developers59 offre une première vue du Framework. Pour aller plus loin, l’ouvrage Programming Windows Identity Foundation60 est à a conseiller vivement à tout développeur WIF.

Le SDK (Software Development Kit) WIF61 propose des modèles de projet pour développer facilement des applications Web et des services Web fondés sur les revendications ainsi que des STS personnalisés.

Le forum WIF62 regroupe les échanges de la communauté s’intéressant à cette technologie.

c.1.1.2S’interfacer avec d’autres protocoles et standards


Au-delà des standards supportés nativement par le Framework WIF, il peut s’avérer intéressant de capitaliser sur la fondation proposée par WIF pour l’écriture de STS personnalisés et d’utiliser un tel socle pour mettre à disposition un STS passerelle protocolaire.

Ainsi, pour permettre, par exemple, une authentification OpenID (Cf. section éponyme § b.2.2) auprès d’un fournisseur OpenID (Google, Orange, PayPal, Yahoo, myopenid, etc.) au niveau d’une application Web supportant le protocole WS-Fed Passive (via le Framework WIF par exemple), on peut envisager un STS personnalisé qui assure la transition/traduction entre le protocole OpenID et le protocole WS-Fed Passive et vice versa.

Un tel STS développé avec WIF doit fournir une page de connexion qui fera la « poignée de main » (handshake en anglais) avec le fournisseur OpenID. Pour cela, la bibliothèque DotNetOpenAuth63 peut être utilisée pour faire apparaitre le STS comme un consommateur d’identité OpenID. Ce STS peut ensuite être déclaré comme un STS de confiance au niveau de l’application considérée. Sur cette base, des utilisateurs authentifiés par un fournisseur OpenID reconnu par le STS personnalisé peuvent ensuite accéder aux ressources de ladite application en fonction des permissions qui leur seront conférées.

Un tel exemple de STS est proposé, avec une application exemple, dans le billet OpenID – WS-Fed Protocol Transition STS64. Le kit thinktecture Starter STS (Community Edition)65 disponible sur la forge CodePlex et fondé sur le Framework WIF propose également cette capacité en s’appuyant sur la bibliothèque DotNetOpenAuth.



Figure - STS Transition de Protocole avec OpenID.

La Figure illustre les interactions entre les différentes parties impliquées lors de la première connexion. La figure montre les interactions de façon conceptuelle. En réalité, toutes ces flèches sont des requêtes, redirections et réponses HTTP qui passent par le browser client.

  1. L’utilisateur navigue vers l’application considérée.

  1. Le Framework WIF détecte que l'utilisateur est anonyme et tente d'accéder à une page protégée. De ce fait, il émet une requête WS-Fed SignIn à destination du STS et redirige ainsi l’utilisateur vers ce dernier.

  2. Au niveau de la page de connexion du STS chargée de faire la poignée de main avec un fournisseur OpenID, l'utilisateur précise son identifiant OpenID.

  3. Le STS émet une requête d'authentification à destination du fournisseur OpenID et de rediriger ainsi l’utilisateur vers ce dernier.

  4. Le fournisseur OpenID demande le mot de passe correspond à l’identifiant OpenID précisé.

  5. Le fournisseur OpenID valide l’identité de l’utilisateur.

  6. Le fournisseur OpenID retourne une réponse d'authentification au STS, avec la redirection associée.

  7. Le STS extrait les revendications émises par le fournisseur OpenID et génère un jeton SAML avec les revendications OpenID. Le STS renvoie une réponse WS-Fed SignIn avec le jeton SAML avec la redirection de l’utilisateur vers l’application accédée à l’origine.

Le Framework WIF récupère le jeton SAML, le valide et génère sur cette base un principal de sécurité. L'utilisateur peut accéder maintenant à la page protégée puisqu’il est authentifié. Des informations de profil sont également potentiellement disponibles (si l'utilisateur a rempli son profil dans le fournisseur OpenID).

Cette même approche peut également constituer une voie d’intégration pour des applications reposant sur un socle non Microsoft. Ainsi, une authentification Web unique peut être proposée au-delà des applications reposant sur le Framework WIF à des applications PHP ou Java sur Linux par exemple. Ces applications pourront utiliser pour cela la bibliothèque simpleSAMLphp66 respectivement la bibliothèque OpenSAML67.

Le STS précédent peut être étendu pour augmenter les revendications d’identité venant du fournisseur OpenID avec d’autres revendications obtenues via l’interrogation d’un référentiel local ou une interaction avec un autre fournisseur de revendication via WS-Trust par exemple. Le STS construit une identité composite ou mash-up d’identité. Une telle approche est décrite dans le billet Using Consumer Identities for Business Interactions68 avec une identité PayPal.

Le projet de STS multi-protocoles Protocol Bridge Claims Provider69 utilisé dans ce contexte et disponible sous licence libre Ms-PL70 utilise différents fournisseurs de revendication. Un fournisseur de revendications est une source faisant autorité pour les revendications qui parle un protocole spécifique (OpenID avec l’extension AX (OpenID Attribute Exchange71), OpenID avec SReg (OpenID Simple Registration Extension72), OAuth 2.0, un protocole personnalisé, etc.). Au sein du STS multi-protocoles, un fournisseur de revendications est ainsi lié à un gestionnaire de protocole, une classe qui implémente le protocole. Le STS multi-protocoles a été testé avec succès avec les fournisseurs de revendication Yahoo, Facebook et Windows Live ID.

Au-delà de la mise à disposition d’un STS personnalisé supportant d’autres protocoles, le Framework WIF peut également être étendu de façon à ce qu’une application reposant sur WIF supporte d’autres protocoles comme le standard OASIS SAML 2.0. C’est ce que propose en substance par exemple le Framework SAML 2.0 for Windows Identity Foundation73 de la société SafeWhere. Ce Framework permet à une application ASP.NET + WIF d’être vue comme un fournisseur de services SAML 2.0 conforme au mode opérationnel SP Lite. (Le Framework OIOSAML.NET sous licence libre MPL74 sur la forge Codeplex propose une implémentation .NET respectant le profil danois eGovernment OIOSAML 2.0. Cette implémentation ne repose pas sur WIF.)

c.1.2Microsoft Active Directory Federation Services (AD FS) 2.0

c.1.2.1Vue d’ensemble


Microsoft Active Directory Federation Services (AD FS en abrégé) 2.075 constitue fondamentalement un STS à destination des services d’annuaires Active Directory, en l’occurrence Active Directory Domain Services (AD DS en abrégé) ou Active Directory Lightweight Directory Services (AD LDS en abrégé), et d’autres référentiels.

AD FS offre aux utilisateurs finaux une expérience d’authentification unique (Web mais pas uniquement) entre applications, plateformes et organisations.

Comme présenté précédemment, un tel service est à même d’émettre, de valider et d’échanger des jetons de sécurité, d’émettre dans ce dernier cas par exemple un jeton de délégation d’identité. La notion d’échange induit la capacité de transformation de jetons en termes de type de confiance, de format, de sémantique et de (valeurs des) revendications véhiculées par un jeton.

En fonction du rôle particulier du STS considéré et de son emplacement dans la topologie globale de confiance, le type et la sémantique des revendications contenues dans le jeton de sécurité varient. Il est aussi possible d’émettre plusieurs jetons pour des services cibles différents.

Comme tout STS, AD FS 2.0 peut jouer (simultanément) à ce titre plusieurs rôles distincts et participer à différents types de topologies de schémas de confiance :

  • STS fournisseur d’identités demandeur (IdP) - L’authentification effectuée par le STS vis-à-vis du référentiel d’authentification du fournisseur d’identités produit un jeton de sécurité à destination du service cible afin d’obtenir un accès autorisé. AD FS 2.0 agit en tant que fournisseur de revendications (Claims Provider en anglais) ;

  • STS consommateur d’identités (SP) - Le STS vérifie les jetons de sécurité présentés par les demandeurs et génère des jetons donnant accès au service cible. AD FS 20 agit en tant que consommateur d’identité (Relying Party en anglais) ;

  • STS courtier en confiance entre deux ou plusieurs parties - Dans ce cas, le cadre de confiance établie entre chaque partie et le négociant établit un cadre de confiance entre les parties elles-mêmes. AD FS 20 agit dans les deux rôles précédents.

Dans ce contexte, AD FS 2.0 propose une interopérabilité native intégrée via des standards de fédération d’identités, comme OASIS WS-Trust, WS-Federation, SAML 2.0, IMI 1.0, et des revendications.

Au niveau SAML 2.0 par exemple, AD FS 2.0 supporte plus précisément, les modes opérationnels IdP Lite et SP lite (Cf. document OASIS Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.076) ainsi que le profil eGovernment harmonisé Liberty Alliance version 1.5 (Cf. Liberty Alliance eGovernment profile for SAML 2.077).

AD FS 2.0 a passé avec succès les tests d’interopérabilité SAML 2.0 pour ces modes opérationnels IdP Lite, SP Lite et profil GSA 1.5 comme décrit dans le document Liberty Interoperability Testing Procedures for SAML 2.0 version 3.2.278 (Cf. communiqué de presse Liberty Alliance Entrust, IBM, Microsoft, Novell, Ping Identity, SAP and Siemens Pass Liberty Alliance SAML 2.0 Interoperability Testing79).

Le livre blanc Utiliser AD FS 2.0 pour une authentification unique Web fédérée fondée sur SAML 2.080 décrit la configuration relative au standard SAML 2.0 d’une façon générale et une série de livres blancs81 décrit, plus particulièrement, la mise en œuvre d’AD FS 2.0 avec CA Federation Manager, Oracle Identity Manager, Ping Identity PingFederate, Shibboleth 2, etc. et ce, que ce soit en tant qu’IdP et/ou SP.

Par ailleurs, AD FS 2.0 est à même d’agir comme passerelle protocolaire entre les standards OASIS WS-Federation et SAML 2.0 ; dans le contexte d’une transaction courante, et en fonction des acteurs en présence, une partie du dialogue peut s’effectuer selon l’un de ces deux protocoles, et l’autre partie selon l’autre protocole.

Tant le support du protocole SAML 2.0 que cette capacité de passerelle protocolaire ont été accueillis des plus favorablement par Scott Cantor :

« As a Shibboleth and OpenSAML project developer, and a deployer of the Shibboleth software at The Ohio State University, I’m excited and gratified that Microsoft is implementing the SAML 2.0 Web SSO profile in its upcoming products. Throughout the life of the Shibboleth project, and my work on the SAML 2.0 standard, our goal has been to leverage open standards to foster broad interoperability in federated identity within the higher education community and between it and its many commercial and non-commercial partners. Microsoft is clearly one of those critical partners, and as a key technology supplier, its support for the SAML standard reflects an understanding of our community’s needs and goals, and will expand the scope and impact of our efforts.

Our users will benefit by obtaining access to the broadest potential set of federated applications and services, and our worldwide community will benefit from the opportunity to deploy Microsoft’s identity solutions with the knowledge that they will interoperate with Shibboleth. Microsoft’s willingness to listen to our requirements and suggestions demonstrates a commitment to real-world compatibility. I look forward to continuing the dialog with Microsoft as we drive further interoperability in the use of federation metadata to scale and simplify both SAML 2.0 and WS-Federation deployments. »

Toutes ces caractéristiques d’AD FS 2.0 s’inscrivent dans la suite logique de l’annonce majeure82 faite par Microsoft en février 2008 dans le but d’améliorer l’ouverture de ses produits, d’offrir une meilleure interopérabilité et de créer des opportunités pour les développeurs, les partenaires, les clients et les concurrents.

L’échange d’information entre personnes et organisations, l’interopérabilité entre applications et services sont devenus en effet des besoins essentiels. Microsoft a pris depuis déjà un certain temps des engagements concernant l’interopérabilité. Nous avons échangé avec nos clients au sujet de leurs besoins d’interopérabilité et nous les avons écoutés sur la manière dont les solutions Microsoft pourraient devenir encore plus ouvertes et interopérables.

Pour répondre à ces enjeux et ces besoins, Microsoft applique quatre principes d’interopérabilité à ses produits à large diffusion comme Windows Vista (y compris le Framework .NET), Windows Server 2008, SQL Server 2008, Exchange Server 2007, Office SharePoint Server 2007 et Office 2007, ainsi que toutes les futures versions de ces produits :

  • Garantir une connexion ouverte à ces produits ;

  • Promouvoir la portabilité des données ;

  • Améliorer le support des standards de l’industrie ;

  • Favoriser l’échange et la collaboration avec l’industrie y compris les différentes communautés Open Source autour des questions d’interopérabilité et de standards.

Ces principes s’appliquent en particulier à AD FS 2.0 compte tenu de ses objectifs.

Cette plateforme ouverte offre aux utilisateurs finaux une expérience d’authentification unique (Web mais pas uniquement) entre applications, plateformes au sein de l’entreprise, entre organisations, sur le Web et dans les nuages comme avec la plateforme Windows Azure ou avec les services Microsoft Online Services via la passerelle de fédération Microsoft dans le nuage (Cf. section § b.2.1 Windows Live ID).

Ces capacités sont reconnues par le marché. En effet, à l'occasion de la conférence EIC (European Identity Conference) 2009, le principal événement européen pour l'identité et la gestion des accès ainsi que pour la gouvernance, la gestion des risques et la conformité, l’analyste Kuppinger Cole a attribué le prix European Identity Award 200983, dans la catégorie « Meilleure Innovation », à Microsoft pour le projet Geneva (AD FS 2.0 et WIF 1.0), dans laquelle la fédération devient partie intégrante des conteneurs utilisateur : « one of the most significant enhancements for future use and dissemination of the Identity Federation ».

À l'occasion de la conférence EIC 2010, le prix European Identity Award 201084, cette fois dans la catégorie « Meilleur projet B2C », a été attribué à l'Université de Washington (UW). UW a été honoré pour sa solution de Fédération d'identité fondée sur AD FS 2.0 et WIF 1.0 dans la Recherche et l'éducation qui a été développée en partenariat avec Microsoft et qui vise à faire partie de l'initiative Microsoft Live@Edu mentionnée précédemment.

« The University of Washington is delighted to have its work with Microsoft on federation services honored by Kuppinger Cole », a déclaré Bob Morgan, architecte identité pour les technologies de l’information à UW et membre de l’équipe projet Shibboleth:

« At UW, we are committed to standards-based federation to extend the value of UW identity to the services our users need. It is great to partner with Microsoft since they too are making a commitment to federation for Windows Live and Live@edu. Live@edu's support of higher-education federations including InCommon is a key differentiator. Making it all work has many challenges, but it's essential so the higher-ed community can collaborate seamlessly and securely in cloud environments. »

Nathan Dors, responsable de l’identité et la gestion des accès pour les technologies de l’information à UW, a ajouté :

« We agree with Microsoft on the importance of being both standards-oriented and pragmatic. Choice of federating technology is key and we appreciate Microsoft's striving to reach parity between AD FS 2.0 and Shibboleth solutions.  »

Le Centre de ressources Microsoft TechNet AD FS 2.085 et le Weblog du groupe produit86 proposent l’ensemble des informations nécessaires à la mise en œuvre d’AD FS 2.0.



A ce propos, dans un contexte de Microsoft Online Services, l’établissement d’un cadre de confiance entre un serveur AD FS 2.0 en entreprise et Microsoft Office 365 Beta, ainsi que ses conditions de mise en œuvre, est décrit au travers d’une série d’articles87. Ce contenu est destiné aux professionnels de l'informatique qui veulent tester ou implémenter une authentification unique Web de bout en bout avec des applications pour Microsoft Office 365 beta avec les applications clientes riches et Web.

c.1.2.2S’interfacer avec d’autres référentiels, protocoles et standards


L’utilisation pour l’authentification, au niveau d’un serveur AD FS 20 dans le rôle d’un fournisseur de revendication d’un référentiel autre que les services d’annuaires Active Directory (AD DS ou AD LDS) peut s’appuyer sur la mise en œuvre d’un STS personnalisé développé avec le Framework WIF comme cela a été présenté précédemment (Cf. section § c.1.1.2 S’interfacer avec d’autres protocoles et standards).

Comme également abordé dans ce cadre, un STS personnalisé permet de pouvoir s’appuyer sur des fournisseurs d’identité utilisant des protocoles autres que les standards OASIS supportés nativement, comme le protocole OpenID par exemple et vis-à-vis desquels un cadre de confiance ne peut pas être établi directement sur les bases supportées par AD FS 2.0.

Dans les deux cas de figure, le STS personnalisé doit être déclaré comme un fournisseur de revendication au niveau d’AD FS 2.0 de façon à ce que les jetons SAML émis soient reconnus comme étant dignes de confiance.

Ceci suppose par ailler de modifier la logique des pages d’authentification d’AD FS 2.0 pour collecter, le cas échéant, les crédentités nécessaires au niveau de la page et intégrer un rebond vers le STS personnalisé pour obtenir un jeton SAML contenant les revendications souhaitées. La logique d’interaction avec le référentiel ou le fournisseur est propre au STS ainsi développé.

Ces principes sont décrits dans le billet Customizing the AD FS 2.0 Sign-in Web Pages88. Ce billet précise également les pointeurs vers le contenu pertinent du SDK AD FS 2.089.

Pour donner une autre illustration que le cas d’utilisation avec un fournisseur OpenID vu précédemment, ce type d’approche peut être également utilisé au niveau du serveur AD FS 2.0 (dans son rôle de fournisseur de revendications) pour déléguer l’authentification à réaliser à son tour en s’appuyant sur un autre protocole d’authentification Web unique, cette fois non fédéré, comme le protocole CAS (Central Authentication Service)90, comme cela est fait typiquement dans le cadre de la mise en œuvre du projet Shibboleth (en tant que système distribué sous licence de logiciel libre) pour un fournisseur d’identité. L’approche consiste à utiliser, pour cela, le client CAS .NET91 qui s’intègre directement avec les applications ASP.NET.

Le STS personnalisé passif développé avec le modèle pour ASP.NET utilise la bibliothèque CAS.NET pour intercepter et d’authentifier l’utilisateur s’il n’est pas connecté et enrichir la session ASP.NET avec les informations résultantes. Ces informations peuvent ensuite être utilisées pour réémettre un jeton SAML grâce au Framework WIF.

c.1.3Microsoft Windows Azure AppFabric platform Access Control Services (ACS) 2.0




Le service Access Control Services (ACS) 2.092 de la plateforme Windows Azure AppFabric, annoncé lors de la Microsoft Developer Conference 201093 constitue fondamentalement un STS d’autorisation à destination des applications Web et de services Web SOAP et RESTful en entreprise ou située dans le nuage avec la plateforme Windows Azure.

Cette version 2.0 propose nombre d’améliorations et d’évolutions significatives vis-à-vis de la version actuellement en production.

Au-delà d’une intégration poussée avec le Framework WIF et son outillage, d’un support natif d’AD FS 2.0 à la fois comme fournisseur de revendications ou consommateur d’identité, ACS 2.0 supporte nativement les fournisseurs d’identité sociale populaires : Windows Live ID, Google, Yahoo, et Facebook. ACS 2.0 permet de réaliser une transition de protocole entre ces principaux fournisseurs (et le protocole sous-jacent utilisé) et le protocole WS-Federation par exemple.

Les fonctions que pourraient réaliser un STS personnalisé pour interagir avec un fournisseur OpenID (Cf. section § c.1.1.2 S’interfacer avec d’autres protocoles et standards) constituent une fonction native du service, ce qui comprend également :

  • La notion de découverte de domaine de sécurité (Home Realm Discovery en anglais ou HRD en abrégé) ou Where Are You From? (WAYF en abrégé) qui permet à un utilisateur de choisir son fournisseur d’identité est intégré et personnalisable,

  • Un portail Web qui permet un accès administratif à la configuration ACS,

  • Un service de gestion fondé sur le protocole OData94 qui fournit un accès programmatique à la configuration ACS.

En termes de protocoles, le STS ACS 2.0 supporte WS-Trust, WS-Federation, OpenID et OAuth 2.0 (draft 10). Pour ce qui est des formats de jetons, il s’agit de SAML 1.1, SAML 2.0, et SWT.

Dans ces conditions, ACS 2.0 peut être utilisé dans de très nombreux contextes et situations qu’il serait difficile de résumer ici compte tenu de la souplesse apportée.

Au moment de la rédaction de ce livre-blanc, la documentation de ce service est en cours de mise à disposition sur la forge Codeplex95. Le billet Shaping Windows Azure AppFabric Access Control Service 2.0 Documentation on Codeplex96 précise où trouver toutes les informations, guides étapes-par-étapes et exemples.
1   2   3   4   5   6   7   8   9   10

similaire:

C. Scénarios de mise en œuvre 27 iconC. Scénarios de mise en œuvre 27

C. Scénarios de mise en œuvre 27 iconScénarios relatifs au service Web de mise à jour des appareils 13

C. Scénarios de mise en œuvre 27 iconCalendrier de mise en œuvre 14

C. Scénarios de mise en œuvre 27 iconScénario pédagogique. Pour de Lièvre, Quintin & Depover (2002), IL...
«activités», «tâches», «scénarios», …, se posent des questions de «granularité», de mise en scène et d’architecture

C. Scénarios de mise en œuvre 27 icon"Mise en œuvre de Cisco Unified Communication Manager"

C. Scénarios de mise en œuvre 27 iconPrincipes et conditions de mise en œuvre du protocole enum en France

C. Scénarios de mise en œuvre 27 iconThierry brugvin lipha, Paris Est la difficile mise en œuvre

C. Scénarios de mise en œuvre 27 iconLa mise en œuvre de la prime d’activité : un enjeu pour la Branche Famille

C. Scénarios de mise en œuvre 27 iconLa mise en œuvre d’une «mixité sociale» dans le parc hlm de la ville de Martigues

C. Scénarios de mise en œuvre 27 iconMéthodologie de mise en œuvre et problèmes posés par la première application de la réforme 2005








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com