Exporter (0) Imprimer
Développer tout

Notes de publication

Publication: avril 2011

Mis à jour: mars 2015

S'applique à: Azure

Cette rubrique décrit les nouvelles fonctionnalités de chaque version de Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS), décrit dans quelle mesure chaque version du produit diffère de ses prédécesseurs et souligne les modifications avec rupture qui peuvent affecter le code écrit pour une version antérieure.

Au 19 mai 2014, les nouveaux espaces de noms ACS ne peuvent pas utiliser Google comme fournisseur d'identité. Les espaces de noms ACS qui utilisaient déjà Google et qui étaient enregistrés avant le 19 mai 2014 ne sont pas affectés. Cette nouvelle limitation existe car Google supprime progressivement la prise en charge d'OpenID 2.0, dont dépend ACS, et a fermé les inscriptions pour les nouvelles applications. Les espaces de noms ACS existants qui utilisaient Google continueront à fonctionner jusqu'au 20 avril 2015. Si votre application nécessite la prise en charge des comptes Google, nous vous recommandons d'inscrire votre application directement auprès de Google.

Si un utilisateur essaie de se connecter à un nouvel espace de noms ACS à l'aide de son compte Google, il est redirigé vers une page d'erreur HTTP 400.

Nouvel espace de noms ACS et erreur Google

Pour accroître la disponibilité et les performances d'ACS pour tous les utilisateurs, ACS a implémenté une limite de 30 demandes de jetons par seconde pour chaque espace de noms. Si un espace de noms dépasse cette limite pendant une période prolongée, ACS rejette les demandes de jetons en provenance de l'espace de noms pendant toute la durée de l'intervalle et renvoie une erreur HTTP 429 / ACS90055 « Trop de demandes ». Pour plus d'informations, consultez Limitations du service ACS et Codes d'erreur ACS.

Nouvelles fonctionnalités

La mise à jour de décembre 2012 d'ACS comprend les nouvelles fonctionnalités suivantes :

Prise en charge de la déconnexion unique fédérée à l'aide du protocole WS-Federation

Les applications web qui utilisent ACS pour activer l'authentification unique avec des fournisseurs d'identité à l'aide du protocole WS-Federation peuvent maintenant tirer parti des fonctionnalités de déconnexion unique. Quand un utilisateur se déconnecte d'une application web, ACS peut le déconnecter automatiquement du fournisseur d'identité et d'autres applications de partie de confiance qui utilisent le même fournisseur d'identité.

Cette fonctionnalité est activée pour les fournisseurs d'identité WS-Federation, y compris les services de fédération Active Directory 2.0 et Windows Live ID (compte Microsoft). Pour activer la déconnexion unique, ACS effectue les tâches suivantes pour les points de terminaison de protocole WS-Federation :

  • ACS reconnaît les messages wsignoutcleanup1.0 en provenance des fournisseurs d'identité et répond en envoyant des messages wsignoutcleanup1.0 aux applications de partie de confiance.

  • ACS reconnaît les messages wsignout1.0 et wreply en provenance des applications de partie de confiance et répond en envoyant des messages wsignout1.0 aux fournisseurs d'identité et des messages wsignoutcleanup1.0 aux applications de partie de confiance.

Pour plus d'informations, consultez Exemple de code : ASP NET MVC 4 avec la déconnexion fédérée et Authentification passive pour ASP.NET dans WIF.

Fin de la prise en charge d'ACS 1.0

La prise en charge d'Access Control Service 1.0 n'est plus assurée dans cette version, y compris la prise en charge de la migration d'Access Control Service 1.0 vers Access Control Service 2.0.

Navigation vers des espaces de noms Access Control dans le nouveau portail de gestion Azure

Le nouveau portail de gestion Azure (http://manage.WindowsAzure.com) permet d'accéder au portail de gestion ACS familier où vous pouvez créer et gérer des espaces de noms Access Control.

Pour accéder au portail de gestion ACS

  1. Accédez au Portail de gestion Microsoft Azure (https://manage.WindowsAzure.com), ouvrez une session, puis cliquez sur Active Directory. (Conseil de dépannage : « Active Directory » est manquant ou non disponible)

  2. Cliquez sur un espace de noms Access Control, puis sur Gérer.

Pour créer un espace de noms Access Control, cliquez sur Nouveau, Services d'application, Access Control, puis cliquez sur Création rapide. (Ou cliquez sur Espaces de noms Access Control avant de cliquer sur Nouveau.)

Pour obtenir de l'aide sur les tâches de gestion d'ACS dans le portail de gestion Microsoft Azure, cliquez sur Active Directory, puis cliquez sur Aide (?). (Ou cliquez sur Active Directory, cliquez sur Espaces de noms Access Control, puis cliquez sur Aide.)

Navigation vers l'espace de noms Access Control pour un bus des services

Quand vous créez un espace de noms Service Bus dans le , celui-ci crée automatiquement un espace de noms Access Control pour le bus des services.

Pour configurer et gérer l'espace de noms Access Control pour un bus des services

  1. Connectez-vous au Portail de gestion Azure.

  2. Cliquez sur Service Bus, puis sélectionnez un bus des services.

  3. Cliquez sur Clé d'accès, puis sur Ouvrir le portail de gestion ACS.

Pour vérifier que l'espace de noms Access Control est associé au bus des services, consultez le champ Espace de noms de service en haut de la page Access Control Service. Le nom de l'espace de noms est constitué du nom du bus des services et d'un suffixe « -sb ».

Pour plus d'informations, consultez Procédure : Gérer l'espace de noms du contrôle d'accès pour Service Bus.

Améliorations apportées au portail de gestion ACS pour l'affichage des clés de fournisseurs d'identité WS-Federation, avec masquage des mots de passe

Cette version contient deux améliorations liées à l'affichage et à l'utilisation des certificats, des clés et des mots de passe dans le portail de gestion ACS 2.0 :

  • Les certificats de signatures sont désormais visibles dans la section Modifier le fournisseur d'identité WS-Federation : auparavant, les certificats importés à partir de métadonnées WS-Federation utilisées pour valider la signature des jetons émis par ce fournisseur d'identité n'étaient pas visibles dans le portail de gestion ACS. La section Modifier le fournisseur d'identité WS-Federation affiche maintenant des informations sur les certificats importés, notamment leur état et leur date d'expiration. Ces certificats peuvent maintenant être actualisés à l'aide de la case à cocher « Réimporter les données à partir de l'URL de métadonnées WS-Federation lors de l'enregistrement ».

  • Les mots de passe et les clés de signature symétriques sont désormais masqués par défaut : pour empêcher toute divulgation accidentelle des mots de passe et des clés symétriques, ces valeurs sont maintenant masquées par défaut dans les écrans Modifier dans tout le portail. Pour afficher la valeur d'un mot de passe ou d'une clé symétrique (par exemple, pour pouvoir la copier dans une application), vous devez appuyer sur un bouton « Afficher le mot de passe » ou « Afficher la clé ».

Capacité à fédérer des clients d'annuaire avec des espaces de noms Access Control

Les clients Azure Active Directory peuvent maintenant être utilisés comme fournisseurs d'identité dans les espaces de noms Access Control. Cela vous permet, par exemple, d'autoriser votre application web à accepter des identités d'entreprise provenant de clients d'annuaire et des identités de consommateur provenant de fournisseurs sociaux tels que Facebook, Google, Yahoo!, des comptes Microsoft ou tout autre fournisseur OpenID. Vous trouverez des instructions détaillées sur la façon d'implémenter ce scénario dans le billet de blog intitulé Provisioning an Azure Active Directory Tenant as an Identity Provider in an ACS Namespace.

Prise en charge du protocole SAML 2.0 pour les applications de partie de confiance (Developer Preview)

ACS prend désormais en charge le protocole SAML 2.0 pour l'émission de jetons à des applications de partie de confiance. La prise en charge du protocole SAML 2.0 a été publiée en tant que version préliminaire destinée aux développeurs, ce qui signifie que les détails de son implémentation sont encore sujets à modification. Pour plus d'informations, consultez Developer Preview : protocole SAML.

Problèmes connus

Dans la mise à jour de décembre 2012 de Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS), les problèmes connus suivants ont été identifiés :

Les coadministrateurs Azure peuvent désormais gérer les espaces de noms. Toutefois, une action est requise pour propager des coadministrateurs existants à des espaces de noms existants.

Avant la mise à jour de novembre 2012, nous avons résolu un problème selon lequel, par défaut, seul l'administrateur de service Azure principal pouvait gérer les espaces de noms Access Control créés dans l'abonnement. Si un coadministrateur Azure tentait d'accéder au portail de gestion ACS pour un espace de noms Access Control, il recevait l'un des codes d'erreur ACS suivants :

  • ACS50000 : Une erreur s'est produite lors de l'émission du jeton.

  • ACS60000 : Une erreur s'est produite lors du traitement des règles pour la partie de confiance utilisant l'émetteur ‘uri:WindowsLiveID’

  • ACS60001 : Aucune revendication de sortie n'a été générée pendant le traitement des règles.

Ce problème a maintenant été résolu pour les nouveaux espaces de noms Access Control créés par un administrateur ou un coadministrateur de service Azure. Toutefois, les clients ayant des espaces de noms qui existaient avant le correctif doivent appliquer la solution de contournement suivante pour que les données des coadministrateurs soient propagées à ces espaces de noms :

  1. Connectez-vous au portail Azure (https://windows.azure.com/) à l'aide d'informations d'identification d'administrateur de compte ou de service.

  2. Supprimez puis rajoutez le coadministrateur, à l'aide des instructions fournies dans Ajouter un coadministrateur à un abonnement Azure (http://msdn.microsoft.com/en-us/library/windowsazure/gg456328.aspx)

  3. Déconnectez-vous, puis connectez-vous au portail Azure à l'aide des informations d'identification du coadministrateur. Vous pourrez alors gérer les espaces de noms Access Control.

En septembre 2012, Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS) a reçu une mise à jour contenant les modifications suivantes :

L'entityID publié dans les métadonnées WS-Federation émises par ACS est désormais toujours en minuscules

L'attribut « entityID » dans les métadonnées WS-Federation émises par les espaces de noms Access Control est désormais toujours en minuscules. Dans les versions précédentes, il utilisait la casse entrée lors de la création de l'espace de noms dans le portail Azure. L'attribut « entityID » identifie l'espace de noms Access Control auprès des applications de partie de confiance. Voici un exemple de cet attribut :

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Cette modification était nécessaire pour résoudre les problèmes potentiels de validation de jetons dans lesquels la casse de l'espace de noms Access Control dans le jeton émis par ACS (qui est toujours en minuscules) ne correspond pas à la casse de l'espace de noms Access Control importé par la partie de confiance. Les parties de confiance qui utilisent Windows Identity Foundation ne sont pas concernées par les problèmes de respect de la casse.

Les certificats X.509 téléchargés vers ACS ont désormais une restriction de taille de clé publique de 4096 bits

Tous les certificats X.509 téléchargés vers un espace de noms Access Control via le service de gestion ou le portail de gestion ACS doivent maintenant avoir une taille de clé publique inférieure ou égale à 4096 bits. Cela comprend les certificats utilisés pour la signature de jetons, le chiffrement de jetons et le déchiffrement de jetons.

Dans Windows, vous pouvez vérifier la taille de clé publique d'un certificat en ouvrant le fichier de certificat (.CER), en sélectionnant l'onglet « Détails » et en vérifiant la valeur du champ « Clé publique ». Les certificats qui utilisent l'algorithme de signature sha256RSA sécurisé ont une clé publique de 2048 bits.

Tous les certificats existants ayant une taille de clé supérieure à 4096 bits continueront à fonctionner avec ACS, mais il ne pourront pas être réenregistrés dans ACS tant qu'ils n'auront pas été remplacés par un certificat conforme.

Modification mineure de l'algorithme de sélection de « clé primaire » utilisé quand ACS signe un jeton à l'aide d'un certificat X.509

Dans le service de gestion et le portail de gestion ACS figure un champ « Rendre primaire » pour les certificats de signature de jetons qui, quand vous le sélectionnez, oblige ACS à signer les jetons avec ce certificat. Avec cette version, si le champ « Rendre primaire » n'est activé pour aucun certificat de signature de jetons configuré, l'espace de noms Access Control utilise le certificat de signature de jetons non primaire existant ayant la date de début de validité la plus ancienne pour signer le jeton. ACS ne signe pas les jetons avec un certificat de signature de jetons non primaire s'il existe un certificat primaire qui n'est pas valide ou qui a expiré.

JWT Bêta : modification du comportement de signature lors de l'utilisation d'une clé ou d'un certificat d'espace de noms global pour signer un jeton JWT

Lors de la publication de la prise en charge bêta du format JWT (JSON Web Token) en juin 2012, ACS utilisait l'ordre de priorité suivant pour déterminer la clé à utiliser pour signer chaque jeton JWT délivré à chaque application de partie de confiance :

  • Clé de signature symétrique attribuée à la partie prenante, si elle est disponible

  • Certificat de signature X.509 attribué à la partie prenante, s'il est disponible

  • Clé de signature symétrique attribuée à l'espace de noms Access Control

  • Certificat de signature X.509 attribué à l'espace de noms Access Control

À compter de cette version, les clés symétriques à l'échelle de l'espace de noms ne sont plus prises en charge pour la signature des jetons JWT. Voici le nouvel ordre de priorité pour la signature des jetons JWT :

  • Clé de signature symétrique attribuée à la partie prenante, si elle est disponible

  • Certificat de signature X.509 attribué à la partie prenante, s'il est disponible

  • Certificat de signature X.509 attribué à l'espace de noms Access Control

En juin 2012, ACS a reçu une mise à jour contenant la nouvelle fonctionnalité suivante :

Format JWT désormais disponible pour les applications de partie de confiance (Bêta)

Cette mise à jour introduit la prise en charge du format Bêta JWT (JSON Web Token) dans ACS. JWT est un format de jeton encodé JSON qui peut être signé à l'aide d'une clé symétrique ou d'un certificat X.509 et qui peut être délivré par ACS à des applications de partie de confiance sur les protocoles suivants :

  • OAuth 2.0.

  • WS-Federation

  • WS-Trust

Le format de jeton JWT est désormais une option sélectionnable dans la section Applications de partie de confiance du Portail de gestion ACS et configurable par l'intermédiaire du Service de gestion ACS.

Pour en savoir plus sur le format de jeton JWT, voir la Spécification de jeton web JSON. Des exemples de code ACS avec des jetons JWT seront publiés ultérieurement.

ImportantImportant
La prise en charge de JWT est marquée comme « Bêta » dans ACS, ce qui signifie que tous les détails de l'implémentation JWT sont sujets à modification. Nous encourageons les développeurs à expérimenter avec ce format de jeton. Toutefois, vous ne devez pas utiliser JWT dans les services de production, car le comportement peut changer sans avis préalable.

Début mai 2012, ACS a reçu une mise à jour contenant la modification suivante :

Modification des propriétés d'ID d'entités exposées via le service de gestion

Le service de gestion ACS expose actuellement une propriété d'ID pour chacun des types d'entités qu'il prend en charge, comme décrit dans Référence de l'API du service de gestion ACS. Ces propriétés d'ID sont définies et gérées automatiquement par ACS.

Dans cette mise à jour du service, ACS est migré vers un schéma de base de données différent. En conséquence, ces ID exposés via le service de gestion changent pour tous les types d'entités.

Il est rare et généralement déconseillé que les applications stockent ou aient une dépendance codée en dur envers ces ID pour interroger des entités spécifiques via le service de gestion. Au lieu de cela, nous vous recommandons d'interroger les types d'entités RelyingParty, ServiceIdentity, RuleGroup et Issuer à l'aide de la propriété Name et d'interroger les autres types d'entités à l'aide d'un ID d'entité parente (par exemple RuleGroupId dans le cas de règles ou IssuerId dans le cas de fournisseurs d'identité).

Modification du classement de base de données pour le traitement des règles

Pour étendre la prise en charge des langues internationales et améliorer la sécurité, cette version de ACS met à jour de SQL_Latin1_General_CP1_CI_AS à Latin1_General_100_BIN2 le classement de base de données SQL sous-jacent utilisé pour comparer les revendications d'entrée. Cette modification permet à ACS de prendre en charge des jeux de caractères et des combinaisons de jeux de caractères supplémentaires. Les applications qui reposent sur des revendications d'entrée contenant des chaînes avec plusieurs jeux de caractères non pris en charge par SQL_Latin1_General_CP1_CI_AS peuvent observer des revendications différentes ou supplémentaires suite à ce nouveau classement. Nous encourageons les clients souhaitant tirer parti de cette nouvelle fonctionnalité à valider leurs applications quant à la compatibilité avec le nouveau classement SQL.

Le 5 janvier 2012, ACS 2.0 a reçu une mise à jour contenant les modifications suivantes :

Dans la version précédente, ACS répondait avec des codes d'erreur différents quand un client s'authentifiait avec un émetteur inexistant (code d'erreur : ACS50026) ou des informations d'identification incorrectes (code d'erreur : ACS50006). Ces codes d'erreur étaient précédemment émis quand un client essayait de s'authentifier avec un nom d'identité de service non valide ou à l'aide d'un jeton SWT ou SAML émis par un fournisseur d'identité non valide.

ACS renvoie respectivement les codes d'erreur ACS50008, ACS50009 ou ACS50012 pour un échec d'authentification SWT, SAML et de nom d'utilisateur/mot de passe. Reportez-vous au tableau ci-dessous pour plus d'informations :

 

Réponse d'authentification Avant Après

Émetteur inexistant

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml, OU

ACS50012 AuthenticationFailed

Informations d'identification incorrectes

ACS50006 InvalidSignature

Dans la version précédente, ACS répondait avec des codes d'erreur OAuth 2.0 différents quand un client s'authentifiait avec un émetteur inexistant (invalid_client) ou des informations d'identification incorrectes (invalid_grant). Ce comportement a également été mis à jour et ACS renvoie invalid_request quand la demande OAuth 2.0 est mal formée, invalid_client si l'authentification du client échoue ou si l'assertion fournie pour l'authentification est mal formée ou non valide, et invalid_grant si le code d'autorisation est mal formé ou non valide. Reportez-vous au tableau ci-dessous pour plus d'informations :

 

Réponse d'authentification Exemples Avant Après

Émetteur inexistant

invalid_client

invalid_client

Informations d'identification incorrectes

SWT est signé avec une clé incorrecte. L'ID client et les informations d'identification correspondent à ceux configurés dans ACS.

invalid_grant

Échec d'authentification

Échec de la validation de l'URI d'audience. Échec de la validation du certificat. L'assertion d'une identité de service contient des revendications auto-émises.

invalid_grant

Assertion mal formée

La signature est manquante dans SWT. L'assertion SAML n'est pas du code XML valide.

invalid_request

Code d'autorisation mal formé

invalid_grant

invalid_grant

Code d'autorisation non valide

invalid_grant

Demande OAuth2 mal formée

invalid_request

invalid_request

Les notes de la mise à jour de juillet 2011 d'ACS 2.0 contiennent les éléments suivants :

Tous les espaces de noms Access Control reçoivent automatiquement la mise à jour de juillet 2011. Cette mise à jour ne contient aucune modification des conditions préalables ACS pour les clients nouveaux ou existants. Pour plus d'informations sur les conditions préalables ACS existantes, consultez Configuration requise pour ACS.

La mise à jour de juillet 2011 d'ACS comprend les nouvelles fonctionnalités suivantes :

1. Les règles prennent désormais en charge jusqu'à deux revendications d'entrée

Le moteur de règles ACS prend désormais en charge un nouveau type de règle qui permet de configurer jusqu'à deux revendications d'entrée au lieu d'une seule. Vous pouvez utiliser des règles avec deux revendications d'entrée pour réduire le nombre global de règles nécessaires pour effectuer des fonctions d'autorisation utilisateur complexes.

Dans le portail de gestion ACS, vous pouvez spécifier une seconde revendication d'entrée dans une nouvelle règle en cliquant sur Ajouter une seconde revendication d'entrée dans l'éditeur de règles. Dans le service de gestion, vous pouvez configurer des règles avec deux revendications d'entrée à l'aide du type d'entité ConditionalRule. Vous pouvez toujours configurer des règles avec une seule revendication d'entrée à l'aide du type d'entité Règle à des fins de compatibilité descendante.

Pour plus d'informations sur les règles avec deux revendications d'entrée, consultez Règles et groupes de règles.

2. Localisation dans 11 langues

Le portail de gestion ACS et la page de connexion ACS pour les applications de partie de confiance prennent en charge la localisation dans onze langues : anglais, français, allemand, italien, japonais, coréen, russe, espagnol, portugais (Brésil), chinois simplifié et chinois traditionnel. Une option « Anglais (International) » est également disponible ; elle utilise un autre format de date pour la définition et l'affichage des dates d'entrée en vigueur/d'expiration pour les clés. La langue affichée pour ces interfaces utilisateur peut être modifiée de trois façons :

  • Sélecteur de langue : dans le portail de gestion ACS, vous pouvez modifier instantanément la langue affichée à l'aide d'un nouveau menu de sélecteur de langue qui s'affiche dans le coin supérieur droit du portail.

  • URL : vous pouvez modifier la langue affichée dans le portail de gestion ACS en ajoutant un paramètre « lang » à la fin de l'URL demandée. Les valeurs correctes pour ce paramètre sont les codes de langue ISO 639-1/3166 qui correspondent à une langue prise en charge. Exemples de valeur : en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn, et zh-tw. Vous trouverez ci-dessous un exemple d'URL du portail de gestion ACS avec un paramètre qui définit le français comme langue affichée :

    https://your-namespace.accesscontrol.windows.net/?lang=fr

  • Préférences du navigateur web : si le paramètre « lang » ou le sélecteur de langue n'ont pas été utilisés pour définir une préférence de langue, le portail de gestion ACS et les pages de connexion hébergées par ACS déterminent la langue par défaut à afficher en fonction des préférences de langue définies dans les paramètres du navigateur web.

Voici une liste des principales modifications de comportement de service dans cette version :

1. L'encodage est désormais UTF-8 pour toutes les réponses OAuth 2.0

Dans la version initiale d'ACS, le jeu d'encodage de caractères pour toutes les réponses HTTP à partir du point de terminaison OAuth 2 était US-ASCII. Dans la mise à jour de juillet 2011, l'encodage de caractères de toutes les réponses HTTP est maintenant défini sur UTF-8 pour prendre en charge les jeux de caractères étendus.

Le problème suivant est connu dans cette version :

L'éditeur de règles ne peut pas afficher les émetteurs personnalisés qui ne sont pas associés à des fournisseurs d'identité

Actuellement, l'éditeur de règles du portail de gestion ACS peut afficher uniquement les émetteurs de revendications associés à un fournisseur d'identité ou à ACS. Si une règle chargée fait référence à un émetteur qui ne correspond pas à l'un de ces critères, l'erreur suivante est affichée :

  • ACS80001 : Cette règle est configurée pour utiliser un type d'émetteur de revendication non pris en charge par le portail de gestion. Utilisez le service de gestion pour afficher et modifier cette règle.

Il existe deux scénarios pris en charge dans lesquels un émetteur peut exister sans être associé à un fournisseur d'identité dans ACS :

  • Dans un scénario de délégation OAuth 2.0, un enregistrement d'émetteur est créé dans l'espace de noms Access Control à l'aide du service de gestion ACS, et cet émetteur n'est associé à aucun fournisseur d'identité.

  • Quand un émetteur est créé pour les besoins de l'assertion de revendications dans une demande de jetons sur le protocole OAuth WRAP et qu'une identité de service du même nom est utilisée pour l'authentification auprès d'ACS.

À compter de cette version, ACS n'impose aucune limite quant au nombre de fournisseurs d'identité, applications de partie de confiance, groupes de règles, règles, identités de service, types de revendications, enregistrements de délégation, émetteurs, clés et adresses pouvant être créés pour un espace de noms Access Control.

Pour plus d'informations sur les limitations de service, consultez Limitations du service ACS.

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2015 Microsoft