The integration between IFS Applications and SQL Server Reporting Services has three secured layers. The user is first authenticated when he/she accesses reports on the server and then when the report is executed. During report execution the user will be authenticated before any data can be retrieved from the data source. If the data source is a cube, it is required that it has been processed and filled with data, before the report execution. This document will explain the different layers and how security can be set up to get the best seamless experience for end users.
These are the three basic authentication layers involved.
Once the activity BrowseBiMyReports is granted, users that access My Reports in Enterprise Explorer connects to the report server through HTTP requests that are directed to a URL that is reserved for and registered in a report server instance. You can change this connection to use HTTPS instead so that users access the report server over an encrypted channel. This is recommended by Microsoft since some of the authentication process is in clear text.
The request is authenticated by the Report Server Web service. Users are authenticated using their Windows domain credentials and integrated security by default, but you can also configure the report server to use basic authentication. See more details about this >>.
After the user is authenticated, the report server checks for permissions that authorize access to report server content and operations. Permissions are defined in role assignments that describe which tasks a user can perform. Each user who connects to the report server must have role assignments defined on the account that he or she uses to connect to the report server. It is recommended to setup user groups to simplify this. See the guidelines on how to set up authorization for some of the IFS specific folders >>
Reports can contain embedded data sources or connect to shared data sources stored on the report server. To retrieve data used in a report, the report server must connect through these data sources to the underlying data database, web service or XML document. When the report runs, the report server opens the connection, executes the query, waits for the dataset to be returned, and then closes the connection before continuing to the next processing step.
Connections to external data sources are first defined in the report and then managed independently of the report after the report is published. At runtime, these connections are made by the report server on behalf of the user who is running the report. The report server passes the credentials to the data source. For any given data source connection, the report server can get credentials in one of the following ways:
The report server does not validate connection or credentials when they are created. To verify whether connection properties are valid, you must run the report.
We have provided an example of how you can set up a shared data source directly to the IFS database. IFS does not recommend such a connection due to performance reasons, however, it may be used in certain situation when online data is required. We recommend that you use the second security option above. Option one will not work for Oracle connections unless you have set up Oracle to handle Windows Integrated Security and Kerberos delegation. This is not an easy task but is explained in a white paper here >> Option three will work but keep in mind that the same credentials will be used for all the users that run the report. This will overrule any security set up in Oracle.
All IFS samples get data from a cube located in MS Analysis Services. This type of data source only permits Windows Authentication. Therefore, there are few limitations with regard to the setup of security. Typically, the reports will connect to Analysis Services for the purpose of executing a set of MDX Statements to fill the dataset in the report. Cubes are access protected and authorization can be set up on partition level, dimension level and cell level. However, in our sample-cube we have restricted the access of the entire cube. This will probably be adequate in most situations, but you may modify it as required in a way that ensures the security of sensitive data.
The cube must be processed in order to be updated or populated. This means that the cube must access the underlying data model and retrieve data from data views (usually an IFS Information Source). It is suggested that you configure the cube to access this data as a super user and then configure the security on the cube instead. The cube will then contain all data required to calculate aggregated values etc.
MS SQL Reporting Services (also called Report Server) runs its own process. It provides report management and report viewing as a service. This is provided over a web interface and via a special endpoint used by the .NET framework. IFS Enterprise Explorer interact with both. My Reports uses web and Report Viewer in .NET to view quick reports and dashboards.
The connection used by the report viewer and the web interface are both secured and therefore, users must provide credentials to be allowed access. The following security models can be used:
After installing SQL Server and Reporting Services, Windows Integrated Security will be active by default. In this mode, Reporting Services will look your current windows user up in the active directory. If the user is logged in it will be treated as trusted and allowed access without having to present username and password. IFS Enterprise Explorer can be set up to allow windows users automatic access. This is called running IFS EE in SSO (Single Sign On) mode. The users will not have to provide credentials for IFS EE or in Reporting Services. Reporting Services will be considered as a part of the application. This is the recommended way of running the External Report Integration.
In Basic Authentication mode, you must provide your credentials again when accessing My Reports from the Navigator in Enterprise Explorer. This can be used to support Oracle users in Reporting Services. However, it will have the following limitations:
If you want to configure Reporting Services to use basic authentication, a set of instructions must be followed. Refer the Microsoft help >>.
Another possibility that can be used for demo environments and for customers who use database logon and require a quick installation, is to use a combination of windows integrated security and basic authentication. You can keep your database logon for IFS Applications and also keep the standard setup for SSRS and SSAS. In this case, users will log into IFS Enterprise Explorer as a database user and then switch to the windows user once they start using reporting tools. There will be a mismatch between the users in the different applications which may create confusion. It is possible to overcome the above confusion by using the windows users to authorize cubes and reports. This method is not recommended.