locked
Multiple PWAs and Secure Store Service RRS feed

  • Question

  • Hi,

    I was wondering what the correct configuration is if you have multiple PWAs on different web applications, and want to configure reporting and the secure store service.  This is on Project 2010.  I did see on a Project 2013 article a note stating:

    "If you have multiple instances of Project Web App and you want to isolate reporting access for each, you will need a Report Authors group for each instance of Project Web App."  - same thing for viewers.

    Does an additional Secure Store Target Application have to be created for the new authors/viewer groups or do you add the groups rights on to the original ProjectServerApplication Target ID?   Are there security implications to this?

    Thanks.  I can't seem to find any information on this topic and would like to know how to configure this.

    Jason


    JK

    Wednesday, June 19, 2013 6:19 PM

Answers

  • Hello, I would create a report authors and report viewers AD group for each PWA instance, you could use the same secure store target app for all PWA instances. The additional report viewers groups isn't required for each PWA instance but would keep the set up consistent. Paul

    Paul Mather | Twitter | http://pwmather.wordpress.com | CPS

    • Marked as answer by Jkokoty3 Thursday, June 27, 2013 3:09 PM
    Wednesday, June 19, 2013 6:58 PM

All replies

  • Hello, I would create a report authors and report viewers AD group for each PWA instance, you could use the same secure store target app for all PWA instances. The additional report viewers groups isn't required for each PWA instance but would keep the set up consistent. Paul

    Paul Mather | Twitter | http://pwmather.wordpress.com | CPS

    • Marked as answer by Jkokoty3 Thursday, June 27, 2013 3:09 PM
    Wednesday, June 19, 2013 6:58 PM
  • It really depends on the goal. When our team worked on this feature, we had military contractors who can't see beyond one project to companies where everyone can see everything. The SecureStore profile allows you to set up a data access profile for an authorized group of users. The credentials associated to the profile can be used to access one or more data sources. However, if you aren't authorized to use the SSS profile, you get no data. Using different ad groups for viewers is necessary but it is incomplete security.

    In the situation of multiple PWA instances, does it matter if users from one instance can see data from another instance? If so, I'd set up two SSS profiles with different AD groups associated to each profile. They can both use the same underlying credentials. This way, some enterprising Excel jockey can't just replace the SSS id in the spreadsheet and connection string and get into the other database.

    Hope this helps.

    Treb Gatte | @tgatte | http://AboutMSProject.com

    • Proposed as answer by Jesper Arnecke Saturday, June 22, 2013 10:33 AM
    Friday, June 21, 2013 2:06 AM
  • Hiya,

    Also it would just make troubleshooting easier to keep things separated..

    Saturday, June 22, 2013 10:34 AM
  • I agree with Treb's answer.  Typically different site collections and/or PWA have different security requirements and such it makes more since to have a Secure Store for each PWA site.

    Cheers!


    Michael Wharton, MVP, MBA, PMP, MCT, MCTS, MCSD, MCSE+I, MCDBA
    Website http://www.WhartonComputer.com
    Blog http://MyProjectExpert.com contains my field notes and SQL queries

    Sunday, June 23, 2013 4:42 PM
  • Treb,

    I think the discussion is over simplified, perhaps.

    Since the Project Server Code is looking for a Secure Store entry named: ProjectServerApplication and two different Secure Store entries cannot use the same Target ID, you would also have to create a new instance of the Secure Store service Application.  And a service group, you would have to associate your web application (your new PWA instance) with this service group with the new SSS.

    The option to share a single Secure Store and Target ID entry with multiple AD groups listed in the Membership seems appropriate.  PWA will manage the correct user segregation between instances.  This is architecturally more feasible.  Security is not compromised, b/c the ODC files given to the users instance of PWA point to their respective PWA databases (reporting in particular).  the malicious user would not have access to reports against other databases.  Remember, Secure store does not manage Authors access, only readers.  So they would not benefit from running XL directly either, even if they knew other report DB names, unless they also were in an Authors group so arranged in SQL logins with permissions to other databases.  So multiple AD groups for Authors and Readers, properly arranged will accomplish the goal and use a single Secure Store Target Application ID.

    Please let me know if I missed something.

    and I see (by reading again) that Paul suggested just that.  Nice Paul.


    Thanks, Eric S. Pcubed


    • Edited by ErockP3 Monday, June 24, 2013 10:57 PM acknowledgement
    Monday, June 24, 2013 10:50 PM
  • Eric,

    The issue is that if you configure all instances to use the same Target Application profile, there is a way to update the SQL in Excel without triggering the refresh locally in the Excel client. This technique would allow a skilled individual to get access to data in other instances via the web without having author rights to those databases. The id associated with the Target Application profile has read access and that's all they need. Granted, the casual user won't know how to do this but that's not who we are guarding against.

    It's a best practice to create multiple Target Application profiles in SSS with different member groups per PWA instance. You don't have to create multiple instances of the service to accomplish this. The Target Application Profile name is easily changeable in the Excel files and templates. Once that is done, the user would be limited to their own instance. Most people I've worked with only have one instance so they never hit this.

    BTW, there's no magic around the ProjectServerApplication label. We had to pick a default name and that name won. Also, the Project code has no interaction whatsoever with this aspect as this is all straight up SharePoint. This is also why Project security has no bearing on data visibility in reporting.

    --Treb

    Treb Gatte | @tgatte |http://AboutMSProject.com

    Wednesday, August 28, 2013 7:31 PM
  • Thanks Treb,

    always more to it than first blush.


    Thanks, Eric S. Pcubed

    Thursday, January 16, 2014 6:37 AM