Cryptographic User Hierarchy

The SecurityServer EKM provider also supports hierarchical users via wildcards in the CXI_GROUP user attribute. Imagine the following SQL Server credentials with their identities and the CXI_GROUP attribute of the matching SecurityServer users:

List of Credentials and Identity

An SQL Server account bound to credential EKMuser1 is logged into SecurityServer as EKMuser1. New keys are generated in CXI group ekmgrp1, and only keys in that group can be accessed. Similarly, an SQL Server account bound to credential EKMuser2 is logged in as user EKMuser2, and new keys are generated in CXI group ekmgrp2. Unsurprisingly, an account bound to credential EKMadmin is logged into SecurityServer as EKMadmin. New keys are now generated in CXI group ekmgrp1 since this value is taken from the credential's identity. However, this user can also use keys generated by user EKMuser2 in group ekmgrp2 since the CXI_GROUP attribute grants access to these keys as well. This works since SQL Server commands refer to a key by an SQL Server name, which is bound internally to an EKM provider key name defined in the CREATE … KEY statement, and the actual access is done using an identifier stored together with the SQL Server name. This identifier is also used when the key is deleted inside the provider.

Note that the CXI group from the credential's identity is also used when a key inside the SecurityServer is searched by name. This happens when a new SQL Server key is created from an existing SecurityServer key. Currently, supplying a different CXI group in the CREATE … KEY statement than the one given in the credential is not supported. Moreover, there would be no way to explicitly specify the CXI group when viewing all the keys from the EKM provider.