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 it is also so that this user has full data access to the Information Sources supported by BI Analysis Package.
The only other but not preferred option would be to use to Application owner but using this user is a security vulnerability so avoid this user as far as possible.
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 access Access Views to read data. 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 design to give full read access to thi user.
The only other but not preferred option would be to use to Application owner but using this user is a security vulnerability so avoid this user as far as possible. Any other user than the once mentioned is not possible since the SSIS package 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 Application owner 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 the Application Owner is granted data access.
The User feature in Solution Manager in the IEE client can be used to define some of the necessary security settings.
As can be seen from the picture above the following can be defined via this feature:
Note: If not all companies are selected, then the transfer will not include data from non selected companies
Note: If not all sites are selected, then the transfer will not include data from non selected sites.
Authorization Classes in General Ledger, i.e. defining access level for
the User in General Ledger. Make sure that for all
companies that should be transferred, an authorization class with full
access, normally named MAX, is used.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.
One way to do this is to use the User Feature in Solution Manager.
The other possibility is to use the Users per Company form in the IEE client.
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.
One way to do this is to use the User Feature in Solution Manager.
Note: There might not be an available authority class that gives full read access
The other way is to use the following forms in General Legder.
In the Authority Classes form, all available authorization classes in a company can be views. 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 created when a company is created.
The above form 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 form 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 form 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.
One way to do this is to use the User Feature in Solution Manager.
The other possibility is to use the Sites per User form in the IFS EE client.
In this form, 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 form in IEE client.
Time and Attendance related Information Sources are not used by Analysis Models for Applications 9. 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 built 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.