Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

I am an administrator for a new 4.1 SP2 deployment of BOBI.  We have various unique requirements which sometime present issues in implementation.  The current issue at hand is dealing with Scheduling to Destinations.  Specifically Email (SMTP).

Scheduling to Destinations allows users to schedule reports to any of the following 4 destination locations (as long as they are configured): BI Inbox, File Locations, FTP, and Email (SMTP).

There is a security setting which will allow you to grant or restrict scheduling to destinations.  This presents the first problem.  You cannot pick and choose for the 4 destinations.  It is All or Nothing.  An alternative would be to simply not configure the destination which you do not want to use.  This is a good option until you have a need for that particular option.

We chose (at first) to not configure Email.  The reason for this brings us to problem number two.  Security!  There are numerous problems with this destination.

First, it allows the user to set the value on who the email is being sent from thus "spoofing" the sender.  It does not have the capability to set the from field to a placeholder such as %SI_EMAIL_ADDRESS%.  Even that would not fully address the issue because configuration settings also do not allow you to lock/protect the field.  Even if you could default it to %SI_EMAIL_ADDRESS% (which would pull the users email address from their account info) without protecting the field, the user could still change the value.

Second, it allows for attachments which seems harmless.  Unless the data within your environment needs to be protected.  If the user has access to secure data and sends it out as an attachment it is no longer secure.  It is not even encrypted!  There is no option to password protect the file.  No options to provide a digital signature or certificate.  One way around this is to use the placeholder %SI_VIEWER_URL%.  This provides a link in the email to download the document.  Seems like a good alternative.  Forces the protection of the document to only users with an account.  This does require additional account maintenance and depending on your licensing model it may not be feasible.  As an administrator, there is no way to allow email but disable adding an attachment.  So if the add attachment option cannot be restricted then there is no way to allow email and limit/force the users to use the %SI_VIEWER_URL%.

We soon found that we had a small group of power users (5) which needed the capability to email as they were scheduling and delivering over 900 reports each month.  We needed a way to allow these 5 users to schedule to email without allowing the other 1500 users the same capability.  If we could find a solution to the adding attachments issue then we could allow all 1500 users to use email.  There is no way I could see to accomplish this short of SDK which I try to avoid as it only complicates patching and upgrading.

After a few days of thinking about our options here is what we have done to address the first issue of alacarte Scheduling to Destinations.

First we created an AdaptiveJobServer which did not have the Email destination configured.  This server was the only one the majority of our end users have access to.

Second, we cloned that AdaptiveJobServer.  Then we enabled and configured the Email destination, removed the end user groups which we did not want to email, and added the five power users which needed this capability.

In theory you could set up separate servers for each of the 4 destinations and grant/deny access accordingly thus providing you an alacarte option.  We have not gone this far yet.  This would potentially cause an issue with needing to know the correct server and specifying that server in the Server Scheduling Group settings.

This is still a work in progress.  If you have experienced anything similar or have a different approach please share!  I will update with our lessons learned as we go forward with implementation.