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.
Follow these steps to add a xWeb User:
After running these steps, the xWeb user should be able to run the Authenticate web method successfully.
An xWeb user is managed from the User page in netFORUM. T
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.
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.
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.
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.
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.
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.
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.
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.
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 two-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.
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:
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.
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.
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.
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:
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!
The most prudent xWeb security profile you can adopt is:
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:
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.
Update: beginning in 2008.01, all you must do is 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.
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.
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.
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.
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:
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.