This post has been republished via RSS; it originally appeared at: Microsoft Information Protection Developers articles.
Now Available: Microsoft Information Protection SDK 1.3!
We're pleased to announce that the Microsoft Information Protection SDK version 1.3 is now generally available via NuGet and Download Center. We've added several new features to this release as well as performance and API improvements.
- Decryption of protected MSG files is now supported.
- Inspection of message.rpmsg files is supported via
- On-disk cache may now be optionally encrypted.
- Protection API now supports China sovereign cloud.
- Arm64 support on Android.
- Arm64e support on iOS.
- End user license (EUL) cache can now be disabled.
- .pfile encryption may be disabled via
- Improved performance for protection operations by reducing number of HTTP calls
New in version 1.3 is the
MipContext is now the highest-level object in MIP SDK and spans all profiles for the life for the application. The
MipContext object is created and passed in to the various profile types. Here's an example for
MipContext has information about the application, cache storage path, and, optionally, logger and telemetry overrides. The object is passed in to the
FileProfile::Settings constructor and then the profile is loaded. For details, visit our updated samples on GitHub.
The existing APIs will remain in place but have been marked as deprecated. They will be removed in the next version of the SDK.
Cache Storage Encryption
Previous versions, when creating a profile, had a bool parameter to specific whether storage was in memory or not. False indicated that state would be stored on disk. New in 1.3, we've removed this parameter and replaced it with
mip::CacheStorageType. The cache storage can be OnDisk, InMemory, or OnDiskEncrypted.
When the type is set to OnDiskEncrypted, all policy and license information in the state databases are encrypted via locally available crytographic APIs. This encryption makes database tampering and browsing more difficult.
For full details on cache storage, including this new encryption feature, check out the cache storage concepts page on Microsoft Docs.
Across the SDK, we've decoupled on-behalf-of operations from the
In previous versions of the SDK, if your application needed to perform an operation on behalf of the user, that delegated identity was required to have been set as a property of the
mip::Identity was provided to the Engine for each of the three APIs, and all operations that engine performed were performed on behalf of that delegated user. Based on feedback from customers around the performance of that pattern, we've removed the delegated identity details from
mip::Identity and instead added
A File API example of this in C# looks like:
This new model helps to reduce round-trip times to the service involved in setup of new engine objects.
Label ID is now
Functions that previously accepted a label identifier as an input now require a
mip::Label object instead. Making this change in your application, in most cases, should be trivial and can be accomplished via
In addition to
SetLabel(), the following APIs use
mip::Label instead of label ID.
mip::ApplyLabelAction::GetLabel- Previously GetLabelId
mip::RecommendLabelAction::GetLabel- Previously GetLabelId.
mip::ExecutionState::GetNewLabel- Previously GetNewLabelId.
- In previous versions, we required that you called
mip::ReleaseAllResources. Version 1.3 replaces this with
mip::PublishingLicenseInfoand updated to contain rich fields instead of raw serialized bytes.
mip::PublishingLicenseInfocontains the data relevant to MIP after parsing a publishing license (PL).
mip::LabelNotFoundErrorthrown when application passes MIP a template ID or label ID that is not recognized.
- Added support for label-based conditional access via the claims parameter of
mip::AuthDelegate::OAuth2Challenge(). This functionality hasn't yet been exposed via the Security and Compliance Center portal, but we will share details as soon as the settings are available.