This page deals with security configuration related to IFS Analysis Models
To successfully extract data to the Data Warehouse in SQL Server it is necessary to make sure that the executing user is granted read access to all involved objects, i.e. basically the Access Views and also that this user has access to data to be extracted.
The preferred user is the <IFSINFO> user that is defined during installation of IFS Applications. This user will have access to all necessary views in his own schema. By default this user has full data access to the Information Sources supported by Analysis Models.
The only other but not preferred option would be to use to <appowner> but using this user is a security vulnerability and should thus be avoided.
It is important to understand what happens during the extract step in the ETL process. The following section provides a summary.
In the Extract step there is a connector that is used to connect to the
Oracle database. Username and password is defined. The credentials for the <IFSINFO>
user is thus the preferred option.
During execution the following happens:
This means that if the F1 user has language en (English) as the default language, translated texts will also be transferred as English texts. If the purpose is to view information in an OLAP cube in e.g. French, after processing the ETL, then the Cube might support French attribute translations but the language dependent data will still be in English. This means that the transferred translatable attributes as e.g. descriptions, will only be available in the Data Mart in one language, e.g. English. An OLAP cube can however via use of SQL Server Analysis Server be translated to many languages. Normally only labels etc. are translated in a cube. It is however possible to also define translations for the data such as descriptions, but there is no automated support for this. So the IFS Applications specific translations cannot be transferred via the ETL process except for translations in one language, according to the default language of the current F1 user.
It is recommended to use the <IFSINFO> user that is defined during installation of IFS Applications as the extracting user, i.e. the IFS Application user defined in IFS Analysis Models Installer that will log on to the IFS database and read data from the Access Views. The <IFSINFO> schema will contain all necessary views, mainly Access Views, and the security filter mechanism of the involved views, Fact and Dimensions view, is designed to give full read access to this user.
The only other but not preferred option would be to use to <appowner> but using this user is a security vulnerability and should thus be avoided. Any other user than the ones mentioned is not possible since the SSIS packages used in the ETL process are not designed to handle a general user.
The Access Views are designed to work both for access within or from outside of IFS Applications. Data related security is especially important for access within IFS Applications. The Access Views act as a layer on top of existing dimension and fact views. These views may have security implemented explicitly as part of the view definition and implicitly as part of function calls or sub selects. Thus, to make sure that all data as well as correct data is extracted, it must be made sure that the User has access to the data.
As long as the preferred user, i.e. <IFSINFO>, is used it should not be necessary to define any data access since that is built into the security filter mechanism. But if, for some reason, the <appowner> is used it will be necessary to make sure that this user has full access to the data.
The following options are possible:
Note: The <IFSINFO> user should have full data access. The Application Owner however will by default NOT be defined to have access to all data in IFS Applications. For this user it is therefore vital to make sure that data access is granted.
It is necessary to define companies that the extracting user has access to. Only these companies will be transferred. The general approach would be to make sure that the User has access to all companies.
This can be done by using the Users per Company page.
The drawback with this option is that companies have to modified one-by-one.
To get full access to Information Sources in General Ledger it is necessary to make sure that the Application Owner, in each company, is connected to an authorization class that allows full read access.
Note: There might not be an available authority class that gives full read access
The other way is to use the following page in the General Ledger area.
In the Authority Classes page, all available authorization classes in a company can be viewed. It is necessary to have one authority class that is dedicated for full read access. By default this class is named MAX and it is defined during company creation.
The above page only allows to handle companies one-by-one.
Once the Authority Class has been defined in a company, the next step would be to make sure that the Authority Class allows full access. Use the page Authority Combinations to handle this.
Allowed should be set to Yes and for all code parts the allowed value should be %.
This configuration must be done per company.
The last step would be to make sure that the Application Owner is connected to the authority class that gives full access. Use the page Users per Authority Class.
As before the configuration must be done per company.
It is necessary to define sites that the extracting user has access to. Only these sites will be transferred. The normal thing would be to make sure that the User has access to all sites.
The page Sites per User can be used for this purpose.
In this page, all allowed sites can be defined for one user, i.e. the sites that the Application Owner has access to.
Access to projects is by default granted to the Application Owner.
This means that there is nothing to be configured to be able to read all project related information.
To get access to Employee Analysis in Human Resources (HR) the User has to be set up to have access to protected information through the Access to Protected Persons page.
Time and Attendance related Information Sources are not used by Analysis Models for Applications 10. If however it is necessary to add these Information Sources to the ETL process as a customization, please consider security. Some information is supplied in this section.
Position Access affects the following Information Sources:
Documentation about how to setup position access, please refer to:
The configurations in IFS Applications are made in order to make sure that data is not filtered, i.e. that the different Information Sources supply data without considering security mechanisms. In most cases the raw data from IFS Applications should be extracted and defined in the SQL Server database. It is more or less not possible to define security in IFS Applications that should apply when loading the Data Warehouse. Security is often user or role based so the security must be defined late and not during the extract phase.
Security information related to different product specific security implementations are not transferred to the Data Warehouse. This means that there is currently no way to use existing information to build a security layer in the SQL Server database. Thus, if this is needed it has to be handled by each customer project.
One way to handle security in SQL Server would be to create roles, assign user to these roles and then in SSAS set up e.g. dimension access with respect to these roles. Security in SQL Server generally and cubes especially is a rather big area and many solutions are available. Please follow this link to get more information.