nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Securing Services using the Spring Framework on 10.2

NicCampbell

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

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

LeoDonahue

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

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

Where are you going to deploy arcgis.war?

NicCampbell

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

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

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

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

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

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?

NicCampbell

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?

I'll be securing access to arcgis.war URL (web adaptor). I'll probably hold off on the token generation unless the security testing indicates there's a vulnerability. If there is one, I'll use a token generated in arcmanager at https://myserver.example.com/arcgis/tokens/generateToken and use that token to access the arcgis services. That token will be read by the spring project and applied to the url the user requests, provided that user has access to it. As far as securing methods go, it would probably only be useful for SOEs. I may be wrong though. It might be possible to secure a method within the geometry service.

LeoDonahue

I'm not sure what using Spring Security "and" tokens buys you. They both restrict access to the arcgis web services based on username/password.

You could deploy arcgis.war and enable security on it using ArcGIS Server Manager and get the same effect. The user consuming ArcGIS Server web service would need to authenticate, and at that point, you should be under HTTPS.

This is why I asked if you are securing the ArcGIS web service or the application that consumes your ArcGIS web service.

Your app can always generate a token in the background and supply those credentials to a secure ArcGIS web service without the user of your app even knowing. However, I get the feeling that you also want to secure the "app", which is fine - I get it, but I think your solution is trending towards unnecessary complication by fielding requests to arcgis.war via Spring Security.

Spring Security secures your app.
ArcGIS Server and possibly the web container can secure your ArcGIS Web services.

NicCampbell

I'm not sure what using Spring Security "and" tokens buys you. They both restrict access to the arcgis web services based on username/password.

You could deploy arcgis.war and enable security on it using ArcGIS Server Manager and get the same effect. The user consuming ArcGIS Server web service would need to authenticate, and at that point, you should be under HTTPS.

This is why I asked if you are securing the ArcGIS web service or the application that consumes your ArcGIS web service.

Your app can always generate a token in the background and supply those credentials to a secure ArcGIS web service without the user of your app even knowing. However, I get the feeling that you also want to secure the "app", which is fine - I get it, but I think your solution is trending towards unnecessary complication by fielding requests to arcgis.war via Spring Security.

Spring Security secures your app.
ArcGIS Server and possibly the web container can secure your ArcGIS Web services.

ArcGIS server manager is great but it doesn't meet our business requirements. We'll need to provide a way for hundreds of users external to our company to login to our website. The big catch is that depending on what type of subscription they have with us, they'll be restricted to different areas of the web services. Yes, they could be added to various groups but that requires more manual effort than I want to put forth. This, and other requirements I won't bore you with, rules server manager out as an option.

LeoDonahue

ArcGIS server manager is great but it doesn't meet our business requirements.

I would "not" suggest using it to define/create users. It can be configured to authenticate users to LDAP or a database. You can always write a front end to let users register under a certain subscription, but that process should be manually reviewed anyway.

NicCampbell

Our web adaptor is now secured by spring security rather than LDAP using the ideas posted previously in this thread. Just thought I'd post in case anyone was considering using it.

AdamKuran

Hi,

Similarily to you I have an Spring application that communicates to AGS. Application is secured but services are not and they have to.

I thought about some solutions and one of them is that you described as option 1.

As I suppose there is some kind of Single Sign On at least between your application and web adaptor (services)?

Is there a possibility to get your configuration? Or even some instructions?

(unfortunatelly I can't go to link that you wrote in post)

Adam

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.