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.
–
MLowryJul 12 '11 at 14:21

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.
–
wwnickJul 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.
–
nw1Jul 12 '11 at 18:33

3 Answers
3

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.

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?
–
tomfumbAug 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.WrightAug 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.
–
tomfumbAug 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.WrightAug 20 '12 at 16:52

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.