WebService in MOSS

编写自定义SharePoint Web Services之二

http://kentcj.vicp.net/wiki/Wiki%20Pages/编写自定义SharePoint%20Web%20Services之二.aspx



Location:
BlogsSharePointing - The Act of Collaborating
   
Posted by: Steve Walker 6/7/2006

Someone asked me how to have their custom web service access SharePoint securely without having to give the end users administrative access to SharePoint. The service would work fine when run by an administrator for SharePoint but when a normal user would use it, ti would crash and tell them they were not authorized. I have had this question asked a few times so I thought it worthy of a blog post so maybe others can benefit as well.

Ok.. So here would be the options for this:
 
Option 1 - Preferred Method -
  • Create a "Service Account" for your service (or use an existing one). This needs to ne a network Account.. not a local machine account.
  • Create a "Service Principal Name" for your service/user account in your AD. This must be run by a domain admin. setspn.exe is the utility that you need to use for this. THis is a crucial step for Authentication to work properly. setspn.exe -r http/machinename domain\accountname is the syntax I believe but I would have to look that up for you. If you are using a CNAME in DNS and have a hsot header for IIS, you need to register http/hostheadaer as well.
  • Create an Application Pool in IIS for the web service (or use an existing one that is already running under your "service account") and assign the idenitity of the app pool to our service account.
  • Set up a web site in IIS to host your "Custom Web Service" (Or use one that you can assign to the application pool we created.
  • Run this service under a specific "Service Account".. NOT network service or localsystem !! You can run multiple service applications under a single service account but this account will hold your provleges into SharePoint. You cannot use these generic well known accounts to access resources accross the network.
  • Add the "Service Account" used in the application pool to the IIS_WPG, STS_WPG groups on the server that is hosting your custom web service
  • Turn OFF impersonation in your web service.. but leave windows authentication on. You can still access who is calling you to run security checks in your web service code but we will use the Application Pool identity to connect to SharePoint (or SQL databases, etc..)
  • Add the Service Account to the "Administrative" account for Sharepoint on the SharePoint server.
  • Run your web service code. It access SharePoint using the credentials that you supplied in the app pool :-) Your end users hit your service and you call sharepoint. thuse providing a security boundary between them and your sp admin access ;-) Your service can return the objects from sharepoint to your users for the most part.. or you could make a smaller object to pass back to your app if you don't need the entire object. would be much more performant that way as the SP objects are a bit "Fat on the wire" so to speak :-)
This would be the most secure way to do it and would avoid the end users having to be administrative over Sharepoint. Only code that YOU publish to your service tier would be available to them to execute. I would recommend security checks in your service tier to ensure users have rights to invoke your service. At a minimum set the security at the IIS level in your web service.
 
Option 2 (Not preferred)
  • Turn off impersonation in your web service tier. Keep windows auth on
  • in your code, elevate your privelges by impersonating an administrative user account in your code. Impersonate Admin User, Attach Credentials to the call to the sp web services. revert to old credentials.
  • Store Administrative user name and password in config on your server somewhere.. encrypted of course ;-)
either method will accomplish your goals. I prefer option 1 as it utilizes the security infrastucture that should already be in place in your network. It allows you to avoid storing your administrative SharePoint credentials for your application. In a production environment, your developers don't even need to know the administrative credentials at all to deploy thier code (if you are a public company that is a concern)
 
I sometimes take security a bit farther than some developers... but I guess that what comes when you used to be a security guy for a living ;-)
 
Happy SharePointing !!


Location: BlogsSharePointing - The Act of Collaborating    
Posted by: Steve Walker 6/7/2006

Someone asked me how to have their custom web service access SharePoint securely without having to give the end users administrative access to SharePoint. The service would work fine when run by an administrator for SharePoint but when a normal user would use it, ti would crash and tell them they were not authorized. I have had this question asked a few times so I thought it worthy of a blog post so maybe others can benefit as well.

Ok.. So here would be the options for this:
 
Option 1 - Preferred Method -
  • Create a "Service Account" for your service (or use an existing one). This needs to ne a network Account.. not a local machine account.
  • Create a "Service Principal Name" for your service/user account in your AD. This must be run by a domain admin. setspn.exe is the utility that you need to use for this. THis is a crucial step for Authentication to work properly. setspn.exe -r http/machinename domain\accountname is the syntax I believe but I would have to look that up for you. If you are using a CNAME in DNS and have a hsot header for IIS, you need to register http/hostheadaer as well.
  • Create an Application Pool in IIS for the web service (or use an existing one that is already running under your "service account") and assign the idenitity of the app pool to our service account.
  • Set up a web site in IIS to host your "Custom Web Service" (Or use one that you can assign to the application pool we created.
  • Run this service under a specific "Service Account".. NOT network service or localsystem !! You can run multiple service applications under a single service account but this account will hold your provleges into SharePoint. You cannot use these generic well known accounts to access resources accross the network.
  • Add the "Service Account" used in the application pool to the IIS_WPG, STS_WPG groups on the server that is hosting your custom web service
  • Turn OFF impersonation in your web service.. but leave windows authentication on. You can still access who is calling you to run security checks in your web service code but we will use the Application Pool identity to connect to SharePoint (or SQL databases, etc..)
  • Add the Service Account to the "Administrative" account for Sharepoint on the SharePoint server.
  • Run your web service code. It access SharePoint using the credentials that you supplied in the app pool :-) Your end users hit your service and you call sharepoint. thuse providing a security boundary between them and your sp admin access ;-) Your service can return the objects from sharepoint to your users for the most part.. or you could make a smaller object to pass back to your app if you don't need the entire object. would be much more performant that way as the SP objects are a bit "Fat on the wire" so to speak :-)
This would be the most secure way to do it and would avoid the end users having to be administrative over Sharepoint. Only code that YOU publish to your service tier would be available to them to execute. I would recommend security checks in your service tier to ensure users have rights to invoke your service. At a minimum set the security at the IIS level in your web service.
 
Option 2 (Not preferred)
  • Turn off impersonation in your web service tier. Keep windows auth on
  • in your code, elevate your privelges by impersonating an administrative user account in your code. Impersonate Admin User, Attach Credentials to the call to the sp web services. revert to old credentials.
  • Store Administrative user name and password in config on your server somewhere.. encrypted of course ;-)
either method will accomplish your goals. I prefer option 1 as it utilizes the security infrastucture that should already be in place in your network. It allows you to avoid storing your administrative SharePoint credentials for your application. In a production environment, your developers don't even need to know the administrative credentials at all to deploy thier code (if you are a public company that is a concern)
 
I sometimes take security a bit farther than some developers... but I guess that what comes when you used to be a security guy for a living ;-)
 
Happy SharePointing !!
posted @ 2007-10-23 23:41  AutodeskWebDev  阅读(431)  评论(0编辑  收藏  举报