BI Publisher Siebel Security Model & Siebel LDAPSecAdapt

Since the release of Siebel and BI Publisher a new security model is introduced in BI Publisher, Siebel Security. When using the Siebel Security model, BI Publisher relies on Siebel for its authentication and authorization. Siebel employees can be authorized to generate reports by assigning them the necessary responsibilities. Oracle officially only supports the Siebel Security model when using DB Security for Siebel and the use of the BI Publisher LDAP security model when using LDAP Security Adapter for Siebel. In fact Oracle names the combination of Siebel LDAPSecAdpt with BI Publisher Siebel Security model a 'mixed authentication method' and has not certified and/or validated this method yet. The BI Publisher LDAP Security model has one disadvantage, it requires hardcoded LDAP Security Groups like XMLP_DEVELOPER. Groups names like these probably do not follow your company naming standards for LDAP objects and are therefore not allowed. If so this immediately makes BI Publishers LDAP Security Model not suitable for implementation in your production environment. If you have a better understanding of how the
Siebel Security model works, it is fairly simple to implement this security model when using the LDAPSecAdpt for Siebel.

When generating a Siebel Report in a connected environment the communication between Siebel and BI Publisher can broadly be split up in three steps; getSecurityModel, getTemplateParameters and runReport. In the first step, getSecurityModel, Siebel requests the Security model that has been applied by BI Publisher. Based on the received response, the Siebel component defines the implementation of the following steps. When the Siebel Security Model is configured as BI Publishers security model it responds with 'SIEBEL'. In the following steps the TemplateParameters for the selected report template are requested from BI Publisher and the report is run.

Two sub-steps, BIP-Siebel/Security:Authenticate and BIP-Siebel/Security:GetRoles can be distinguished in the getTemplateParameters and runReport steps. These sub-steps provide the authentication and authorization of the Siebel user during the report generation. Because the getTemplateParameters and runReport steps are two separate webservice calls, the Siebel user is authenticated and authorized twice during the generation of one report. When the XMLP Reports Server component (Siebel) makes the getTemplateParameters or runReport webservice call, the user-id of the employee and his/her password is supplied in the webservice call to BI Publisher. BI Publisher then uses the by Siebel provided username and password to authenticate and authorize the Siebel user by passing these credentials in the BIP-Siebel/Security:Authenticate and BIP-Siebel/Security:GetRoles webservice calls to Siebel. The webservice call BIP-Siebel/Security:Authenticate is handled by the EAI ObjectManager which delegates the authentication to the configured security adapter. If the user is authenticated successfully, BI Publisher makes the BIP-Siebel/Security:GetRoles webservice call which returns the users responsibilities to BI Publisher. Keep in mind that the selection of responsibilities by the EAI Objectmanager is based on User-ID, the User-ID always is stored in uppercase and queries are case-sensitive. This is an important detail when you execute the BI Publisher reports to be executed via a Workflow Process or through scripting as described in Doc ID 823360.1, 'Siebel BI Publisher Reports Business Service'. When setting the user-id used by the Workflow Process or script, the user-id must be defined in upper-case. If the user-id is not defined in uppercase, the user-id will be authenticated successfully, but not receive any roles and therefore not able to generate the report.

Because one picture can say more than a thousand words;

blog comments powered by Disqus