Kategorie: Microsoft Azure

Azure Media Services announces support for AAD and deprecation of ACS authentication

This month we are announcing the release of support for Azure Active Directory (AAD) authentication in Azure Media Services. Customers of our REST API and .NET client libraries can now use AAD authentication to authorize requests. In addition, we are releasing a new management blade in the Azure Portal to simplify the usage of User and Service Principal authentication with AAD. With the release of this update to our REST API, we are now able to provide the same role-based access management (RBAC) as provided by the Azure Resource Management (ARM) service. By moving to AAD authentication you will also now be able to track and audit all changes made by specific users or an application connected to your Media Services account. The new Azure Media REST API requires that the user or application making REST API requests must have either contributor or owner level access to the resources it is attempting to manage. More details on how role-based access control works for Azure resources is available at Azure Role-based Access Control. IMPORTANT! 12-month deprecation notice of ACS authentication support in Azure Media Services Because Azure Active Directory provides powerful role-based access control features and support for more fine-grained access to resources in your account compared to the ACS token authentication model (“account keys”), we strongly recommend that you update your code and migrate from ACS to AAD-based authentication by June 22, 2018. Also, a key reason for the rapid migration is the upcoming announced deprecation of the ACS key based authentication system. What does this mean for you? Microsoft Azure Media Services will end support for Microsoft Azure Access Control Service (ACS)-based authentication on June 22, 2018. To provide customers sufficient time to update their application code, we are providing 12 months’ notice to manage the necessary transition. What actions should you take? We recommend that you take the following actions prior to June 22, 2018 to ensure that your applications continue to work as expected: Update the code for your applications authored for Media Services. Migrate from ACS-based authentication. Begin using AAD-based authentication. Mitigation steps must be taken on or before June 22, 2018 to ensure your applications authored for Media Services using ACS authentication tokens will continue to function as expected without failures in production. Please review each of the new authentication scenarios below closely and take the appropriate action to update to using AAD authentication in your source code. The Azure Media Services REST API supports authentication for both interactive users and web API, middle-tier, or daemon applications. The following sections provide details on how to use AAD authentication when working directly with the REST API or through the .NET client library. User Authentication with AAD in Media Services If you are looking to build a management application for your Azure Media Services account like the Azure Media Services Explorer tool, you can simply login with a User’s credentials that has been granted access to the Media Services Resource in the portal via the Access Control (IAM) blade. This type of solution is very useful when you want human interaction with the service that fits one of the following scenarios: Monitoring dashboard for your Encoding jobs Monitoring dashboard for your Live Streams Management application for desktop or mobile users to administer resources in a Media services account. A native application would first acquire an access token from Azure Active Directory and then use that access token to make all REST API calls. The following diagram shows a typical interactive application authentication flow. For a RESTAPI request to succeed, the calling user must be a “Contributor” or “Owner” of the Azure Media Services account it is trying to access. Unauthorized requests would fail with status code 401. If you see this failure, please double check that you have configured your user as “Contributor” or “Owner” on the Media Services account. You can check this through the Azure portal by searching for your media account and clicking on “Access control” tab. Users of the .NET client SDK for Media Services must upgrade to the latest version on Nuget (windowsazure.mediaservices version 4.0.0.4 or greater) to use AAD authentication for communicating with REST requests. The following example shows the differences between how to authenticate with the .NET client SDK previously using ACS and the new way that uses AAD credentials. NOTE: Applications will also need to update their references to include a new assembly “Microsoft.WindowsAzure.MediaServices.Client.Common.Authentication.dll” and add references to that namespace as well as reference to the “Microsoft.IdentityModel.Clients.ActiveDirectory” assembly to get access to the ITokenProvider interface. For more information and a detailed sample on using the .NET SDK with AAD see this overview and the available environment settings and constants.   DEPRECATED method of authenticating using ACS credentials // Create and cache Media Services credentials in a static class variable.
_cachedCredentials = new MediaServicesCredentials(
_mediaServicesAccountName,
_mediaServicesAccountKey,
“urn:windowsazuremediaservices”,
“https://wamsprodglobal001acs.accesscontrol.windows.net”);

// Used the cached credentials to create CloudMediaContext.
var mediaContext = new CloudMediaContext(_cachedCredentials);
mediaContext.Assets.FirstOrDefault();
New method of authenticating using AAD credentials and User authenticationvar tokenCredentials = new AzureAdTokenCredentials(“{YOUR AAD TENANT DOMAIN HERE}”, AzureEnvironments.AzureCloudEnvironment);
var tokenProvider = new AzureAdTokenProvider(tokenCredentials);
var mediaContext = new CloudMediaContext(new Uri(“YOUR REST API ENDPOINT HERE”), tokenProvider);
mediaContext.Assets.FirstOrDefault() // This would return a 401 unauthorized if you are not set up as an authorized user

The “AzureEnvironments.AzureCloudEnvironment” constant is a helper in the .NET SDK to get the right environment variable settings for a public Azure Data Center. It contains pre-defined environment settings for accessing Media Services in the public data centers only. For sovereign or government cloud regions, you can use the ” AzureChinaCloudEnvironment”, “AzureUsGovernmentEnvrionment”, or “AzureGermanCloudEnvironment” respectively.
A lot of the details regarding acquiring an AAD access token has been wrapped and simplified for you in the AzureAdTokenProvider and AzureAdTokenCredentials classes. For example, you do not need to provide the AAD authority, Media services Resource URI or native AAD application details. These are well known values that are already configured by the AAD access token provider class. If you are not using our .NET client SDK, it is recommended to use the ADAL Library to simplify the creation of the access token request using these parameters. The following values are used by default in the AzureAdTokenProvider and AzureAdTokenCredentials classes.
You also have the option of replacing the default implementation of the AzureAdTokenProvider with your own implementation.
AAD Service Principal Authentication in Media Services
For non-human interaction through daemon services, Web APIs, Consumer (mobile or desktop), and Web application, where interactive login or direct user management/monitoring of resources in the Media Services account is not required, you will need to first create an Azure Active Directory application in its own tenant.
Once it is created, you will have to give this application “Contributor” or “Owner” level access to the Media Services account in the Access Control (IAM) blade. Both steps can easily be done through the Azure Portal or through the Azure CLI, or PowerShell script. Note that for AAD resources, “Contributor” has the same access to the resource as “Owner” but only the “Owner” role can grant access to other users. Currently this version of the Media Services REST API does not provide RBAC at the entity level, but that is something we have on the roadmap for our future API update in the Fall. We have also provided the new “API Access” blade in your Media Services account to make it easy to generate the required application or select from an existing one.  If you would like to use x509 certificates instead or ClientID and ClientKey, you can reference the documentation for details on how to configure the SDK
The following examples show how a daemon application may use AAD web application credentials to authenticate requests with the REST service.

Deprecated way of authenticating using ACS credentials // Create and cache Media Services credentials in a static class variable.
_cachedCredentials = new MediaServicesCredentials(
_mediaServicesAccountName,
_mediaServicesAccountKey,
“urn:windowsazuremediaservices”,
“https://wamsprodglobal001acs.accesscontrol.windows.net”);

// Used the cached credentials to create CloudMediaContext.
var mediaContext = new CloudMediaContext(_cachedCredentials);

New way of authenticating with an AAD Service Principal and client symmetric keyvar tokenCredentials = new AzureAdTokenCredentials(“{YOUR AAD TENANT DOMAIN HERE}”, new AzureAdClientSymmetricKey(“{YOUR CLIENT ID HERE}”, “{YOUR CLIENT SECRET}”), AzureEnvironments.AzureCloudEnvironment);
var tokenProvider = new AzureAdTokenProvider(tokenCredentials);

var mediaContext = new CloudMediaContext(_mediaServicesApiServerUri, tokenProvider);mediaContext.Assets.FirstOrDefault();

Making it easy to get started with the new API Access Blade for Media Services
Azure Active Directory authentication could be complex for users unfamiliar with the details of AAD, so we wanted to make it very easy to get started with very little knowledge of AAD. For that reason, we are introducing a new “API Access” blade for Media Services accounts in the portal that will replace the previous ACS “Account keys” blade. We are also disabling the ability to rotate the ACS keys to promote users to update their code and move to AAD support.
The new API Access blade makes the process of connecting to Azure Media Services with AAD much simpler. When you first select the API Access blade, you will be presented with a choice of using either user authentication for human interactive management applications, or creating a Service Principal and AAD application for non-human interaction with the Media Services API.
 
When selecting the user based authentication option, you will see a new panel that contains all the Active Directory information needed to authenticate with the API. This includes the API endpoint that you need to call, along with the ClientID, Domain, and Resource.
 
For Service Principal authentication, you will see additional values and the ability to select from an existing AAD Application or create a new one directly in the panel.

When the Service Principal blade opens, it selects the first AAD application that meets the following criteria:

It is a registered AAD application
It has “Contributor” or “Owner” RBAC permissions on the account
After creating or selecting an AAD app, you will be able to create and copy a Key (Client Secret) and copy the Client ID (Application ID) which are required to get the access token in this scenario. In the blade, you can choose to “Create New” AAD Application, or select from an Existing one in your Subscription.  When selecting an existing one, you will see a new blade listing your existing applications to choose from.

Once you select from an existing application or create a new one, you will see additional buttons to “Manage Permissions” or “Manage Application”.  You can use these settings to open the AAD application management blade directly to perform management tasks such as changing keys or reply URL, or customizing the applications manifest.
Clicking on the Manage Application button will bring up the AAD application management blade which allow you to create Keys for use with the API using this application.

If you do not have permissions to create AAD apps in your Domain, the AAD app controls of the blade are not shown and a warning message is shown instead.
  Next Steps and Actions for Media Services Customers
We are very excited to be making the transition from the older ACS key based authentication to the more secure, flexible, and role-based Azure Active Directory service. All Azure Media Services customers should begin immediately to migrate to use the new AAD based authentication model by downloading the latest .NET SDK, or updating their existing REST based API calls.
In addition, we are working on a new version of our REST APIs with support for more client SDK languages with AAD authentication. More details on that updated API will come in a later blog post.
The key actions you should be taking today:

If you are using .NET, update to the latest SDK and migrate to AAD authentication.
Plan early for the deprecation of ACS authentication support in Media Services API. The older ACS authentication support will be shutting off officially on June 22, 2018.
Note on Java SDK and Open Source and Community driven client SDKs
If you are currently using the Java SDK or one of the many community or open source generated client SDKs for Media Services, you have a couple of options at this time.  The existing Java SDK for Media Services will be updated in the coming months to support AAD authentication for customers to immediately begin migration to.  For the open source libraries, since these are not supported directly by the Media Services team, you would need to work with the community SDK developer to prioritize updating the SDK to support AAD for your scenario. We also recommend that you stick with the community SDK a little longer, as we reach out to the developers and work with them to update their libraries.  In addition, we are working hard on an updated REST API (v3) that is coming out later this Fall with support for AutoRest generated client SDKs across PHP, Java, Python, and more which will support AAD authentication. We will be following up with more blog posts on migrating to the new v3 API and client SDKs when they are ready for preview.
Resources and Additional Documentation
For more details, sample code and specific scenario documentation, please refer to the following articles:

Use AAD auth to access the API
Use the Azure Portal to Manage AAD Auth
Access the Media Services API with .NET and AAD
Use the Azure CLI 2.0 to create and configure an AAD app
Use PowerShell to create and configure an AAD app 
Contact Us with Questions
As always, if you have any questions, comments, or feedback, please post a message or question to our MSDN Forum or use Stack Overflow. For direct support, please submit a support request through the Azure Portal. We are also available on Twitter via @MSFTAzureMedia.
Quelle: Azure

Building an Azure Analysis Services Model for Azure Blobs — Part 3

The third and final part of the article series “Building an Azure Analysis Services Model on Top of Azure Blob Storage” has been published on the Analysis Services team blog. It shows that an Azure Analysis Services S9 server can successfully ingest more than 1,000 source files in a 1-terabyte TPC-DS data set stored in Azure Blob Storage in less than 12 hours. Among other things, Part 3 demonstrates how to analyze the memory consumption of the model and how to optimize model size and processing times. This part also discusses the advantages of more sophisticated data sources, such as Azure SQL Data Warehouse, over Azure Blob Storage for reducing the data volume that must be transferred to Azure Analysis Services for processing. Thanks to the modern Get Data experience, you can build a flexible data import pipeline directly in a Tabular model and import even very large data sets with reasonable processing times.

Read the full article “Building an Azure Analysis Services Model on Top of Azure Blob Storage”.
Quelle: Azure

ASOS: How they migrated from local monolith to microservices in Azure

Today we are kicking of a new series on Microsoft Mechanics called "How we built it" to share the real-world architectural back stories and best practices as told by the technology architects in our customer organizations.

We kick off the series with lead architect, Dave Green, from British online fashion retailer ASOS, to take a closer look at their design goals and approach for moving from a locally-operated monolith to a fully architected built-for-Cloud online retail system.

Breaking down the monolith

Founded almost two decades ago, ASOS was ahead of its time establishing a fully-online retail presence. The company has a growing customer base of 14 million customers, spanning 230 countries worldwide. Their exponential growth resulted in the need to move beyond a single currency and support multiple languages.

This meant building in more agility, scale and efficiency into their tech architecture. Rather than perform a lift and shift migration, the team decided to adopt a cloud-native, microservices architecture from scratch for faster iteration and release of new features.

Then they set to work breaking down their monolithic retail app which comprised stateful, intertwined services into core microservices, swapping out functions from the monolith piece-by-piece.

As Dave Green explains, core to their approach was the decoupling of their presentation layer from their compute layer. This gave them more freedom to easily add or change features and scale their developer teams to work on multiple features at once. Further, as each service maintains its own state and data, this made it easier to scale the data layer and compute layer independently.

Multi-geo footprint and performance

Breaking down the monolith and moving core services to the Cloud also enabled them to architect for greater performance and resiliency for their global customer base. This included geo-redundancy across North and West EU regions, where most of their customers reside with a handful of core services sensitive to latency, running in Asian and North American regions.

The combined approach with Cloud microservices, paid off on some of their busiest shopping days. This includes Black Friday, where they saw an increase in peak order handling from 9 orders per second using their original monolith retail system to 33 orders per seconds with their Cloud microservices architected system.

To learn more, watch Dave Green's account on "How we built it." You can also join Dave and the ASOS team, on June 29th at 9am PDT for their AMA session on the Microsoft Tech Community at http://aka.ms/how-we-built-it-ASOS.
Quelle: Azure

Managing updates for your Azure VM

In this blog post, I will talk about how to use Update Management solution to manage updates for your Azure VMs. Right from within your Azure VM you can quickly assess the status of available updates, initiate the process of installing required updates, and review deployment results to verify that updates were applied successfully to the VM.

This feature is currently in private preview. If you’re interested in giving it a try, please sign up!

Enabling Update Management

From your VM, you can select “Manage Updates” on the virtual machines blade, under Automation + Control. After selecting it, validation is performed to determine if the Update Management solution is enabled for this VM. If it is not enabled, you will have the option to enable the solution.

The solution enablement process can take up to 15 minutes, and during this time you should not close the browser window. Once the solution is enabled and log data starts to flow to the workspace, it can take more than 30 minutes for data to be available for analysis in the dashboard described in the next section. We expect this timing to significantly improve in the future.

Review update assessment

From the Manage Updates dashboard, you can review the update compliance state of the VM from the Missing updates by severity tile, which displays a count and graphical representation of the number of updates missing on the VM. The table below shows how the tile categorizes the updates missing by update classification.

To create an update deployment and bring the VM into compliance, you configure a deployment that follows your release schedule and service window. This entails what update types to include in the deployment, such as only critical or security updates, or if you want to exclude certain updates.

Create a new Update Deployment for the VM by clicking the “Schedule deployment for this VM” button at the top of the blade and specify the required values. 

After you have completed configuring the schedule, click the “OK” button and you return to the status dashboard. You will notice that the Scheduled table shows the deployment schedule you just created.

View update deployment state

When the scheduled deployment executes, you see the status appear for that deployment under the Completed and in-progress table. Double-clicking the completed update deployment takes you to the detailed deployment status page.

To review all detailed activities performed as part of the update deployment, select “All Logs and Output tiles”. This will show the job stream of the runbook responsible for managing the update deployment on the target VM.

OS support

Windows: Windows 2012 and above
Linux: RedHat Linux 6 & 7, Ubuntu Server 12.04 LTS, 14.04 LTS, 15.10, and 16.04

New to OMS Update Management

If you are new to OMS Update Management, you can view the current capabilities which include Update Insights across Windows and Linux, and the ability to deploy updates, as well as documentation.

In future posts, I’ll talk about how to manage updates for multiple VMs in your subscription and how to orchestrate the update deployments including running pre/post steps, sequencing, and much more!
Quelle: Azure

Enable client side monitoring in Azure with Application Insights

With the Application Insights JavaScript SDK you can collect and investigate the performance and usage of your web page or app. Historically we have offered onboarding through manually adding a script to your application and redeploying. Manually adding the script is still supported, but recently we have added the ability to add client-side monitoring from the Azure portal in a few clicks as well.

Enablement

If you have enabled Application Insights in Azure, you can add page view and user telemetry. You can learn how to switch on server-side monitoring in our documentation.

     1. Select Settings -> Application Settings

     2. Under App Settings, add a new key value pair:

Key: APPINSIGHTS_JAVASCRIPT_ENABLED

Value: true

     3. Save the settings and Restart your app in the Overview tab.

The Application Insights JavaScript SDK is now injected into each web page.

Feedback

If you have any questions or experiencing any problems with the JavaScript SDK, feel free to open an issue on GitHub.
Quelle: Azure

GDPR Questions? Azure has answers.

Microsoft is here to help

Please have a look at our white paper How Microsoft Azure Can Help Organizations Become Compliant with the EU General Data Protection Regulation to gain an understanding of how your organization can use currently available features in Azure to optimize your preparation for GDPR compliance. We are here to help you with your compliance efforts in the face of the coming EU law.

May 25, 2018: a new era begins for data privacy

On this date in a little less than a year, the new European Union (EU) data protection law will be implemented, replacing the old Data Protection Directive, which has been in effect since 1995. The new law, known as the General Data Protection Regulation (GDPR), gives individuals greater control over their personal data and imposes many new obligations on organizations that collect, handle, or analyze personal data.

This is what we do

Azure has developed a tradition of compliance which gives our customers the tools they need to comply with complex regulations. Our attention to, and preparation for the impact of GDPR continues to show how we equally prioritize the best cloud technology with the best compliance offerings.

Additional information about how Microsoft helps you to fulfill specific GDPR requirements are available at the GDPR section of our Microsoft Trust Center.
Quelle: Azure