In previous articles of these series, we first looked at the various methods we could use to extend the Azure AD directory schema. After this trip down memory lane, we then continued with a not-so-short introduction to custom security attributes, a great new functionality designed to address some of the shortcomings of existing solutions. We covered their creation, assignment and even mentioned few limitations. Now, we are finally at a point when we can compare them against all the “older” methods. We have already hinted that custom security attributes are what Microsoft envisions as the way forward, so are they a better option?
Generally speaking, yes. There are few caveats though, starting from the fact that they are currently only available as preview. You might as well wait for Microsoft to enhance their functionality and fix some underlying issues, before releasing them in GA. Still, even in their current version custom security attributes offer some benefits compared to other methods:
- A robust permissions model. The set of newly introduced Azure AD admin roles and Graph API permissions allow you to delegate management and use of custom security attributes on a granular level. With most other methods, everyone in the directory could either read or set values for all extension attributes, in an “all or nothing” approach. Read-only scopes for programmatic access via the Graph API was added in early February, although only the delegate permissions can be scoped to specific attribute sets.
- Enable ABAC for Azure resources. Attribute-based access control is another preview functionality, which expands on the granularity of RBAC by leveraging attribute-level values. For example, you can define a role assignment that grants access to all Azure storage blobs associated with a given Project name. You can then define a custom security attribute to store all the Projects on which users work, and use the corresponding values in combination with the condition set on the blob layer.
- Can be used as confidential attributes. As another example of an authorization-based scenario enabled by custom security attributes, you can store sensitive information, such as user’s pay grade within the directory, while ensuring that only authorized personal can read the data. By default, every user within the directory can fire up PowerShell or even open the Azure AD blade to read objects and their properties. While certain controls exist to limit such access, this makes other extension types an inappropriate choice for authorization-based scenarios. Custom security attributes are a much better solution, thanks to the robust permissions model.
- No dependence on application registration. Apart from removing any additional overhead related to managing the corresponding application/service principal object, this also means that custom security attributes do not suffer from the same naming schema limitations such as other methods, such as directory schema extensions. And of course, their lifecycle is not tied to the lifecycle of any application object.
- Discoverability. Being able to list all directory extensions defined within the directory and their values has been a challenge for some of the older methods. With custom security attributes, you can use a single, standardized Graph API query to fetch all attribute sets and definitions. Equally important, results will be trimmed based on your permissions within the directory!
- Data types and validation. With out of the box support for several data types, support for multiple-valued attributes and pre-defined values to select from, custom security attributes address most data validation scenarios. Both the UI and API enforce the requirements defined as part of the custom security attribute creation process, greatly simplifying maintenance tasks. But a solid plan is required from the get-go, as mistakes will often force you to start from scratch.
- Support across Azure AD. While still in their infancy, custom security attributes are already supported in parts of the Azure AD UI, which cannot be said for some of the other extension attribute types. Most other methods only expose extension attributes and their values as part of the Graph, which can be limiting. Custom security attributes show quite the promise in this regard. Going forward, we can expect other functionalities to integrate with custom security attributes, perhaps even the Microsoft 365 Admin Center?
- Naming schema. It is worth re-iterating that custom security attributes have relaxed naming requirements and no dependence on any application object/ID. Although you cannot use arbitrary values and their “fully qualified” name is in the form of setName_attributeName, the prefix is not exposed anywhere in the UI and for all intents or purposes you can have simple, descriptive names such as “SSN” or “ProjectName”.
In other areas, additional improvements will be needed:
- Preview functionality. While all of the above might sound great, keep in mind that custom security attributes are still in preview, so the occasional issue can be expected. On the other hand, this will guarantee that the functionality will receive future feature updates, unlike most of the other methods where development has long ago stagnated.
- Missing functionalities. As already mentioned, custom security attributes currently do not support object types such as groups, applications or devices. No delete operations are supported either, which has the unfortunate side effect of making mistakes costly. For Hybrid organizations, synchronizing attribute values based on AD data is also not possible. Similarly, organizations will likely want to extend this functionality to other Azure AD integrated applications, in either direction. Microsoft will likely address such requirements in the future, but for the time being, they do represent a gap, compared to some of the other methods.
- Filtering. Being able to quickly report on all objects that have a particular custom security attribute set is one of the areas that Microsoft needs to address going forward. Still, we are able to do this client-side, thanks to the ease of getting a list of all defined extensions, as per the previous points.
- License requirements. Another thing to keep in mind is the Azure AD Premium P1 requirement, you will not be able to use custom security attributes if your organization doesn’t have a matching SKU. PIM integration in turn requires Azure AD Premium P2.
And with that, we can wrap up our not so short introduction to custom security attributes in Azure AD. A promising new functionality, designed to address some of the most common requirements and pain points of the “extend the Azure AD schema with custom attributes” scenario, we will likely be hearing more about them in the future. This of course depends on Microsoft’s willingness to continue investing in their feature set, and even more so on the collaboration between different product groups, in order to make custom security attributes available across all Microsoft 365 and Azure workloads.
Regardless of what the future brings, custom security attributes do offer some advantages over other extensibility methods. The robust permission model makes them a perfect fit for authentication-based scenarios, such as Azure’s ABAC or the confidential attributes concept. Built-in data validation and predefined values are another great selling point, as is the already released (albeit limited) support across Azure AD. Removing the dependency on application objects and the corresponding naming schema implications are also something we can appreciate.
Custom security attributes are fairly straightforward to work with, and I’m sure many organizations will appreciate the fact that Microsoft has provided a UI to manage and assign their values, even before the feature hits GA. Even though our review was mostly focused on automation scenarios, as in leveraging the Graph API endpoints to perform the corresponding operations, you can refer to the official documentation for detailed instructions on how to perform the same action via the Azure AD blade UI. If you find some of the examples we covered above too involved or outright complicated, rest assured that the UI-based alternatives are much easier to work with.
Removing the dependence on Azure AD application object is another thing that most organizations will surely appreciate. But the real MVP here is role-based access control. While attributes are available tenant-wide, the concept of attribute sets adds additional granularity and enables targeted use, and is of course what powers the robust permission model. Some of that granularity is lost when managing attributes and their values programmatically via the application permissions model, but that’s an inherent limitation of the Graph API.
Even with some shortcomings, custom security attributes add a lot of value, which is only bound to grow going forward. Thus, I have no hesitation in recommending custom security attributes as a feature you should keep an eye on. I know we at CoreView will, and we are in fact already discussing how to support them within our products.
I hope you enjoyed our detailed analysis on this promising new feature. I for one would recommend you take a deeper look into what custom security attributes bring to the table and explore their use within your organization!
5 thoughts on “Custom security attributes in Azure AD part 4: compare with older methods”
I second Ryan’s question. The failure to include confidential attribute functionality in Azure AD is a tremendous security hole with respect to leveraging Azure AD in conjunction with Azure Federation. And none of the documentation that I’ve read related to these custom security attributes indicates that they are available to SAML related functionality. That was the first usecase that came to mind when I heard about the custom security attributes and it turns out to be a bust.
Can custom attributes be used in an external identity user sign-up flow?