Server Object Extensions (SOEs) give developers the ability to utilize the extensive geoanalytical capabilities of ArcObjects within an ArcGIS Server service. They also provide a framework that enables access to custom functionality in a service through the standard Web service protocols SOAP and REST. Enabling Web access to an SOE is well documented in the ArcObjects SDK.
ArcGIS Server Web services can also be secured using token or Web server authentication methods. Since SOEs are can be enabled on a specific service, authentication rules configured on a service apply to all of its extensions, including custom SOEs. This poses the question: if an SOE is enabled on a secured Web service, can the authenticated user be retrieved within the SOE? Yes, in ArcGIS Server 10 this is possible.
Use the C# code provided below as an example. Basically, within your SOE code get the current server environment and cast to IServerEnvironment2 to gain access to UserInfo. If authentication is enabled for ArcGIS Server Web services, each request to a service will be associated with an authenticated user. UserInfo will contain the user name and roles within which that user is present for the current request. Note, when Web server authentication is based on Windows users and groups, the user name is in the format domain\user.
Unfortunately, REST SOE's hosted on ArcGIS Server for .NET require ArcGIS Server 10 service pack 2 for this to function. ArcGIS Server 10 service pack 2 will be available for download on the ArcGIS Resource Center soon.
Can u talk a little bit about how to go about configuring the web server security restricting access to the SOEs. Which web service/app should we start messing with? I had tried this a while ago without luck on the ArcGIS web app itself under IIS. Is this something coming new in 10.1 which i heard from the devsummit videos?
Also, is it possible to secure different different (map etc..)services or SOE services differently?
Securing Web services in ArcGIS Server involves defining authentication rules on services. Since an SOE must extend a service, any security settings on the service will apply to its extensions. Note, you can interrogate user info within a custom SOE to change how the SOE responds, but this is not something you do with ArcGIS Server administration... you use code logic.
Note, the .NET REST handler in ArcGIS Server 10 has a bug where the user info is not available as part of the server environment (the code above will not work). This bug is fixed in ArcGIS Server 10 sp2, due out soon.
Hope this helps,
Thank you for the response. Another question along the same lines. Earlier I had tried to simply the security setup by trying to ascertain if the web site issued form authentication token 'aspxtoken' on the request header can be used by the server object also for authentication. The only difference was that AGS expected the token to called 'token'. I changed that setting on my website so that form authentication token was called 'token' instead of 'aspxtoken'. But that didn't seem to so it. AGS seems to generate its own kinda token instead of reusing the token utilities in ASP.NET. I would great if I could use the same machine key in both my web site and the AGS .NET handlers so that users who are authenticated with the website also automatically get access to the AGS services... Make any sense? Would appreciate ur input here...
Unfortunately the token functionality in ArcGIS Server is completely internal and unique. The encryption logic is not public, so sharing a token with your Web site and the AGS .NET handler is not possible. On a side note, we do support single sign-on with Web server secured services (e.g. integrated auth).
Hi Rex, thanks for the post. I was wonder:
Can I, based on the membership information, modify the Server Object's map (like adding filters to layers) and thus alter the returned map image?
Is it a performance issue to connect to a sql server database inside an SOE (like if I needed more info about that user's identity in the system)?
Post a Comment