We're excited to announce two new releases this week. Our regularly-scheduled quarterly release of the Microsoft Information Protection SDK is now available. In this 1.4 release, we've shipped several updates that you can read about below.
We've also made available a subset of Microsoft Information Protection SDK functionality in Microsoft Graph. We've reduced the overhead of taking the full SDK for apps that require only label policy information or to compute actions for a specific label.
A common request that we've heard from our partners is:
"We need a REST API to fetch the label policy and evaluate labeling actions."
Reasons for this request vary, but have fallen in to two primary buckets: Making REST calls to Graph is easier than integrating the entire policy SDK, or we simply didn't have support for the language or platform that the partner or customer required (Java, for example).
Now available this week in Microsoft Graph Beta, your applications can make REST calls to perform the following policy operations:
- List all labels
- Fetch information about a specific label
- Get a list of actions that should be taken to apply a specific label
- Resolve sensitive information types to a label and the actions to take to label.
- Pass in existing content metadata, return actions to remove label.
- Pass in existing content metadata, return details from service about the label.
Get started with our beta today at Graph Explorer and by reviewing our Graph docs.
Later this week, we'll dive deeper into how to use the API in your own applications. We're eager to get your feedback on the existing beta, and to hear about other functionality you'd like to see us expose via Graph.
New in MIP SDK 1.4
Over the last three months, we've focused primarily on improving our story for protected, or protecting, email. We've completed a great deal of work that enables decryption of most types of encrypted mail, regardless of encoding or attachments. We've heard from customers and partners that this is especially important for DLP inspection, eDiscovery, and journaling.
We've also invested in encrypting of MSG files. By passing in a plaintext MSG file to the File API with some label or protection information, you get the protected file as output. The primary use case for this scenario is protecting messages at creation from line-of-business applications, or mail gateway products that may need to decrypt, append data, and re-apply protection.
MIP SDK 1.4 Change Summary
-
All SDKs
- Various performance improvements and bug fixes
StorageType is now CacheStorageType- APIs deprecated in 1.3 have been removed.
- All profiles must be initialized with MipContext
- Settings path, application info, logger delegate, and telemetry/log level getters/setters are removed and now in MipContext.
- Better static library support on Apple platforms
- Merged mip_telemetry.dll in to mip_core.dll
-
File SDK
- Protected email support
- The SDK now supports applying protection to plaintext MSG files.
- Added support for decryption of string8 messages.
- PFILE extension behavior is configurable via
ProtectionSettings::SetPFileExtensionBehavior
- Default is that .TXT becomes .PTXT (applies to any supported extension)
- Can be configured to create .TXT.PFILE instead.
-
Policy SDK
- C API is now available.
- HYOK labels can be filtered via
PolicyEngine::Settings::SetLabelFilter()
-
Protection SDK
- Now available in .NET package!
- Package is monolithic and included in Microsoft.InformationProtection.File package.
- Removed deprecated APIs
- Added new APIs for creating protection handlers.
ProtectionEngine::CreateProtectionHandlerForPublishing() should be used to create publishing handlers.ProtectionEngine::CreateProtectionHandlerForConsumption() should be used to create consumption handlers.
- Completed work on the C API.
Resources
