Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

Given that AGS does not allow enabling security on individual services, what is the best approach for hosting a mix of both secure and open services?

enter image description here

Update: we have abandoned AGS-based security because of its many flaws and capricious inconsistencies. Beware!

share|improve this question
    
This is a great topic, I'd be interested in knowing how you plan to serve your services because sometimes it is possible to do the security side on an html wrapper of your viewer and have different viewers for different users. Although it doesn't secure your services, it makes them "hidden" in a way unless the user just checks your REST directly, which is highly unlikely, although possible of course. –  MLowry Jul 12 '11 at 14:21
    
@MLowry - We're using Silverlight+REST, OpenLayer+REST, and Geocortex+ADF. –  nw1 Jul 12 '11 at 14:55
1  
The open services are easy, just add the 'Everyone' role to your store, and add it to 'Allowed Roles' of the services you wish to be available to everyone. help.arcgis.com/en/arcgisserver/10.0/help/… This is still a good question, as AGS security is a bit of a chore, and I would like to see what the community has come up with. –  wwnick Jul 12 '11 at 16:17
    
@wwnick - With one caveat, that this is not supported with Windows roles. According to your link, it requires a role with the magical name of "*", which can only be created when using a provider. But this sounds like the most direct solution. –  nw1 Jul 12 '11 at 18:33

3 Answers 3

Previously I used user groups to assign view/edit permissions to the rdbms.
as MLowry described I just created maps in virtual directories that delineated users.
I have been wanting to dig in and learn more about the security in ags10.
In the new arcgis scenario it looks like you would use those same user levels on the enterprise and then utilize several folder levels to create services in to seperate maps so users won't get errors.

share|improve this answer
up vote 0 down vote accepted

Best answer was wwnick's comment, referring to the Everyone role as documented here, although the Anonymous role is really more appropriate for an open service.

share|improve this answer

A Option you can have is to build your secure layers in a seperate instance of ArcGIS, then acess this via proxy, Then force that layer to load by LayerDefinitions; then build that list of layer definitions based on your security provider.

My current project relies on a custom single-sign-on solution, then once the user is authenticated they are passed to the MapViewer which has the critical layers load dynamically into the map based on code that looks at there rights and capabilites via there login-token and sets the layerdefs appropriatley.

All of my standard base stuff is exposed via a public instance; but then the secured users load there layers based on industry/group assignments.

share|improve this answer
    
If I understand correctly you are talking about client-side code dictating which layers are visible to the user, so what stops the knowledgeable user from changing which layers they see? –  tomfumb Aug 18 '12 at 0:23
    
The client side app simply uses the right request to display; you still need to pass to the client the right properties for the query, this you can make as complex as you want including hashing a value that is the keys to the layers with filters to display. –  D.E.Wright Aug 18 '12 at 3:30
    
This still doesn't sound very secure - relying on the client to only make requests they're supposed to assumes a lot of trust in your users. It seems like you're leaving the door unlocked and hoping no one will realise they can just walk in off the street. With any kind of public-facing site you have to lock it twice and remove the door handle. –  tomfumb Aug 20 '12 at 16:33
    
@tomfumb - that is a very simplistic view of it, we have to find solutions based on the tools that are exposed. The use of the other code in conjuction with the JS/API hooks allows the user to get to the application. I never said that was the only element. We require you to pass through our secure portal using a HTTPS SSO to get your token to be used to get to your layers which are all bound in the service. –  D.E.Wright Aug 20 '12 at 16:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.