fSeries is all about gathering data and delivering it to users. It is therefore essential that the system protects data in terms of who can have access and which data they can see, as well as logging activity.
At the same time fSeries is a highly configured system that provides the flexibility to implement it in many different environments and organisations.
fSeries security is therefore flexible enough to fit the customer’s needs but strong enough to protect the data it is accessing.
User Authentication
When a user attempts to use fSeries in any way, they are authenticated. This is often not seen by the user as the system will attempt to authenticate them based on their network identity (note: automatic authentication may be disabled for web service access by setting AutoAuthenticate off).
Authentication is done using an fData DSD that returns several pieces of information:
- Are the user’s credentials valid
- Which fSeries roles does the user hold
- Which data access roles does the user hold
- Which allow/deny permission sets does the user belong to
- Any other information about the user (such as their identity in other systems)
All of this information is captured during authentication and is accessible through fSeries. For example you can use data access roles and allow/deny permission sets to determine what data and options they can have access to, or you may want to pass their identity in another system to that system when requesting data.
The security DSD to be used can be specified by the administrator. Several standard DSDs are available, but these may be adapted for your own use or you may even create a new one for your own requirements.
Further information:
Data Access
fData is the part of fSeries that gathers data to be used in fPanels, fDocs or fRemote. In many cases this is straightforward in terms of security of the data but some data is sensitive and must be protected from unauthorised users.
There are two levels on which you may want to secure data based on the user requesting it:
- Data set – may this user see this set of data
- Rows and Fields – may the user see specific rows (records) and fields
Data Sets
Data gathering is defined in DSDs (Data Set Definitions). A DSD is not just a query to grab a table of data, it is a process of steps to build up a set of data about a subject (e.g. a client, an address, a team). This process can include steps to determine information about the user and then restrict the data included.
For a simple example, if a user may only see data about a selected client if they are a member of a particular team, the DSD can first discover which teams the user is a member of, and then use this information to either disable the client data completely or restrict the data returned for the client. This way of stepping through a process is particularly important if these two steps require data from completely different data sources.
Because fData can gather many different sets of data (data groups) in one data set, it provides very flexible ways to check, control and block data groups based on data gathered within the DSD or in a separate DSD, or information picked up at login.
Further information:
Rows and Fields
When fSeries gathers data, as each data group is gathered, fSeries Data Access Control (DAC) checks against rules set for the data group in the DSD. DAC applies each rule and either removes corresponding field values or removes rows accordingly. Several rules may be set for a data group and all will be checked and applied.
DAC restricts fields and rows in a data group based on either the user’s data access role (established at login) or any condition expressed as an fSeries function, or a combination of both. The function is evaluated immediately after the base data is gathered and any data items have been calculated, so that the condition may be based on values in the row.
Further information:
Data Sharing
fRemote lets you share your data with other fSeries servers but under your complete control. There are many levels on which you can protect your shared data.
Each fRemote server has a unique Remote Id. As a data provider you must issue this to other fSeries customers with whom you wish to share data. This ensures they are requesting data from the correct fSeries server.
Each of your permitted requestor servers must also be issued with a user id and password that is a valid user in your fSeries with the role “Remote”.
You can also specify that you will only accept requests from designated IP (server) addresses.
So any request for data must specify your unique Remote Id, contain credentials of a valid user with the Remote role and (optionally) originate from a designated IP (server) address.
The requestor has access only to data that you permit. This is done by creating DSDs for their use that have the “Remote” purpose. Further, you can optionally tag DSDs to be available only to specific requestors. This means that you can be precise about which remote fSeries server can have which sets of data.
When a requestor fSeries administrator is creating their own DSDs to gather data from your server they will be offered only those DSDs that you have given permission for them to use. They cannot access your data only request DSDs for which you have granted them permission.
The DSDs that you create to provide data remotely can include all of the security features that apply to your own data security. By default your DSD has access to the requestor server’s credentials but you may also insist that the requestor supplies more details about the actual user (such as their role) that you can incorporate into your own data security.
fRemote data sharing provides many levels on which you can protect your data and only allows others to request data that you have explicitly given them permission to receive.
Further information:
Output Sharing
fRemote also provides an option to share outputs with users under your full control. This is the fRemote Groups option.
By default fSeries provides open access to outputs to all users, securing data at the point where it is gathered. If you want to privode access to outputs (fDocs, fSheets, fPanels, or fMaps) for groups of users (internal or external) but maintain control over what they can access, fRemote Groups is designed to do so.
For each Group, a menu is set up (called fRemote_[group id]) which lists all of the options you wish to make available to the group, including menus of further options. When a user comes to the site they can only access outputs and menus included in this special menu.
You can also designate a “start menu” for each group so that users only need to come to your site and they will be directed to an appropriate start menu to allow them to access outputs.
Further information:
Audit Logging
As well as providing extensive data security options, fSeries also lets you log user activity (both access to the system and access to your data).
Logs are recorded in the fSeries SQL Server database but the content is entirely in your control. This is achieved with the Audit Log data group type. By adding one or more Audit Log data group within a DSD, they will be included in the data gathering process, recoding the activity.
If you include such a data group in you security DSD you can record user access the system (the standard security DSDs include this).
If you include such data groups in any other data group you can record exactly what the user has seen.
fSeries will automatically record key details such as the logged in user, the date/time and the context (e.g. the document being generated or the presentation being displayed). You can specify further values to be recorded based on the data gathered (e.g. the client id that they requested).
Further information:
Useful Functions
fSeries functions are used throughout security to test values such as data fields, data access roles and permission sets. Below are some fSeries functions that are particularly useful in this context.
AccessRoles returns the user’s data access roles
HasAccessRole check whether the user has a specific data access role
HasNoAccessRoles check whether the user has no access roles at all
CheckAccess checks whether the user has access rights based on a list of permission sets
AllowAccess checks whether the user’s allowed permission sets match a specified list
DenyAccess checks whether the user’s denied permission sets match a specified list
UserData returns a value about the user captured at login in User Defined Values
Further information:
