ESGF_Tutorial_Securing_The_Dashboard
This tutorial describes how the ESGF security infrastructure, and in particular the access control filters, can be used to secure a generic web application running within a Tomcat servlet container. The general technique involves placing a chain of servlet filters in front of the web application which intercept any HTTP request to the application, and force the following operations (see Figure):
- Require the user to authenticate with openid and password, by redirecting the user to the local Openid Relying Party (ORP) application, and subsequently to the user Identity Provider (IdP) of choice
- Verify that the authenticated user is authorized to access the requested resources, by querying a configured SAML Authorization Service (AzS)
- Enforce the authorization statement from the AzS by sending an HTTP 404 ("Access Denied") response if the user was not authorized.
All filters are configured in the web application deployment descriptor ( _ WEB-INF/web.xml _ ).
As an example, we will secure the ESGF Dashboard, which is a web application available at the URL [ http://<esgf_node>/esgf-dashboard/ ](http://<esgf_node
/esgf-dashboard/) which contains restricted functionality that can be run only by the _ local _ root administrator. So in this example the user will log in with the _ local _ rootAdmin openid ( [ https:///esgf- idp/openid/rootAdmin ](https://github.com/ESGF/esgf.github.io/wiki/|esgf- idp|openid|rootAdmin) ) through the _ local _ IdP, and will be authorized by the _ local _ AzS. If we wanted to secure a different web application, the IdP and AzS components could in principle be remote services, not necessarily running on the same ESGF node (while the ORP would still need to be running locally).
Figure: Software components involved in securing the Dashboard web application. In this case, all components are running within the same Tomcat servlet container.
Unfortunately, the Open SAML libraries used in the authorization process have a lot of dependencies, so the following jars must be placed in the WEB-INF/lib directory of the secured application (all these jars are available for example in the lib directory of the _ thredds _ application):
- commons-collections-3.2.1.jar
- commons-logging-1.1.1.jar
- commons-logging-api-1.1.jar
- esgf-security-1.4.7.jar
- esg-orp-1.2.5.jar
- joda-time-1.6.jar
- log4j-1.2.14.jar
- opensaml-2.3.2.jar
- openws-1.3.1.jar
- serializer-2.9.1.jar
- slf4j-api-1.5.6.jar
- slf4j-log4j12-1.5.6.jar
- spring-2.5.jar
- spring-webmvc-2.5.jar
- velocity-1.5.jar
- xalan-2.7.1.jar
- xercesImpl-2.9.1.jar
- xmlsec-1.4.2.jar
- xmltooling-1.2.2.jar
- XSGroupRole-1.0.0.jar
The authentication filter must be configured first in the security chain. It intercepts all requests and, if the user has not authenticated already, it will redirect to the ORP application. Note that the ORP must be running on the same host of the secured web application, because the proof of authentication is passed as a _ cookie _ , which has host domain scope. Note that in the example below, authentication will not be required for HTTP requests to ancillary resources, such as cascade style sheets ( _ .css _ ) and images ( _ .png _ , _ .gif _ , _ .jpg _ ). The filter initialization parameters must be customized for your specific deployment.
<filter>
<filter-name>authenticationFilter</filter-name>
<filter-class>esg.orp.app.AuthenticationFilter</filter-class>
<init-param>
<param-name>policyServiceClass</param-name>
<param-value>esg.orp.app.RegexPolicyService</param-value>
</init-param>
<init-param>
<param-name>openidRelyingPartyUrl</param-name>
<param-value>https://test-datanode.jpl.nasa.gov/OpenidRelyingParty/home.htm</param-value>
</init-param>
<init-param>
<param-name>trustoreFile</param-name>
<param-value>/esg/certificates/esg-truststore.ts</param-value>
</init-param>
<init-param>
<param-name>trustorePassword</param-name>
<param-value>my secret password</param-value>
</init-param>
<init-param>
<param-name>authenticationNotRequiredPatterns</param-name>
<param-value>"[^?]*(/|(?<=\.(png|jpg|css|gif|js))(\?.*)?)"</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>authenticationFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
The authorization filter must be configured immediately after the authentication filter. It uses an implementation of _ [ AuthorizationServiceFilterCollaborator ](https://github.com/ESGF/esgf.github.i o/wiki/AuthorizationServiceFilterCollaborator) _ to establish the user authorization. In this case, the implementation supplied is _ SAMLAuthorizationServiceFilterCollaborator _ , which will send the authorization query to the configured SAML Authorization Service. The SAML Authorization Service can in principle be any implementation of the ESGF security specification, but in particular the standard authorization service that is deployed on an ESGF node is already pre-configured to only allow access to all URLs that contain the string _ esgf-dashboard _ to the local root administrator. So, for this particular example, it is important to use the SAML authorization service deployed on the same ESGF node as the Dashboard application.
<filter>
<filter-name>authorizationFilter</filter-name>
<filter-class>esg.orp.app.AuthorizationFilter</filter-class>
<init-param>
<param-name>authorizationServiceClass</param-name>
<!-- <param-value>esg.datanode.security.app.NoAuthorizationServiceFilterCollaborator</param-value> -->
<param-value>esg.orp.app.SAMLAuthorizationServiceFilterCollaborator</param-value>
</init-param>
<init-param>
<param-name>authorizationServiceUrl</param-name>
<param-value>
https://test-datanode.jpl.nasa.gov/esgf-security/saml/soap/secure/authorizationService.htm
</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>authorizationFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Note that if the web application required the user only to authenticate, but not to be specially authorized, the authorization filter could be configured with the _ [ NoAuthorizationServiceFilterCollaborator ](https://github.com/ESG F/esgf.github.io/wiki/NoAuthorizationServiceFilterCollaborator) _ instead.
The enforcer filter must be configured last in the security chain. Its purpose is simply to verify that the user has been properly authorized to access the requested URL by the upstream filters, and if not, to send an HTTP 404 (Access Denied) response.
<filter>
<filter-name>enforcererFilter</filter-name>
<filter-class>esg.orp.app.FilterAuthorizationEnforcerer</filter-class>
</filter>
<filter-mapping>
<filter-name>enforcererFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
The instructions above have been codified in the esgf installer script _ ( esg-node ) _ to make things easier for you. Edit your web application's web.xml to have this tag in it [towards the beginning of the file of course] :
The installer will see this tag and replace it with the entries show above
and replace the necessary values resulting in a secured esgf p2p node webapp!
