Vancouver: Security Attribute Conditions Explained

[Willem]

Vancouver: Security Attribute Conditions Explained

In the Vancouver release there is a new “Security Attribute Condition” added to the conditions

 In the Access Controls (ACL’s):

As well as on Data filtration records:

---

Security Attribute Conditions

Description

But what do these new Security Attribute Conditions mean? What do they do? There is no documentation on this in the Vancouver docs (as per the last version of August 3^rd😞
https://docs.servicenow.com/bundle/vancouver-platform-security/page/administer/contextual-security/t...

When the Docs do not tell us about these nice new Gems, it is up to the Community to support! After a bit of digging, I found this:

Name	Description
Group	User is member of the specified group
GroupExplicit	User is an explicit member of the specified group.
HasAdminRole	User has admin role
Impersonating	User is impersonating another user
InteractiveSession	Current session interactive
LoggedIn	User is logged-in/authenticated
NetworkCriteria	Network Criteria
Role	User has the specified role
RoleExplicit	User has the specified role explicitly, that is, it is present in the sys_user_has_role table.

(Want to view this yourself? It is in the “sys_security_attribute”-table

< yourinstance >.service-now.com/sys_security_attribute_list.do )

---

Explained

If this provides you with enough information. You can stop reading here. However, I can imagine that from the description there is still some unclarity. Below I try to both visually and in text explain the concepts, so you know how to use it. In case you have any questions, feel free to comment below 😊

Group

User is member of the specified group

If you are added to the Netherlands Group, you are by group inheritance part of the Europe Group. Both direct assignment in the Europe group, as well as the inheritance will evaluate to TRUE.

GroupExplicit

User is an explicit member of the specified group.

Only by direct assignment in the Europe group will evaluate to TRUE.

HasAdminRole

User has admin role

Either inherited or granted directly the (System) Admin role it will evaluate to TRUE.

Impersonating

User is impersonating another user

Will evaluate to TRUE if the current logged in user is impersonating another user

InteractiveSession

Current session interactive

Allows you to distinguish between a logged in user (interactive session) and an integration (user). Returns TRUE for an interactive session.

LoggedIn

User is logged-in/authenticated

Allows you to specify if the ACL is only applicable to logged in users, or users that are not authenticated (public). Returns TRUE if the user is logged in.

NetworkCriteria

Network Criteria

Allows to filter based on IP Ranges. Specify an IP Range (record), the Network criteria will evaluate to TRUE if the user is logged in with an IP within the IP Range.

Role

User has the specified role

Both having for example the HR Manager role, inherited from HR Admin, as well as directly having the HR Manager role will evaluate to TRUE for the Role condition

RoleExplicit

User has the specified role explicitly, that is, it is present in the sys_user_has_role table.

Only having the HR Manager role directly will evaluate to TRUE.

[paulcurwen_pgds]

That DOCS has no mention of this is a bit of an oversight to say the least 🙂

[marcos_castro]

Thank you for documenting this. It's a pretty neat feature. Do you know if it will be available to install on previous versions as well?

[Manthan]

@Willem Thanks for documenting this.

[Joe Walters]

Very nice write up!

Any quick insights into what "Existing" vs "Local " means?

[Paul Curwen]

DOCS now has some info.

https://docs.servicenow.com/bundle/vancouver-platform-security/page/administer/contextual-security/c...

Here you will find the explanation of Local vs Existing

https://docs.servicenow.com/bundle/vancouver-platform-security/page/administer/contextual-security/c...

Local and Existing Security Attributes

Existing and Local Security Attributes enable customers to reuse Security Attribute condition sets.

Local & Existing Attributes

The ACL Security Attribute Condition Builder enables customers to specific if a Security Attribute is either existing or local.

Note: Security Attributes conditions are defaulted to local.

A local defined Security Attribute is saved only to the single ACL where it is created in.

The existing option enables users to reference an existing Security Attributes conditions to the condition builder.

[Luiz Guilherme]

Looks like SNOW is starting to take the necessary attention to the platform access management area, which is a really hight concern area to be addressed once there is no OOB solution to manage it and the platform complexity doesn't help customers to address it, ie. Separation of Duties conflicts (SOD) OOB; even the OOB roles/personas doesn't have a SOD matrix that helps to identify conflicts between them.
I really hope this is just the start point so ServiceNow will provide more and more OOB tools to help customer to do the platform governance.

Thank you

[amol_joshi]

How does it work with the previous 3 conditions (role, field condition, script condition)? We could leave the field and script conditions empty and ACL would still grant access based on just role condition. Will that still be a case? Can we leave the security attributes untouched during configuration and still get ACLs working?

Thanks

[carleen]

@Willem What a great article!

That last one confuses me a little. Many applications are set up to inherit lower-level access to simplify user-role access and ACLs. I read your explanation, which means this won't work with RoleExplicit.

For example:

• admin role contains manager role
• manager role contains user role

This way

• The user can be granted the only admin role (direct or via group) and inherit manager and user automatically, instead of having to grant them all three.
• lower-level ACLs, like can read [xyz] app table, only need to have the user role, instead of user, manager, and admin.

Here is an example of a user that gets the notify_view role through a few levels of inheritance roles. These inherited roles are present in the sys_user_has_role table. All roles granted by a group show inherited=true, and contains roles regardless of whether they are granted through group membership or a direct role, will show inherited=true.

In OOB(Out-of-Box) Security Attributes: Non-explicit and explicit behavior explained it says:

Security Attributes address nuanced permission needs with an explicit vs. non-explicit (inherited) evaluation of roles permissions.

This leads me to believe top-level roles granted by groups (which are inherited=true) will also be denied.

Have you tried to test any of the scenarios above yet?

[Willem]

Hi @carleen 
Yes you are correct. Role inheritance still works for Role, so if you want that behavior you can select that. But with RoleExplicit adds the "nuanced permission". I cannot remember if I tested it with group inheritance. But I definitely tested the role inheritance from the example. So Admin, although inheriting the role, could not access when using RoleExplicit.

To me it would make sense that you still have access if the exact "user"-role (from your example) is granted via a group, that the user with that role still has access. I would assume that counts as giving the users in the group explicitly that role. But you are also correct that it is group-inheritance, so a form of inheritance...🤔

[Matt Hernandez]

There is an interesting write up from an external party, from Jan.2024 => Balancing Act: Navigating the Advantages and Risks of ServiceNow’s New Security Attributes 

NOTE:  it looks to be part of an advertisement about selling a security management tool. Still its a more intriguing description than Servicenow provides.

[Merrindal Routl]

Hi all,

Great article but I'm still a little confused about the Local vs. existing options.  The docs say the following:

A local defined Security Attribute is saved only to the single ACL where it is created in.

The existing option enables users to reference an existing Security Attributes conditions to the condition builder.

I think that the above means:

Local: Value returned by the condition field

Existing: Value returned by the Security Attribute field

Is that correct?

[Adam43]

I'm curious about Local vs. Existing as well.  I'm troubleshooting a report view ACL that seems to only exist in our production instance (still on vancouver) and not in our sandbox (upgraded to Washington already).  it's marked as Local, but the current version is stuck on an older 'default' and not on what should be a more updated version from the application.  there are no updates on the updates related list and the ACL itself shows created by 'service.now' and updated by 'admin'.  don't think i've ever seen the user 'service.now'.  And comparing the 'current' version to most recent from the application removes the 'local' value to null in the field.

before I open a HI ticket- any thoughts?

[kali]

Hi @Willem ,

Thanks for this amazing article. While creating ACL if i am planning to use security attribute conditions then i can ignore the roles , script conditions , data conditions like the acl will check the security attribute conditions and then provide access.