Home 
Integration tips and tools 
Twitter Feed snc tweets 
Downloads SNCGuru apps 
About/Contact 
About about SNCGuru 
Contact contact SNCGuru Follow these guidelines to make sure you’re using the right security technique for every situation!
TUESDAY, FEBRUARY 07, 2012
Posts Tagged ‘System Security’
Monday, 28 February, 2011 08:28
A
s a Service-now administrator or consultant, you may run into situations where it is necessary to identify the IP address of a user session before performing some action. These situations are almost always security-related. For example, you may want to restrict the ‘Delete’ operation for Change request tickets to users at a specific location, or you may want to show a particular UI action button to users whose sessions originate from a particular IP address.
I haven’t seen this type of request very often, but it is pretty simple to get this type of information in Service-now. This post shows you how.
Wednesday, 05 January, 2011 09:30
I
‘ve written before on SNCGuru about how ‘before query’ business rules can (and should) be used to secure row-level read access to records in Service-now. While this usually works perfectly, there is one issue that I’ve seen come up continually that there hasn’t been a good fix for. Over the past few weeks, I’ve seen several incidents and questions about inactive users disappearing from reference fields in Service-now systems. You may have noticed this yourself when you’ve de-activated users or groups in your system. The culprit in these cases is the ‘user query’ or ‘group query’ business rule.
The recommended (but really not great) solution up until this point is to turn the business rule off and use a reference qualifier on the reference field that you need to see the user in. The reason this solution is a bad one is that there are over 300 user reference and list fields in your system! Not only is that a big pain (and a bad idea) to add that reference qualifier to all of those places, but it also does nothing for the countless places (modules, filters, reports, etc.) that have UI elements that work like reference fields but cannot be filtered with a reference qualifier! This isn’t a new problem, but I’ve come up with a new (and extremely simple) solution.
Monday, 09 August, 2010 13:48
I
often get the request to set up access for group managers to be able to manage the members of their groups in Service-now. This configuration isn’t too difficult to set up but it does involve a few different pieces. It’s also important to consider your group setup in your system before allowing access in this way. If you are bringing in group memberships from a data source like LDAP for example, the last thing you want is to have your managers manually changing those group memberships within Service-now. The configuration shown below could be easily customized to allow access only to non-LDAP groups if you needed to do both however.
Monday, 04 January, 2010 10:44
System security is probably one of the more challenging things to implement in Service-now.com. While an out-of-box Service-now instance comes with the core security built-in, any implementation will inevitably have customizations in this area. At some point, I plan on writing a basic security guide to help administrators and consultants make informed decisions about how security should be implemented in their systems.
One little-known, but extremely useful access control method is to use business rules to restrict record access in your system. You can do this by creating what I call a ‘Before Query’ business rule. These business rules have a ‘When’ value of ‘Before’ and also have the ‘Query’ checkbox selected. ‘Before Query’ business rules are only used when you need to restrict access to certain rows within a table for certain groups of individuals. Because the security is controlled by a script, the restriction can be applied based on roles, group membership, company or department information from the user record, or pretty much anything else that you can derive about the user trying to access a set of records. There are a few of these business rules out-of-box that serve as great examples of how to implement security in this way. When I need to implement security with a ‘Before Query’ business rule, I usually start with the ‘incident query’ business rule as my template.
Thursday, 31 December, 2009 17:06
O
ne common problem I encounter with Service-now deployments has to do with the sharing of a field between many tables extended off of the same parent table. Because the Task table and the Configuration Item table make heavy use of extended tables this is where I see the problem most often. What is the best way to make changes to a shared field for the table that I’m working on, but not impact other tables that may be using the same field?
Let’s say that I’m in the middle of a Change management deployment and I’m using the ‘Configuration item’ field on my Change form. At the same time, my company is trying to roll out Incident management so there’s also someone from another department trying to make configuration changes to the ‘Configuration item’ field on the Incident form. The Incident management process says that the Configuration item field is optional while Change management says that it should be mandatory. Incident management has a very complex reference qualifier for the field, but Change management doesn’t want a reference qualifier at all. Since there is only one dictionary entry for the Configuration item field, we can’t both have our way if we are making configuration changes on the dictionary entry. Below are a few of the common scenarios where you might see this problem and how you can make it work for all tables that access the shared field.