Securing Services using the Spring Framework on 10.2

NicCampbell · ‎11-09-2013

I'm currently trying to use the spring security framework in order to provide the authentication and authorization for my organization's arcgis web services. At the moment we use ldap to secure our services but our business requirements have us looking for a more robust alternative.
I have tomcat on a redhat server that is currently running the web adaptor as well as a simple spring security project but I'm missing the part where I can make use of spring to secure the webservices. The web adaptor is running at http://<web server name>/arcgis/rest/services while the spring security is running at http://<web server name>/sampleSpringSecurity. The spring security does its job just fine for all paths that fall under sampleSpringSecurity, but that does me no good when it comes to securing the web adaptor. I'm experienced with java but my exposure to spring has been limited and my experience with web adaptors is almost nonexistent. Any suggestions would be greatly appreciated.

Thank You,

Nic

LeoDonahue · ‎11-12-2013

At the moment we use ldap to secure our services but our business requirements have us looking for a more robust alternative

Such as both ldap and container managed security? Or..?

I have tomcat on a redhat server that is currently running the web adaptor

May I ask whether you have just looked into applying security constraints in Tomcat to the URLs you want to secure? The security constraint would lookup users/passwords in whichever realm you configure.

I would also suggest that if are going to use container managed security or any security that requires a user to login, enable SSL in your container. It's easy to do with a self signed certificate, or you can buy one. I don't know your intended setup though.. is this internal only?

NicCampbell · ‎11-12-2013

Such as both ldap and container managed security? Or..?

May I ask whether you have just looked into applying security constraints in Tomcat to the URLs you want to secure? The security constraint would look up users/passwords in whichever realm you configure.

I would also suggest that if are going to use container managed security or any security that requires a user to login, enable SSL in your container. It's easy to do with a self signed certificate, or you can buy one. I don't know your intended setup though.. is this internal only?

Thanks for the reply! I'll start out with container managed security. Some of the execs would like to keep their current login information so we might need to add in our ldap configuration at some point but that's for a later date. SSL is definitely a must. I'm just waiting on our IT group to buy the certificates. Ultimately the project will be used by users around the world. I'll have to look into the tomcat security constraints. There's a good chance I'll eventually want to restrict access to methods as well as URLs, which spring has the capability to do.
Over the last few days I've been trying to figure out the best way of securing the services and the two ideas I've come up with are (in order of preference):

Add the spring configuration directly to the web adaptor war file (arcgis.war) using Maven's overlay. Overlay just saves me the trouble of manually adding the spring security project to the war file. I tried the proof of concept yesterday and it worked beautifully. The proof of concept uses the example project, chapter03.06-calendar from the book "Spring Security 3.1". They provided an instant database setup using H2, but once everything was working I tweaked the datasource to use our sql server. Ultimately I'd like to use spring CAS.

Use the spring security service to forward requests to arcgis from the user and return the response. In this case, the user would never have direct access to the arcgis. Ldap would just contain a user, let's say arcgisUser, with access to all services. The spring security project would determine if a user had access to a particular URL. If he did, it would make the request to arcgis along with a token generated using arcgisUser and return the response. Otherwise, the user would receive an error message.

Cheers,

Nic

LeoDonahue · ‎11-12-2013

Where are you going to deploy arcgis.war?

NicCampbell · ‎11-12-2013

Where are you going to deploy arcgis.war?

I've been deploying the web adaptor to a redhat server using the instructions found here. Our IT department was kind enough to perform the steps in the "Configuring the ArcGIS Web Adaptor." link at the bottom of the setup instructions. The URL we'll expose to our users will be something like: https://{springSecurityProjectName}/arcgis/rest/services.

LeoDonahue · ‎11-12-2013

How does Spring Security restrict access to:

http://yourserver/arcgis/rest/services

?

I know you said you were using maven overlay, but won't that only apply to your SpringSecurityProjectName web app?

Step #6 of that link you posted says follow your Java application server to deploy the arcgis.war. When you do that, the /arcgis path is open to everyone. Right?

NicCampbell · ‎11-12-2013

How does Spring Security restrict access to:

http://yourserver/arcgis/rest/services

?

I know you said you were using maven overlay, but won't that only apply to your SpringSecurityProjectName web app?

Step #6 of that link you posted says follow your Java application server to deploy the arcgis.war. When you do that, the /arcgis path is open to everyone. Right?

In the security.xml file of the spring security project, I just added

<intercept-url pattern="/arcgis/**"
                access="hasRole('ROLE_ADMIN')"/>

This is subject to change but it did allow me to prove that visiting https://{myserver}/arcgis requires the user to login. All spring overlay does is allow me to add to the arcgis.war file. The result would be the same if I just took the contents of my spring security war file and manually moved them into the arcgis war file. I originally deployed just the arcgis war file without any security. At that point, the services were exposed to everyone. It was only after merging in the spring security project that I was able to secure the services.

LeoDonahue · ‎11-12-2013

I see.

I haven't used Spring for anything yet. It looks like it gives you a custom springSecurityFilterChain Filter to secure the URLs.

What happens to http://yourserver/arcgis if your SpringSecurityProjectName web app crashes?

It seems like all this does is move the security configuration from the web container to the Spring Framework?

NicCampbell · ‎11-12-2013

I see.

I haven't used Spring for anything yet. It looks like it gives you a custom springSecurityFilterChain Filter to secure the URLs.

What happens to http://yourserver/arcgis if your SpringSecurityProjectName web app crashes?

It seems like all this does is move the security configuration from the web container to the Spring Framework?

That's an excellent question. The answer to that may very well cause me to use option 2 instead of option 1. I'll post again if I get a definitive answer. My hope would be that since they're running under the same java process, crashing one would crash the other. We'll have some white hat testers come in at some point and I'll offer this up as a potential exploit. Something I could do to ensure bringing down the security service would prevent access to the arcgis services would be to steal part of option two. I would allow users to login using spring security but only the arcgisUser would have access to arcgis services. The spring security application would have the token generated by arcgisUser to access the url. If it crashed, the user would need to login as arcgisUser to gain access to the site (which they wouldn't be able to do). This would involve ensuring the user was never directed to a url containing the token but I believe it's possible. The advantage I've seen to moving the security configuration to the spring framework is that it allows you to provide authorization down to the method level. The spring framework seems pretty powerful but since I'm pretty green I'll abstain from making any claims beyond saying, yes, it allows you to move the security configuration out of the web container.

LeoDonahue · ‎11-12-2013

Just so I'm on the same page here. You want to secure user access to making requests to your arcgis.war URL. Or are you trying to add security to an application that consumes the arcgis.war?

I ask because you have mentioned using tokens and also securing your web app down to the method level. The method level of your application or the method level of say an ArcGIS Geometry service?