Table of Contents
The Identity Management System (IDMS) provides access control capabilities for security relevant data. The current IDMS supports EOxServer with a native security component for HTTP KVP and POST/XML protocol binding as well as external components for SOAP binding. The system is based on other free and open software projects, namely the Charon Project, the Shibboleth framwork and the HMA Authentication Service. In the context of EOxServer, the SOAP support in the IDMS can be used to provide authentication and authorisation capabilities for the SOAP Proxy.
The IDMS uses two different schemes for authentication: The native EOxServer component relies on Shibboleth for Authentication, the SOAP components use the Charon framework.
The approach chosen for the SOAP part of the IDMS follows the OGC best practice document User Management Interfaces for Earth Observation Services for the authentication concept. The authentication part is following the ideas of the XACML data flow pattern: The IDMS authorisation part consists of a Policy Decision Point (PDP, here represented through the Charon Policy Management And Authentication Service) and the Policy Enforcement Point (PEP, represented through the Charon PEP Service). The following figure gives an overview of the IDMS SOAP part:
The HMA Authentication Service, or Security Token Service (STS), and the Charon PEP components were both modified in order to be compatible. This is a result of the ESA project Open-standard Online Observation Service (O3S). The STS now also supports SAML 2.0 security tokens, which the PEP components can interpret and validate. The IDMS supports trust relationships between identity providers and enforcement components on the basis of certificate stores.
The HTTP or native EOxServer part of the IDMS uses exactly the same scheme for authorisation as the SOAP part, but uses the Shibboleth federated identity management system for authentication.
Two requirements must be met to use the IDMS in this case:
- A Shibboleth Identity Provider (IdP) must be available for authentication
- A Shibboleth Service Provider (SP) must be installed and configured in an Apache HTTP Server to protect the EOxServer resource.
A user has to authenticate at an IdP in order to perform requests to an EOxServer with access control enabled. The IdP issues a SAML token which will be validated by the SP.
Is the user valid, the SP adds the user attributes received from the IdP to the HTTP Header of the original service requests and conveys it to the protected EOxServer instance. The whole process ensures, that only authenticated users can access the data and services provided by EOxServer. The attributes from Shibboleth are used by the EOxServer security components to make a XACMLAuthzDecisionQuery to the Charon Authorisation Service.
The following services are needed both for the HTTP and the SOAP security part:
Download locations for the IDMS components:
- Shibboleth: http://shibboleth.internet2.edu/downloads.html
- CHARON Authorisation Service: http://www.enviromatics.net/charon/ or http://packages.eox.at/idm/
- Security Token Service: http://packages.eox.at/idm/
- PEP Service: http://packages.eox.at/idm/
- EOxServer: http://eoxserver.org/wiki/Download
The following software is needed to run the IDMS:
- A LDAP Directory.
- Java JDK 6 or higher
- Apache Tomcat 6 or higher
- Apache Axis2 1.4.1 or higher
- MySQL 5
- Apache HTTP Server 2.x
The following software is needed to build the IDMS components:
The IDMS uses a LDAP directory to store user data (attributes, passwords, etc). You can use any directory implementation, supporting the Lightweight Directory Access Protocol (v3).
Known working implementations are:
A good graphical client for LDAP directories is the Apache Directory Studio.
- The Charon services need the
acs-xbeans-1.0.jardependency in the
\libfolder of your Axis2 installation (presumably the
webapps/axis2of your Apache Tomcat installation).
- Furthermore, you have to activate the EIGSecurityHandler in the
Global Modules section of your axis2 configuration
- You may configure the logging for the services in the Log4J configuration
Both, the Security Token Service and the PEP service make use of Java
Keystores: The IDMS uses Keystores to store a) the certificate used by the
Security Token Service for signing SAML tokens and b) the public keys of those
authenticating authorities trusted by the Policy Enforcement Point. The
keytool of the Java distribution can be used to create and manipulate
The following command creates a new Keystore with the password :secret: and a suitable key pair with the alias :authenticate: for the Security Token Service:
keytool -genkey -alias authenticate -keyalg RSA -keystore keystore.jks -storepass secret -validity 360
The following command exports the public certificate from a key pair :authenticate: to the file
keytool -export -alias authenticate -file authn.crt -keystore keystore.jks
The following command imports a certificate to a Keystore:
keytool -import -alias trusted_sts -file authn.crt -keystore keystore.jks
You can use the Apache HTTP Server as a proxy, it will enable your services running in Tomcat to be accessible over the Apache server. This can be useful when your services have to be accessible over the HTTP standard port 80:
First you have to enable
Create a virtual host in your
<VirtualHost *:80> ServerName server.example.com <Proxy *> AddDefaultCharset Off Order deny,allow Allow from all </Proxy> ProxyPass /services/AuthenticationService ajp://localhost:8009/axis2/services/AuthenticationService ProxyPassReverse /services/AuthenticationService ajp://localhost:8009/axis2/services/AuthenticationService </VirtualHost>
ProxyPassReversedirectives have to point to your services. Please note that the Tomcat server hosting your services must have the AJP interface enabled.
For the installation and configuration please refer to the HTTP or SOAP specific documentation: