- This topic is empty.
- Posts
-
-
Forgot to add that I'm using vs 5.7
-
Hi Chele,
What do you mean by "data connections"?
If you mean the connection string then the connection string is encrypted and sits in a file on the server.Only administrators see the file. This data is not exposed in any SI web parts.
If you want to hide data in SI Web Parts then you can set security on the site/page/web part level.
If is still not clear please let me know.
-
Sorry I wasn't more specific. When you add any of the SI web parts and go to configure the system and service then when you go to the catalog, it shows you a list of all the stored proceedure calls. Is there a way to keep other users who may use the web parts from seeing that?
-
Hi Chele
Currently there is no restriction in place to protect the system integration metadata in ezEdit screen. However if you would like to see this in place, we can submit a feature request. I know this has been brought up before so it may be in our backlog. The feature request allows user to define SharePoint users/groups for the specific system/service configuration (explicit allow or prohibit). This restriction definition is guarded both by ezEdit when user design connection entity/operation/parameter as well as at runtime execution.
-
Yes for the feature request. Are there any work arounds that a system admin could perform in the interim?
-
For now, the workaround would have to be on your external data source side. Though we will still not have the ability to hide the system/service/operations from the site designer who has the capability of using ezEdit and define connections, it is possible to set up Pass Through or Windows Credential for the system integration connections so the external data source can verify and decline request from the credential that was sent to it.
Using SQL Server connection as an example, you could set up a system account in your SQL server and use windows credential with that account in Web Parts SI system configuration. Any user design and use the SI web part with this connection can get whatever data is allowed for that system account. For data that you want to protect from general user, you could set up accounts in SQL server with the specific grant permissions. Only user granted the permission is allowed to retrieve the data. By pairing the Web Parts credential (via Pass Through or Windows Credential) and database login accounts, you can achieve the security trimming you needed, though not the perfect way.
-
Wouldn't you need to have Kerberos set up to pass the Windows Credentials from the user to the SQL server?
-
We currently do not use Kerberos. We’re using some of the qsi web parts. Is there a way to keep individuals from other sites and\or site collections from seeing the data connections that we’ve set up in SI?
-
To avoid "double-hop" issue, yes, you need kerberos setup. Workaround is using mixed logins so to pass SQL logins rather than windows.
-
You must be logged in to reply to this topic.