Management of custom attributes for certificate groups

[doloban]

In terms of certificate management through CZERTAINLY we typically have different logical certificate groups. For each group we would like to have unique custom attribute set.

At this moment it is possible to link attribute to specific resource, the goal would be to link custom attribute only to certificates, which members of specific group/s.

Setting of custom attribute could work similarly to choosing resources for custom attribute - there would be possibility of choosing specific groups, for which would custom attributes set show up.

In situtation where certificate is imported into CZERTAINLY the user would choose specific group at the beginning, where the certificate belongs, and then after the selection is shown list of custom attributes assigned to that specific group (in custom attribute configuration). If certificate doesn't belong to any existing group, then will be shown only attributes, that have resource=certificate, but they don't have any assigned group.

Change of group is not a common operation so it is probably not necessary to deal with custom attributes in this situation. A prompt with warning "You are about to change certificate group, there is a possibility of custom attribute data loss. Do you want to continue?" could be enough.

[3keyroman]

Hello @doloban , we were discussing the possibilities for the management of the custom attributes based on the association to groups, similar way, how groups can be associated with RA Profiles for example.

Take a look at the draft here: https://github.com/orgs/CZERTAINLY/projects/5/views/1?sliceBy%5Bvalue%5D=Certificates+%26+Requests&pane=issue&itemId=75301455

The group in CZERTAINLY is meant to be a logical separate space, like a folder containing object that are assigned to the same group. Our idea is to implement association with groups to custom attributes. Then you should be able to assign custom attribute to specific group or groups.

Any comments to this approach?

[brozova-m]

Hello @3keyroman, this feature suggestion is more likely to be under my charge, please feel free to direct future communication on me.

I read the draft and it feels exactly how we ment it. About the part "To solve":

1. if a custom attribute has a group then object without the group should not be able to have this attribute, object without any group should be able to have only attributes without a group (if we want to complicate the situation we can create a policy settings where an administrator can choose whether the attribute is required/optional/not visible for object with/without the group, but let's start with the less complicated variant)

2. you should allow it with loss of the content I would only suggest that if an object has multiple groups (I think that this option is planned to implement in close future) then the attribute with its content disapears only if there is no group assosiated with the custom attribute left

I hope that my answer is clear, let me know in case it is not.

Thank you, Marie Brožová

[3keyroman]

2. you should allow it with loss of the content I would only suggest that if an object has multiple groups (I think that this option is planned to implement in close future) then the attribute with its content disapears only if there is no group assosiated with the custom attribute left

The object can have multiple groups in the current release of the CZERTAINLY. My only concern is about forcibly removing custom attributes and its content, when the user will make any change to the group association of the custom attribute.

Although the warning can be shown to the user in UI, it would not in the API.

Wouldn't be more safe to tell user that it cannot be removed or changed because there is still custom attributes used for some objects (or list objects if there is few of them). In this case the user has control about the custom attributes and when you want to remove group, you will need to filter object with such group and remove custom attributes.

What do you think, @brozova-m ?

[brozova-m]

@3keyroman yes, it sound like client will have it more under his control like this, I am OK with your suggestion, Best, Marie

[doloban]

I'm reading through this too, and I agree with you @3keyroman . It would make sense to prevent user from deleting attributes bound to specific group by removing/changing group. And even if a user wants to do that and has a lot of filled attributes bound to specific group, he could list all filled attributes and remove them by API Bulk Operation.