XWeb User Administration

Note: This page is geared to the netFORUM System Administrator. xWeb user has to be created by Abilaafter a valid xWeb license is purchased. Each xWeb user can only be used for one application. If you are a vendor or an integrator trying to use xWeb, you need to talk to your client and contact Abila for setting up xWeb user. See xWeb User for more.

An xWeb User represents a record in the netFORUM User table called fw_user. In most respects, an xWeb User is like any other netFORUM user that logs into the iWeb application. Just like an iWeb user, an xWeb user will belong to one or more Groups that grant privileges to netFORUM Tables and Columns that are administered through the security tools in netFORUM.

The major difference between an xWeb User and an iWeb User is that the xWeb user does NOT log in to iWeb and does NOT have a network account.

How to Create a netFORUM xWeb User

Follow these steps to add a xWeb User:

1. Create a new netFORUM user (NOT a network user) through the front end of netFORUM in the iWeb Admin module, or in the back end using the fw_user_create SP in SQL Query Analyzer.
2. From the User profile page, assign the user to the appropriate security Groups. This user MUST have the appropriate privileges to access the tables/objects they want to in xWeb. If you want to limit the tables and columns that are accessible to the xWeb User, then you may do so using Group Table Privileges and Group Column Privileges as you would for any iWeb user.
3. Run the Populate User Privileges process through the iWeb Admin overview page.
4. Update the xWeb User's xweb password.
5. Check the enforce ip security and enforce object security checkboxes (see IP Address Restriction and xweb enforce object security flag below) and configure this security accordingly as described in the next steps.
6. If you checked enforce ip security then add Xweb ip address security records for the program's web server(s).
7. If you checked enforce object security then add XWeb User Object Security records for the Objects the account will access.
8. If the user should have read-only access, and does not need to update/insert data, then check the read-only checkbox (available beginning in 2008.01).
9. Verify that the user can Authenticate and run GetQuery web method call via xWeb Diagnostics.

After running these steps, the xWeb user should be able to run the Authenticate web method successfully.

Managing xWeb Users

An xWeb user is managed from the User page in netFORUM. T

Additional xWeb related information is managed from various child forms on the User profile page. The nearby image shows the xWeb child forms on the User profile page in the 2008.01 build of netFORUM. The xWeb child forms are:

1. xWeb User Object Security - see xweb enforce object security flag below.
2. xWeb IP Address Security - see IP Address Restriction below.
3. xWeb Activity - see Checking xWeb User Status below.
4. xweb authentication activity - see Checking xWeb User Status below.

In the 2007.01 build, the only xWeb field accessible on the User page is the password field; before that build, the password field was not on the form and can only be set in back-end SQL.

Security Enhancements

In the 2008.01 build of netFORUM, a number of security enhancements were added to xWeb. These settings are controlled from the User profile page in the Admin module.

These enhancements were added to enablenetFORUM site administrators to limit the access of xWeb Users more easily. With one exception, all of these security enhancements do NOT automatically take effect for existing users, when the site is upgraded to this build. The one exception is that starting in this build, Metadata Limitation takes effect unless overridden as explained below.

Except for the metadata limitation, all of these security enhancements need to be turned on in order to take effect for existing users. This was done in order to prevent destabilizing a pre-existing xWeb integration. Abila strongly recommends turning on these settings for any new integrations, and to consider carefully turning on the enhanced security for legacy applications after making any necessary adjustments and thorough testing.

For any newly added users, the read-only, enforce object security and restrict IP address checkboxes will default to checked. This is done so netFORUM, by default, assumes a restrictive security posture.

Important! netFORUM Site Administrators: Please do not simply uncheck these checkboxes because you "don't have time to worry about them" or because you'll "get around to it later." Take the time to set up security right from the beginning. If you don't do it now, you probably never will.

xweb read-only flag

When checked, the user will not be able to run any web methods that insert, update, or delete data, regardless of any other security settings that would grant this access. Check this checkbox if the user only needs to run web methods like GetQuery, GetDynamicQuery, ExecuteMethod, WebLogin, WebValidate, etc.

If checked, then the user may not run InsertFacadeObject, UpdateFacadeObject, or other "write" web methods.

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.

xweb enforce object security flag

Checking this checkbox will implement XWeb User Object Security for the User. This security model is an improved and simpler way of managing most xWeb security. See main article for more.

xweb query row limit

Enter an integer number greater than zero to limit the record count that can be returned in GetQuery. This setting overrides DataGridRowLimit and xwebRecordReturn. If a user sets a TOP keyword in the szObjectName, they will not be able to exceed the value entered in this field.

Start and End Date

If you want to disable an xWeb user, then you can enter an xweb start date and/or xweb end date. If these fields are left empty, then the account is active. If one or the other field is left empty, then it is assumed that that field is indefinite. Suppose you want to enable an xWeb User only for the month of May, 2008. Then you would enter 05/01/2008 in xweb start date and enter 05/31/2008 in xweb end date.

Start Time and End Time

Not implemented yet. This is intended to limit the time of day that an xWeb User can access xWeb, for example, you might have a user account that should access xWeb only during non-business hours. The assumption is that if the start time is later in the day than the end time, then you want the user to be able to access xWeb from the start time of one day up until the end time of the next day. For example, if you want a user to access xWeb only from 9 PM until 6 AM the next day, then enter 9:00 PM in the start time and enter 6:00 AM in the end time. If this user tries to authenticate at 1:00 PM, then will get a fault. If they authenticate at 2:00, they will be able to do so.

If you want the user to access xWeb from 1 AM until 6 AM, then enter 1:00 AM in the start time and enter 6:00 AM in the end time.

Both fields must be populated for this to work. The fields are TimeTextBox control classes. The time is based on the time zone of the SQL Server.

IP Address Restriction

xweb ip address security enables you to associate an xWeb User with one or more known IP Addresses, and allow that user to Authenticate only when the request originates from an IP address entered into this area ofnetFORUM.

By implementing this security, you can ensure that calls to xWeb come only from trusted servers, based on IP addresses. See main article for more.

Do not confuse this with XWeb:Configuration_Settings#ValidateIPaddress; what ValidateIPaddress does is ensure that the server that calls Authenticate is the same server that calls subsequent web methods.

Metadata Limitation

Starting in this build, web methods will not allow access to metadata, defined as any Objects whose primary table is a metadata table. The metadata tables begin with a 2-character module prefix of md, cm, fw, ws, ts or mq. The one exception to this rule is the md_web* (CMS) tables.

In the very unusual case where you would want to enable an xWeb account to access any of these tables, you must enable XWeb User Object Security and explicitly grant access to the needed metadata table(s).

Note that of all the security enhancements contained in 2008.01, this is the only one that automatically takes effect for existing user in addition to any newly added users.

xWeb User Password Hashing

Beginning in this build, netFORUM offers the option to hash the xWeb User's password. In order to enable this feature, the HashXWebUserPassword system option must be set to true. Abilarecommends enabling this option. There is no automated hashing routine to switch from clear-text passwords to hashing; any existing clear-text passwords must be re-keyed by hand and the xWeb application must be restarted.

The steps to do this are:

1. First capture all the existing clear-text passwords of any xWeb Users. You can do this by running a Query from Admin -> User, finding any users where the xWeb password is not null. In your query columns, output the username and the password. Export this file and save it.
2. Navigate to the HashXWebUserPassword system option. Set it to true and Abandon Session
3. Re-run the original query, and edit each user and copy-paste (taking care to avoid trailing spaces or carriage returns) in their original clear-text password into the new password and confirm new password, and save the User record.
4. Clear cache
5. (The xWeb IIS application might need to be restarted in order to force xWeb to reload system options; once this is confirmed, please update this page accordingly).
6. Go test the xWeb integration to ensure that the password switch worked.

xWeb User Best Practices

One user for each program

For a netFORUM site with multiple vendors calling xWeb web methods, there could be many xWeb users, one for each program. Each xWeb User might require different table/column access, and you could configure each access level as appropriate for that vendor.

Do NOT create one xWeb user and share that user with multiple vendors. Each vendor should have their own distinct user. This makes it easier to change passwords when needed, and it makes it easier to track who is doing what. Any updates/inserts will store the xWeb User Name in the "add_user" and "change_user" columns in every netFORUM Table.

Taking this a step further, if one vendor has 3 sites/applications, you might want to have a separate xWeb user for each site. This allows you to further control access.

userName and Password

Recommended naming convention for the user name is xWebSITE where SITE is the name of the site or vendor calling the program. The userName should not be a person, it should be a program/application/vendor. The userName cannot have the @ character or a hypen.

Make the password long and complicated to thwart hackers. Have numbers, letters, upper and lower case, etc.

User is for xWeb Only

The xWeb User does NOT have to be associated with a network account or a SQL Login or Database User or an iWeb user or a staff person. In fact, the xWeb User account probably should not be associated with a network account as you can then trace any activity performed by this account to xWeb usage. The xWeb User should be only for xWeb access. Any updates or inserts will have the xWeb User's user name in the add_user or change_user columns. Best practices dictate that the xWeb User should be ONLY for xWeb and should not be a user who can log in to iWeb, eWeb, or the network.

If the vendor ever needs to get into your iWeb program, then we recommend separate User records for iWeb access; these User records will be just like ordinary staff accounts that will also have a network account.

Limit Privileges

Security best practices always stress that you should give only the access needed, and no more. Even though you trust your vendors/partners using xWeb, you still need to consider the following:

• The vendor's account could be hacked, opening your netFORUM site to attack or your data to theft.
• Even if the account is not hacked per se, a vulnerability in the vendor's application could be exploited and made to perform operations it would not ordinarily do.
• A bug in the vendor's application could do something unintended and negatively affect your database; although this could affect data the application should have permission to write, at least you can wall of the data that the application shouldn't need to work with anyway.
• The vendor could make a mistake and do something harmful.
• The vendor has a rogue employee; it can happen anywhere.

Bottom line, you owe it to your association -- and your members -- to minimize the risk.

Therefore, use xWeb's inherent security features, most of which are explained on this page, and do not let the xWeb Users you set up have unlimited access!

Security Best Practice Summary

The most prudent xWeb security profile you can adopt is:

• Effectively disable GetQuery except for simple lookup tables. Note that this cannot be done easily until 2008.01 by using XWeb User Object Security, and for legacy integrations this cannot be easily done as it will require the integrating program to be modified. Steer any calls to the transactional tables (Individual, Organization, financial, etc.) through custom-developed ExecuteMethod method calls where you can control exactly the data you want returned, and limit the methods to only the vendors you specify (this web method is available in 2007.01). If your build is earlier than 2008.01, you can still do this but it will require tedious and exacting configuration of Group Table Privilege and Group Column Privilege.

• Put your xWeb URL on TLS 1.2

• Use one xWeb User for each vendor and do not share the same user among vendors. This enables you to determine exactly who is doing what, and to tailor access levels for each vendor.

• If the xWeb User will never do any write operations, then make the user be a read only user as described elsewhere on this page. Starting in 2008.01, this is as simple as checking a checkbox.

• Implement Xweb ip address security.

• Implement XWeb User Object Security.

• Implement ValidateIPaddress security.

Case Study

Read Only xWeb User Account

In the majority of xWeb integrations, the calling program is only reading data from netFORUM, and not writing any data. In this case, it is recommended that you give the xWeb User read-access only. Even if you trust the vendor not to make a mistake, you should still limit the rights of the account in case the account is hacked for any reason.

Steps:

1. In the Admin module, add a new Group called xWeb Read Only
2. Run Populate Group Privileges. For Select choose Grant. For the other settings (Insert, Update and Delete) choose Undefined. Run the process.
3. Create a new User for the program, naming the user xWebUserABC if the vendor is called ABC. Be sure that you leave the "super user" checkbox UN-checked.
4. Assign the user to the xWeb Read Only group only, and not any other groups.
5. Run Populate User Privileges for this user
6. Assign the user a password as described above

Now you have a read-only xWeb user. This user will be able to run xWeb:GetQuery to retrieve information from netFORUM but will not be allowed to update/insert any netFORUM data.

If, in the future, this user ever needs to write netFORUM data, then you will add the user to additional group(s) as appropriate and then re-run Populate User Privileges.

Check the xweb read-only flag. You should also further limit the user's access only to necessary Object(s) by implementing xWeb User Object Security.

xWeb User Account with only ExecuteMethod Access

Suppose you need to create an xWeb User that can run certain ExecuteMethod methods but no other methods other than Authenticate.

The simplest and most direct way to configure this user is to follow the steps described in Read Only xWeb User Account except name the security group xWeb No Read or Write (or some other meaningful description) and when you run Populate Group Privileges, select Undefined for all four settings. With this setup, you'll be left with a user that will not be able to execute any web methods successfully except for any ExecuteMethod methods you explicitly grant to that User under ExecuteMethod's own unique security settings.

Troubleshooting netFORUM User Issues

Make sure the calling program is using correct username and password in fw_user:

SELECT usr_code, usr_pwd, *FROM fw_user (nolock)WHERE usr_pwd IS NOT NULL ORDER BY 1

Make sure that user has the appropriate privileges:

SELECT *FROM md_privilege (nolock)WHERE prv_user_name = '????'

Q. When calling xWeb:InsertFacadeObject or xWeb:UpdateFacadeObject web methods we get this error, why?

Object reference not set to an instance of an object. 
at Avectra.netForum.Data.RecordSet.GetDataReader(String szCmdText, OleDbConnection oConn, OleDbTransaction oTrx) 

A. Verify that the xWeb User has proper privileges. Ask the netFORUM system administrator to viery the user's groups and run Populate User Privileges.

Account is not authorized

If you attempt to do an Insert (via InsertFacadeObject), Update (via UpdateFacadeObject) or Select (via GetQuery), and receive one of these exception messages:

Account is not authorized to perform Insert on <<ObjectName>>Account is not authorized to perform Update on <<ObjectName>>Account is not authorized to perform Delete on <<ObjectName>>Account is not authorized to perform Select on <<ObjectName>>

Then this means you need to configure XWeb User Object Security for that User and that Object so that the user will have the necessary permissions.

Checking xWeb User Status

Beginning in 2007.01 there is a child form on the User page that shows the current xWeb Fail and Fault count as shown:

If your build is before 2007.01 and you want to check this manually, here is the SQL:

SELECT [Fail Count] = sum(case xws_expiration_policy when 'Fail' then 1 else 0 end),[Fault Count] = sum(case xws_expiration_policy when 'Fault' then 1 else 0 end)FROM dbo.ws_security (nolock)WHERE xws_usr_code = 'xxxxx'GROUP BY xws_usr_code

If these numbers are both zero, or if there is no record on the child form, then the account should be OK. If the counts are higher than the FailCount configuration setting then then the xWeb User might be locked out and this could explain any xWeb issues. See XWeb:Authenticate#Credentials_Locked_Out for more on how to deal with this issue, including instructions for how to un-unlock an xWeb User that has been locked out.

For 2008.01 build, this child form has been made more informative to reflect the fact that an account is locked out only for the IP address that causes the faults or failures. If one IP address is throwing faults, it will get locked out only for calls from that IP address; if another IP address also authenticates with that username, and that IP address is under the fault/failure limit, then it will not get locked out. The updated child form is shown below:

Here is how to interpret the data in this child form. The following columns are:

• User IP Address - the IP address from which the user attempted to Authenticate
• Failure - the count of Authentication failures from the User
• Fault - the count of method faults from the User
• IP Failure - the count of Authentication failures from the IP Address in the first column
• IP Fault - the count of method faults from the IP Address in the first column

The account above, assuming that the FailCount is set to the default value of 10, and that the default LockOutHours is at the default value of 6, then this account will be locked out because the IP Failure count is at the limit of 10.

If the Failure count were to be at 10, then the account would be locked out.

If the Fault or IP Fault is over the MethodsFaultLimitPerDay limit (default is 50), then the account will get locked out.

If all the numbers are 0, then the account is good.

Beginning in 2008.01, a new child form has been added to show each authentication attempt for the user. Think of this child form as the "detail" view of the summary child form shown just above.

The default sort order is the Add Date descending. The Remaining Minutes shows how many more minutes are left before the token expires (this is essentially the difference between the system date and the Expiration Date). A negative number means the token has expired.

If an account is locked out, and you want to re-enable the account, you can delete the "Fail" attempts from the child form to put the user under the lock-out threshold.