Past Event: Nov 09, 2023
Retrouvez Boxfusion Consulting lors de l’événement Oracle Applications Unlimited Days, en France
1 min read
A while ago we were asked to introduce Active Directory authentication into a Siebel 8.1 and BI Publisher 10g implementation. Enabling Siebel on ADSI is straightforward – the fundamentals haven’t really changed in the last ten years – but we were curious to find out whether there were any issues in getting BI Publisher up and running with Siebel on ADSI, and indeed whether – once we had it up and running – there would be any limitations on functionality.
The manner in which BI Publisher authentication is configured means that when reports are executed via requests from Siebel, BI Publisher can authenticate the requesting user by calling back to Siebel to confirm the user’s credentials. If Siebel is using ADSI authentication, effectively BI Publisher is using ADSI authentication too, albeit indirectly via Siebel. Note however that users logging into BI Publisher via its administrative interface would continue to be authenticated via BIP’s internal authentication mechanism.
An alternative configuration is for BI Publisher to be set up to use ADSI authentication directly for both users requesting reports and users logging in to its UI to perform administration.
We were interested in understanding if there would be different challenges under the two scenarios – our instinct told us there would be – so we set up both scenarios and tested them.
So, we initially tried out BI Publisher with its authentication settings configured to use the Siebel Security Model, while Siebel used ADSI to authenticate its users. In such a scenario, the expected functionality would be that:
1) Users logging into Siebel would be authenticated via ADSI; 2) Any reports requested by Siebel users and executed in BI Publisher should cause BI Publisher to request authentication via Siebel (and hence indirectly via ADSI); and 3) Users logging into the BI Publisher administrative interface would be authenticated via BI Publisher’s own authentication mechanism.
For this particular scenario, getting BIP to authenticate via Siebel (point 2 above) is the only real risk area. The first – and obvious – pitfall when trying to achieve this is if, when setting up Siebel to use ADSI, the administrators decided to ADSI-enable only the Siebel Object Managers supporting the Siebel user interface.
When BIP authenticates using the Siebel Security Model, it does so over Web Services. Ergo, the EAI Object Manager must also be set up to use BIP. Though typically in any ADSI-enabled Siebel environment the EAI Object Managers would generally be ADSI-enabled too, we have worked on client sites in the past where EAI OMs have remained using Database Authentication – and in such a setup BI Publisher could not work using the Siebel Security Authentication Model.
Once the EAI Object Managers have been set up to use ADSI, users can generate reports from Siebel without issue. However, in our tests a second, more-challenging issue arose around scheduled reports. Although users could schedule reports for execution successfully, when the report ran, it would fail every time.
This is down to the fact that, for scheduled reports, BI Publisher ignores some of its settings when utilising the Siebel Security Model. That isn’t to say that the Siebel Security Model isn’t being used – it is – but the BI Publisher scheduler engine uses different credentials settings to those used for processing reports requested synchronously. Finding these settings was a little painful, and once found, it became clear that there is a security weakness in the authentication approach that must be considered in any implementation.
Once we had reports fully working with BI Publisher using the Siebel Security Authentication Model, we then enabled BI Publisher to use ADSI directly. Again this was straightforward – it was simply a case of setting up users and groups within ADSI to support the roles required to allow BI Publisher to work, and configuring BI Publisher’s authentication settings.
Attempting to login to BI Publisher through its user interface was successful, and all of the administrative functions worked as expected. The next tests therefore were to determine whether runtime execution of reports would be successful.
Just as in the last scenario, reports requested synchronously by users worked perfectly, but scheduled reports consistently failed when executing – something that BI Publisher reported as being down to permissions.
We knew that the BI Publisher to ADSI integration had been set up appropriately, and all credentials were correct, so we were confident that it wasn’t down to permissions. Understanding the actual problem took a while, but once we had discovered the root cause, scheduled reports worked as expected.
Our experiences indicate that BI Publisher (with or without ASDI/LDAP) integrated with a Siebel system using ADSI/LDAP works as expected without any obvious loss of functionality under both authentication scenarios. There are, however, some security issues to take into account when using the Siebel Security Authentication Model.
Configuring Siebel and BI Publisher to work together with ADSI/LDAP is, however, tricky with a number of pitfalls, and overcoming these challenges requires a deep understanding of the applications and their authentication mechanisms.
For clients setting up ADSI/LDAP authentication themselves on BI Publisher and Siebel, we’d recommend allowing at least a week of effort to overcome the challenges that are thrown up.
For clients looking for help getting an environment enabled on ADSI/LDAP, Boxfusion Consulting will get you up and running within a day.
1 min read
5 min read
5 min read