{"id":729,"date":"2008-10-15T20:51:45","date_gmt":"2008-10-16T01:51:45","guid":{"rendered":"http:\/\/blogs.devhorizon.com\/reza\/?p=729"},"modified":"2008-10-17T18:56:21","modified_gmt":"2008-10-17T23:56:21","slug":"ssrs-2008-integrated-mode-security","status":"publish","type":"post","link":"https:\/\/blogs.devhorizon.com\/reza\/2008\/10\/15\/ssrs-2008-integrated-mode-security\/","title":{"rendered":"SSRS 2008 integrated mode: Security"},"content":{"rendered":"

When you configure SSRS 2008 to run in SharePoint integrated mode, the way you configure authentication and permissions in your SharePoint Web application matters a lot, because:
\n<\/span><\/p>\n

    \n
  1. That’s what report server uses to control access to report server items and operations.
    \n<\/span><\/li>\n
  2. This would dictate what kind of security model you can use in your reports data sources to access external data sources.
    \n<\/span><\/li>\n<\/ol>\n


    \n<\/span><\/p>\n

    Figure 1: Authentication settings for your Web application is an important step in the integration<\/em>
    \n<\/span><\/p>\n

    Having SharePoint to perform authentication and access control doesn’t mean that SSRS is unaware of the security context under which reports gets executed. The report server uses an internal component called security extension (only available in SharePoint integrated mode) to query WSS object model to find out whether or not the requested resource or operation can be performed for the passed in security context<\/u>.
    \n<\/span><\/p>\n


    \n<\/span><\/p>\n

    Figure 2: Security extension queries SharePoint OM to check for permissions<\/span><\/em><\/p>\n

    <\/p>\n

    Okay, let me take one question that I often get asked right after I say the above sentence. The question is :
    \n<\/span><\/p>\n

    Q<\/strong>) If SharePoint object model is only available on the server on which SharePoint is installed, how does security extension queries SharePoint? Via Web services?<\/span><\/p>\n

    A<\/strong>) Nope. Remember, as part of the installation prerequisites on the report server you need to have a minimum installation of SharePoint(Web front end). This makes the object model available on the SSRS machine when they are installed on two separate boxes.<\/span><\/p>\n

    \"MinimalWFEInstallation\"<\/a><\/p>\n

    Below is just the proof. Uninstall SharePoint bits from the Report server\u00a0 or configure it to Integrated mode without having the Sharepoint bits there and here is the error you get when hitting the report server:<\/span><\/p>\n

    The configuration paramter SharePointIntegrated is set to true but Share Point Object Model cannot be loaded.<\/em><\/p>\n

    \"SharePointObjectModelCannotbeLoad\"<\/a><\/p>\n

    In short, you set, manage and leverage the security model implemented by SharePoint, but report server just performs the following checks:
    \n<\/span><\/p>\n

      \n
    1. Connection Request Validation Check<\/strong>: Whether or not the incoming connection request has access to the report server. If Kerberos is enabled, this request would be under the Windows identity of the user, otherwise in case of NTLM or FBA it is a complete different story and a bit complicated. Here you go:
      \n<\/span>If Kerberos is not enabled, incoming connection request is under the security context of a trusted account (SharePoint application pool identity). For this validation check, WSS OM is NOT queried. When connection request arrives at the report server, report server compares the application pool identity to the account information that the report server retrieved from the SharePoint configuration databases when the report server started and recognized it as a trusted account. On the report server this account is also added as a windows user and is given a local policy of the “Impersonate a client after authentication” property. This account is ONLY used to establish a connection and for impersonating SPUser object on the report server with absolutely no access to the any of the reports or operations.<\/span><\/li>\n
    2. Permission Check<\/strong>: Whether or not the incoming security context has required permission to do what it asks to do \u2013 for example executing a report. If Kerberos is enabled this incoming security context would be under the Windows identity of the user, otherwise (for NTLM or FBA) it is the SPUser object which SharePoint impersonates<\/span> on behalf of the current logged-in user. For this validation check, WSS OM is queried by security extension.
      \n<\/span><\/li>\n<\/ol>\n

      Very simple! Eh? \ud83d\ude42<\/span>
      \n<\/span><\/p>\n

      Well, when you think about it, it makes much sense to off-load some of the responsibilities from SSRS side to SharePoint side and have SharePoint take over all report-related security. SSRS authorization model (native mode) is not anywhere close to what SharePoint offers. Two big wins right off top of my head:<\/span> <\/span><\/p>\n