Field level ACL removes sys_id

[kmlutz]

For security requirements, we need to limit what fields are provided access based upon an ID. Once the ACLs are created, the sys_id of the "tables" are no longer available. The ACLs are being setup for an ID performing a direct call to SN. It has hard-coded in it's logic to be able to use the sys_id field and not another field that may have the same data. I know there may be other ways to do it but we are trying to use their integration tool for the work which seems designed to use sys_id throughout its logic.

Anyone know if there is a way to limit access to a table like cmdb_ci_win_server via ACLs and yet be able to provide the sys_id?

Thanks.

[Slava Savitsky]

Hi Kurt,

I am not sure I understand your question. Could you please try to explain once again what you are trying to achieve? Thanks.

[kmlutz]

Slava,

We have an ID with SOAP roles. Before any ACLs are written, that ID can see the sys_id of a windows server. Once I write the ACLs to lockdown all fields to that ID...like a cmdb_ci_win_server.* set to false...it can't see any fields. Then we only want it allowed to see certain fields. I open it up to the approved fields which it can see and use but sys_id is not one of them. Also, since sys_id does not truly dwell on the form itself...it is not offered via an ACL.

The HP team suggested working with SN to change it, but it seems like a platform design...that once you decide on field level ACLs you will lose access to see the sys_id. I don't see any way to meet the security requirement using ACLs and providing the sys_id to the ID we are using.

I know there are other ways to do the integration, but we wanted to use their integration tool which seems hardwired to use sys_id as a primary key and can't look at another field even if it contains the value.

Let me know if that helps.

[Slava Savitsky]

What if you try to secure fields with individual field-level ACLs instead of locking down everything with a " .* " ACL?

[kmlutz]

Slava,

The problem is we are talking about multiple classes in the CMDB. I can't see the benefit of writing ACLs for every field they can't have access to...and also if we add new fields...then we would have to write ACLs for the new fields every time.