Today we're proud to announce the Microsoft Information Protection SDK Preview!
The Microsoft Information Protection SDK (MIP SDK) brings the classification, labeling, and protection capabilities of Azure Information Protection and Office 365 Security and Compliance Center in to a simple, lightweight, cross-platform software development kit that enables any application to read and apply MIP labels and protection.
In this release, we’re providing our first look at the components of the SDK and how your organization will be able to use each of them to make your own applications Microsoft Information Protection enabled and fully aware.
Back in February, over on the Enterprise Mobility + Security blog, we revealed details on the Microsoft Information Protection story and the work we’re doing to bring together Azure Information Protection and Office 365 labeling via Security and Compliance Center.
It's likely that if you're an existing Office 365 or Azure Information Protection user, you're familiar with Security and Compliance Center (above) and/or the AIP labeling bar (below).
Microsoft Information Protection is the combination of AIP and the O365 labeling in Security and Compliance center, and the future integration around the labeling experience that will come as part of O365 and EMS. The videos below cover some of the changes we’re making as we work toward this goal.
Azure Information Protection: Unified labeling, on-prem scanning and protection across platforms
Preparing for GDPR: Compliance management and information protection capabilities in Microsoft 365
As the classification, labeling, and protection experience becomes native across the Office 365 experience, your organization and users will begin to demand that the ease-of-use they experience in their Office applications and services carry over to 3rd party and line-of-business applications. As our customers and partners, you’ll be able to use the MIP SDK to make classification, labeling, and protection in these applications easier than ever.
The MIP SDK is made up of three separate APIs: File API, Policy API, and Protection API.
The Policy API exists to allow developers to perform label-driven actions in their applications. The typical consumer of this API will be an application owner. This API doesn’t apply a label to a document or take any action at all. Rather, it informs the application of the available labels for the current user and what actions should be taken when that label is applied. It’s up to the software engineer to code the appropriate behavior in the application and to write those changes to the output file.
For example, if I’m a software developer at a company writing a CAD/CAM application, I would leverage the Policy API to:
The Protection API enables developers to read and write Azure Information Protection rights-managed streams. The API can be used to read encrypted input and decrypt to reason over the contents in plaintext, or to take plaintext output from a system and encrypt it in an AIP rights-managed format.
We believe that organizations using RMS SDK 2.1 or 4.2 will be able to fully replace that functionality with the Protection API capabilities from the MIP SDK.
Last, but certainly not least, is the File API. The file API provides an easy-to-use method of performing several file related tasks for well-known file formats. By simply passing in a label ID, the API can apply a label, content marking, and protection to a list of supported formats. Additionally, labels can be fetched from the service, read from a file, deleted or changed, and justification provided when downgrading the label.
The File API isn’t truly independent. Rather, it provides an abstraction of the previous APIs so that developers don’t need to worry about handling policy actions or protection actions; the File API, based on the labels that are present, knows exactly what to apply and how to apply it to the supported file types.
Before embarking on any journey with a new SDK, we understand that it’s important to have solid use cases and business justification. We’ve been mulling over the various use cases for the SDK for quite a long time. You’ll be able to use some of our ideas below to kickstart discussions in your own business.
From the standpoint or Microsoft and the MIP SDK team, our #1 goal with the SDK is this:
The Microsoft Information Protection SDK will enable our third-party ISV ecosystem to build native support for MIP classification, labeling, and protection in to their applications.
One of the most common questions we hear on the Information Protection teams is:
“When will Microsoft support application or service X with MIP?”
It’s extraordinarily difficult to build a solution that works across many applications, in a scalable, fast, user friendly, and most important, transparent manner. We believe that the best MIP CLP experience is a native application experience. We’ll be announcing several partnerships with security ISVs this week at RSA Conference and as we approach GA. These partners are already committed to building support for MIP in to their applications and services.
We believe that, for most tasks, organizations will build functionality that leverages the File API. Because the API can be used to read, apply, or remove labels and protection, without having to worry about modifying the file contents in your own code, it’ll be the simplest, most common approach to using the SDK. Here are some examples of File API use cases:
The Policy API provides functionality that allows application developers to expose to their applications the labels that are available within a tenant and to compute the actions that the label should take. Everything that comes after, applying marking, metadata, protection, etc. is up to the developer to implement. Examples of some policy API use cases are:
The preview release of the SDK can be found here: https://aka.ms/mipsdkbinaries
Inside the ZIP file, you’ll find:
Our next posts will dive more in to the fundamentals of the SDK from a developer’s point of view, as well as in to our sample and tutorial code. In the meantime, if you're looking to get started with writing your own C++ app with the SDK, you'll need to obtain a user identity from one of our test tenants that has the necessary Security and Compliance Center flights enabled. Some items to note:
If you’re interested in getting started with the sample apps and starting to build your own integration, please fill out this form to start the process. We reply with an account within two business days (Future Note: This process will only exist until the necessary service components are in public preview).
Kartik and I are both at RSAC this week, so if you have questions, want to see a demo, or just want one of our new stickers, stop by the Microsoft Information Protection booth in the expo!
Tom Moser, @milt0r, Sr. Program Manager – Azure Information Protection
Kartik Kanakasabesan, @kkanakas , Principal Program Manager – Azure Information Protection
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.