-
Notifications
You must be signed in to change notification settings - Fork 8
Metrics Service Security
The Metrics Service allows an administrator to customize the type of security that is implemented for authentication and authorization. The Metrics Service uses a pluggable Spring Security 3.0.2 solution and ships with sample security plugins that can be used as a basis for building a custom security plugin. Familiarity with Spring Security will help administrators customize the Metrics Service.
While this guide is not intended as a comprehensive guide to basic security concepts, Web security, or Spring Security, there are a few key concepts that must be understood in order to use the sample Metrics Service security plugins and the Metrics Service security plugin architecture.
First are the twin concepts of authentication and authorization, known colloquially as auth & auth. Authentication essentially means providing proof that the user is exactly who they are presenting themselves to be. Some authentication techniques include a username/password combination, an X.509 certificate, a CAC card and card reader, or various bioMetrics solutions. Authorization, on the other hand, is determining the specific access rights that an individual user should have. Consider the following:
- “Bill is allowed to log into the system – prove that you are Bill,” is a matter of authentication.
- “Bill has access to resources,” is a question of authorization.
By necessity, authentication occurs before authorization. Once authentication is satisfied, the Metrics Service moves to authorize. It has two authorization concepts at this time. First, the Metrics Service needs to know whether or not a user has administrative access via ROLE_ADMIN or is only a regular user via ROLE_USER.
The samples included with the Metrics Service are not production quality samples. They are intended to provide examples on how to easily integrate various security solutions with the Metrics Service, not to provide a comprehensive security solution out of the box or a comprehensive tutorial on Spring Security. It is expected that each organization using the Metrics Service will examine its security guidelines and enterprise-wide authentication/authorization solutions and produce a Metrics Service security plugin that is both secure and meets its standards. That solution can then be shared among Metrics Service deployments within the organization.
Most of the examples provided contain various obvious security hazards—for example, the X.509-only and CAS + X.509 plugins contain a list of usernames, roles, and user groups on the hard drive in plain text in a properties file. The CAS+X.509 file contain passwords in plain text. These are undeniable security hazards. Keep this in mind when using the samples.
The Metrics Service ships with three simple sample security plugins that are described in this section:
MetricSecurityContext.xml – This contains the default security implementation for the Metrics Service. It uses a PKI certificate for authentication. If no certificate is provided, it redirects the user to login using CAS as a fallback. CAS stores valid usernames and passwords in a users.properties file on the server. Once the user has been authenticated, the authorization information is provided in the same properties file, users.properties.
To use a non-default security configuration for authentication, replace the active security-based .xml files, (for example, \apache-tomcat-7.0.21\lib\MetricSecurityContext.xml) with the \owf-security\MetricSecurityContext_cert_only.xml file.
OzoneConfig.properties proxies some of the CAS properties that can be customized by specific organizations. Update the corresponding values in OzoneConfig.properties to change where the default CAS server, CAS login and CAS logout point.
MetricSecurityContext_cert_only.xml – This contains the X.509-only security implementation for the Metrics Service. It uses a PKI certificate for authentication. If no certificate is provided, the user is denied access to system. The users' roles (admin and user) are stored in users.properties for authorization.
MetricSecurityContext_cert_ldap.xml – This contains an X.509/LDAP security implementation that uses X.509 for authentication and then performs an LDAP-based lookup to determine the user’s authorization. Authorization includes the user’s role (ROLE_ADMIN or ROLE_USER).
The owf-security-project.zip directory contains the following supporting resource in /src/main/resources/conf.
- apache-ds-server.xml — A sample.xml file used by Apache Directory Server (ApacheDS, an open-source LDAP v3-compliant embeddable directory server) that sets up the initial directory service partitions with the test data.
-
testUsers.ldif — An LDAP Data Interchange Format test file that can be imported to set up test entries that match the certificates bundled with the Metrics Service. This test data includes testUser1 and testAdmin1, roles
ROLE_USERandROLE_ADMIN, and two example groups, group1 and group2. It is designed to work with the sample user PKI certificates that ship with the Metrics Service.
The MetricSecurityContext files in the /owf-security directory offer multiple examples of security options. These are intended as examples and should in no way be used in a production environment. As mentioned previously, the default security implementation provides an X.509 certificate authentication with CAS fallback. When using the default security module in a testing environment, the user must present a valid X.509 certificate, or a valid CAS login, in order to gain access to the Metrics Service.
For each available security option, there is a specific .xml file which must be installed. Installing a new security module is accomplished in just a few simple steps:
Note: The following instructions act as a summary for installing individual security modules. Depending on the module being used or tested, module-specific instructions may be needed. See \owf-security\owf-security-project.zip\readme.txt for the installation details specific to each module type. Additionally the summary instructions below assume that the default installation is being used with Tomcat as the application server/container.
- Stop the application server. An administrator can accomplish this by double-clicking the \apache-tomcat-7.0.21\bin\shutdown.bat or \shutdown.sh file, depending on the operating system in use.
- Delete any security-based .xml (MetricSecurityContext*.xml) files that might currently be present in the
\apache-tomcat-7.0.21\libdirectory. - Copy the appropriate .xml file from
\owf-securityto the application server’s class path. When running Tomcat, the classpath is the\apache-tomcat-7.0.21\libdirectory. - Remove CASSpringOverridesConfig.xml from
\apache-tomcat-7.0.21\libif it was deployed there. - Remove CAS from the Metrics Service instance if switching to a security plugin that does not use CAS by deleting cas.war and the cas directory if it exists from
\apache-tomcat-7.0.21\webapps. - Restart the application server by double-clicking either \apache-tomcat-7.0.21\start.bat or \start.sh file, depending on the operating system in use.
Note: The following instructions describe how to remove CAS from the Metrics Service instance. This should only be done if switching to the X.509 sample, the X.509+LDAP sample, or a custom plugin that does not require CAS.
The MetricSecurityContext_cert_only.xml file eliminates CAS as a fallback to authentication. If the user does not present a valid X.509 certificate, they will be denied access to the system. Authorization is provided by the users.properties file.
To use this security plugin, replace the active security-based .xml file (e.g., \apache-tomcat-7.0.21\lib\MetricSecurityContext.xml) with the MetricSecurityContext_cert_only.xml file, which can be found in the \owf-security directory. Follow the directions above to stop the Metrics Service, remove CAS, and restart.
The MetricSecurityContext_cert_ldap.xml file provides X.509 client authentication with an LDAP-based lookup to determine the user’s authorization. The default configuration attempts to connect to a local installation of Apache Directory Server on port 10389 using the default system account. It determines the user’s authorization by searching on the full, distinguished name presented in the X.509 certificate.
Sample configuration files are provided to set up an Apache Directory Server with user information that matches the X.509 certificates provided with OWF, including a server configuration XML file and an LDAP Data Interchange Format file (*.ldif) which loads users to match the distinguished names in the certificates. For more information about LDAP, refer to http://directory.apache.org/.
Included is a sample Apache DS server XML file called \owf-security\owf-security-project\src\main\resources\conf\apache-ds-server.xml. It adds the partition owf-1 to Apache DS. To do so, it adds the following line of XML to the XPATH spring:beans\defaultDirectoryService\partitions:
<jdbmPartition id="owf-1" suffix="o=Ozone,l=Columbia,st=Maryland,c=US" />
It is also necessary to load the sample data into the directory service. The OWF team has provided a sample LDIF file, called \owf-security\owf-security-project\src\main\resources\conf\testUsers.ldif.
Note: Downloading the Apache Directory Studio may be helpful.
It is also straightforward to modify how the LDAP search is conducted for both user roles and user groups. In order to run the plugin with the default data no adjustment is required. However, to modify the plugin to run off of a different data set, adjust ozone-security-beans\LdapBeans.xml. It is recommended that the administrator get the plugin working from the default data set before trying to migrate to a different data set by modifying the LDAP queries.
To use the X.509(cert)/LDAP security implementation, replace the provided MetricSecurityContext.xml file with MetricSecurityContext_cert_ldap.xml, and follow the directions in the Installing the Security Module section to stop and restart the server and to remove CAS.