locked
CustomData property in the connection string when viewing a dashboard on SharePoint RRS feed

  • Question

  • Hi

     

    I've read Nick's blog about connection security with CustomData at http://nickbarclay.blogspot.com/2008/01/pps-data-connection-security-with.html and have a question regarding deploying dashboards on SharePoint. 

     

    From what I understood, if I use CustomData security I need to do the following steps:

     

    1) Modify the web.config stored on SharePoint server in C:\Inetpub\wwwroot\wss\VirtualDirectories\80 directory.  Make sure that the <appSettings> section contains the following data:

        <add key="Bpm.ServerConnectionPerUser" value="False" />
        <add key="Bpm.UseASCustomData" value="True" />

     

    2) Create a dashboard containing elements that use SSAS data source.  Deploy that dashboard to SharePoint.

     

    3) Give a user permissions for SSAS cube that he needs. 

     

    Considering all that, I suppose that when this user goes to the SharePoint library to view the dashboard, the SharePoint service identity will be used to connect to SSAS, and the metadata in the connection log should contain <CustomData> tag with the user's login.  Am I right? 

     

    If I arrange everything like that, what permissions should the SharePoint identity have on SSAS?  Does it need to have permissions to administer/process/read the cube used by the data source?  What are the minimum permissions on SSAS server that the SharePoint identity should have in order for this scenario to work?  Is the idea in having SharePoint access everything and different users identities be limited to specific dimensions, etc?

    Friday, February 15, 2008 9:24 AM

All replies

  • Hi Varya,

     

    You're almost there. Some pointers.

     

    1. Modify the web.config.... Correct, although you may want to also modify the Monitoring web service and Preview site web.config files too so that you can test the functionality outside SharePoint.

     

    2. Create a dashboard.... Also correct.

     

    3. Give a user permissions... Incorrect. The whole point of this functionality is that you do not have to configure user permissions to the cube itself. The custom permissions per user are held in the source relational database that the cube gets its data from; have a good read of the articles I referenced in that blog post. Dimension member access is granted on-the-fly by the dimensional security MDX code contained in the SSAS roles. This is the code that takes the user information held in the CustomData field and applies it to the dimension members.

     

    The only account/s that need access to the cube are the SharePoint and Monitoring server app pool identity accounts. The application pool identity accounts should be granted minimal permissions on the cube, preferably Read. Remember, though, that it is these app pool identity account that is making the connection to the PPSMonitoring system database too (to get the dashboard definition and permissions etc.), so appropriate permissions need to be granted there too (BPMDeveloper database role). 

     

    Cheers,

    Nick

    Friday, February 15, 2008 9:50 PM
  • Hi Nick,

     

    Have you tried to do what they did in the articles you referenced?  I am trying to implement the solution advised at http://hccmsbi.blogspot.com/2007/08/implementing-user-specific-security-in.html and keep getting different errors.  For instance, I'm now unable to deploy my model site because I'm told that the DSV doesn't contain a definition for my new table with the users.  I can't really understand this error because I previously added that table to the DSV.

     

    Did you have any problems yourself if did the steps described in the blog?

     

    Thanks!

    Tuesday, February 19, 2008 12:03 AM