xWeb User Object Security
xWeb User Object Security is an improved and simplified way of administering xWeb User account security in xWeb. This security feature allows for setting Object-based security for a user, instead of working with the more complicated and granular Group Table Privilege and Group Column Privilege security. xWeb User Object Security provides a more user-friendly and intuitive way to configure security that a busy "real world" site administrator can actually do.
Instead of determining exactly which database Tables and Columns a User can work with, select the Object(s) and flag whether the user may select, insert, update or delete that Object. Any web methods will automatically look to these settings to see if the user is allowed to perform the operation. (Note that at this time the delete flag is not used, but has been added for future use or custom use.)
If you wanted to use Group Table/Column security to enable a user to insert an Individual, you must ensure that the user has access to certain columns in at least a dozen tables. Attempting to determine the complete list of tables and columns that are inserted when adding an Individual can be daunting. In Abila's experience, this exercise was so difficult that most administrators just left the xWeb account with unlimited privileges because paring it down to an appropriate level is too hard. Unfortunately this leaves us with a potential security vulnerability that is difficult to correct. With xWeb User Object Security, all you need to do is add a security record for the User, choose the Individual object, and select the allow insert checkbox, and you're done.
Technically, xWeb continues to enforce Group Table/Column security for site administrators who need the maximum level of security granularity and flexibility. xWeb User Object Security lays on top of Group Table/Column security; it is not a replacement of or a substitute for Group Table/Column security. With this in mind, the recommended best practice is:
- Put the xWeb User into a security group that allows for unlimited Table/Column privileges.
- Check the enforce object security flag checkbox for that user. This will have the effect of taking back all security you just granted in step 1.
- One-by-one, add xWeb User Object Security records to specify exactly which Object(s) the user can interact with. Doing this will carefully "add back" the security that you took away in step 2, leaving the xWeb User with just the right security level.
This feature is turned on only when a user's enforce object security flag checkbox is checked on the User record. Even if the user is a super-user, this security will still be enforced if the enforce user object security flag checkbox is checked. For sites that upgrade to this build, any existing users will not get the checkbox checked automatically, but any new users added on this build will have the checkbox checked.
How Security is Enforced
When certain xWeb web methods are executed, xWeb looks at the Object (typically this is set in a parameter called szObjectName) and whether the web method is trying to select, insert, update or delete. If the xWeb User's enforce object security flag is checked, then xWeb looks to the xWeb User Object Security database table (fw_user_x_md_object) and looks for a record for that combination of User and Object, and which also has the appropriate checkbox (select/insert/update/delete) checked. If a record exists, with the appropriate checkbox checked, then the web method will fire. Otherwise, an xWeb Exception with a fault will be thrown.
For example, when running GetQuery, whichever Object the user chooses, that user must have a xWeb User Object Security record for that Object with the select checkbox checked. When running InsertFacadeObject, the user must have a xWeb User Object Security record for that Object with the allow insert checkbox checked.
Managing Records
From the User profile page in the Admin module of iWeb, navigate to the user record. On the xWeb tab, add a record from the xWeb User Object Security child form. Select the Object and check the appropriate checkbox(es).
You can only add one record for a combination of User/Object.
Web Method List
The table below maps xWeb's Web Methods to the necessary xWeb User Object Security setup that will permit a user to execute the web method. For example, if you want a user to run the CreateAdvocacyData method, then they must have a xWeb User Object Security record with the Congressional Contact Object and the Insert operation. If you see n/a in the Object column, this means that the web method does not use this feature.
| Web Method | Object | Operation |
|---|---|---|
| Authenticate | n/a | |
| CreateAdvocacyData | Congressional Contact | Insert |
| CreateInvoice | Invoice | Insert |
| CreatePayment | Payment | Insert |
| ExecuteMethod | n/a - Uses specialized security | |
| GetDynamicQuery | As specified in szObjectName parameter | Select |
| GetDynamicQueryDefinition | As specified in szObjectName parameter | Select |
| GetFacade Object | As specified in szObjectName parameter | Select |
| GetFacade ObjectList | Will return only Object(s) for which user has can select permissions. | Select |
| GetFacadeXMLSchema | As specified in szObjectName parameter | Select |
| GetIndividualInformation | Individual | Select |
| GetOrganizationInformation | Organization | Select |
| GetQuery | As specified in szObjectName parameter | Select |
| GetQueryDefinition | As specified in szObjectName parameter | Select |
| GetVersion | n/a | |
| InsertFacadeObject | As specified in szObjectName parameter | Insert |
| NewIndividualInformation | Individual | Insert |
| NewOrganizationInformation | Organization | Insert |
| SetIndividualInformation | Individual | Update |
| SetOrganizationInformation | Organization | Update |
| UpdateFacadeObject | As specified in szObjectName parameter | Update |
| WebLogin / WebLogout / WebValidate | Customer | Select |
FAQ
Q. Can I use both Group Table Privilege and Group Column Privilege security and use xWeb User Object Security security?
A. Yes. Group Table/Column security is enforced unless the user is a super-user. xWeb User Object Security is used only when you check the enforce object security checkbox on the user record. Both security features will run simultaneously, and the user must pass both security checks to perform the action. For example, if the user is in a group that has "deny" select access on the Individual table (co_individual), but does have a xWeb User Object Security record for Individual with can select checked, then the user will not be able to run GetQuery on that Object.
Q. I want to allow a user to select from the co_individual table, but not the SSN column (ind_ssn). How can I do this?
A. You'll need to use conventional Group Column Privilege security to prevent the xWeb user from selecting the ind_ssn column. Even if you also add a xWeb User Object Security record allowing he xWeb user to select from the Individual object (which maps to co_individual table, Group Table/Column security will override xWeb User Object Security security and the xWeb user will not be able to select the ind_ssn column.
Q. How am I supposed to know which Objects to grant access to my vendor?
A. Depending on the breadth and complexity of the integration, this can be difficult to determine. Let's face it, to administer security properly can be time-consuming. You will need to determine exactly which data points the vendor will need, and configure security appropriately.
Q. I want to prevent an xWeb User from adding an Invoice. How can I do this?
A. As soon as you check the enforce object security checkbox, then instantly the user can't do anything, with some exceptions as shown above. The user can't add an invoice, and the user can't even select from the Prefix and Suffix tables. With the xWeb User Object Security model, you must add in every object the user can interact with, one by one. By contrast, with Group Table/Column security, the usual practice is to grant access to everything and then chip away; given how complicated that is, few site administrators undertake the task.
The issue is that you probably don't know exactly what methods the integrating application is running, and it might not be easy for the vendor to give you a list. Assuming you can get the integrator to give you a complete list, then you can add all the necessary xWeb User Object Security records. Then check the enforce object security checkbox and make sure everything still works. Obviously you'll want to try this out first on a test environment.
Q. Technically, when you add an Individual, it also adds Address, Phone, Fax, Relationships, etc. In order to run the InsertFacadeObject web method for Individual, do you need xWeb User Object Security records for all of these Objects?
A. No, you only need it for Individual. If you want to call methods to update these other records singly, then you'll need to add xWeb User Object Security records for those as well.
Q. If I want my integrator to be able to run an update on an Object, do I also need to grant select on the same Object?
A. Technically the answer is no, but for practical purposes you should grant both select and update. Without the select rights, the vendor won't be able to get the information about the individual record in the first place, thereby making it impossible to know how to update an individual.
Q. I added a record to the xWeb User Object Security child form for a user, and then immediately ran a web method, but the change did not seem to take effect. Why?
A. This data is cached for performance reasons, so even if you modify the actual data, the cache is still stale. You will need to Clear cache (Admin --> Overview --> Clear Cache) in order for xWeb to recognize the change. Although this is inconvenient, the performance gains are worth it - we don't want xWeb to query this information over and over and over when it will almost never change in a stable production system.
Implementing for Custom Web Method
If you are writing a custom web method in .NET and want to implement this security, here is what you need to do. First, you will have to determine which Object and security operation (select, insert, update, delete) your web method most closely relates to. In the ASMX.CS page, in your web method definition, include the following lines right after the ValidateToken() call:
try
{ ValidateToken(); xWebServiceClass.ValidateOperationSecurity(this.szUserKey, "<< NameOfObject >>", SecurityOperation.Select, this.bEnforceUserObjectSecurity, false, this.bReadOnly); // keep going...}catch(Exception ex){ // manage exception...}
- The first parameter is the Key of the user. You can set this by passing this.szUserKey.
- The second parameter is the name of the Object.
- The third parameter is an enumerator with values for Select, Insert, Update and Delete. Choose the appropriate one for your custom method.
- The fourth parameter passes the user setting for xweb enforce object security flag. You should always pass this.bEnforceUserObjectSecurity which is an automatically included property.
- The fifth parameter is for internal use. Just pass false
- This sixth parameter indicates whether the xWeb User has the read only checkbox checked. If your method is a write web method, the validation will not permit read-only users to execute the method. You should always pass this.bReadOnly to this parameter.
You must call ValidateToken()before calling this method.
The method is a void that will throw an exception if any violations occur.
If your web method does not really map naturally to a particular object, then you can add a new Object purely for this purpose, or you could use ExecuteMethod security for this purpose.