SOA3 HowTo

From Gcube Wiki
Revision as of 17:55, 7 May 2013 by Ciro.formisano (Talk | contribs) (Connector)

Jump to: navigation, search

Introduction

SOA3 (Service Oriented Authentication, Authorization and Accounting) is composed of four REST web services:

  • Authentication Service
  • Authorization Service
  • User Management Service
  • Connector Service

A detailed section about SOA3 Architecture is provided in Data e-Infrastructure Policy-oriented Security Facilities: this page aims at providing a quick guide on the installation and configuration processes.

Installation steps

The four services are packaged in four wars running on Apache Tomcat 7, in particular:

  • authService.war (org.gcube.vo-management.soa3.authentication.rest) is the Authentication Service
  • policyService.war (org.gcube.vo-management.soa3.authorization.policymanagementservice) is the Authorization and Policy Management Service
  • userService.war (org.gcube.vo-management.soa3.usermanagement.rest) is the User Management Service
  • soa3Service (org.gcube.vo-management.soa3.connector.service) is the Connector Service

In addition to Tomcat 7, in order to use Authentication and User Management Services, an LDAP Directory is needed. There are no particular requirements on the LDAP Directory: the tests have been performed on OpenDS 2.2. For the Authorization and Policy Management Service, [|Argus Authorization Framework] 1.5.0 and above is needed.

Configuration

Authentication, Authorization and UserManagement

There is a single, common configuration file for Authentication and User Management Services:

$CATALINA_HOME/conf/soa3/soa3.properties.

The file contains the following properties:

  • LDAP_URL the url of the LDAP with the user list (default "ldap://127.0.0.1:1389")
  • LDAP_BASE the LDAP search base (default "o=mojo")
  • LDAP_USER_DN the administrator DN (default "cn=Directory Manager")
  • LDAP_PASSWORD the administrator account password (default "secret")


The following properties are used only by Authentication Service They are concerns federated authentication and the connection with Shibboleth Service Provider (look at Shibboleth site and Shibboleth installation giude in gCube):

  • CA_CERT = CA Key or keystore folder for assertion validation (default /etc/grid-security/certificates)
  • ASSERTION_SIGNATURE_VALIDATION Assertion signature validation enabled (default true)
  • ASSERTION_TIME_VALIDATION Assertion time validation enabled (default true)
  • SAML_ASSERTION_SOURCE_URL SAML Source host (default http://localhost/Shibboleth.sso/GetAssertion)


Further information on Shibboleth deployment and configuration can be found in Shibboleth and gCube

The following properties are used for Authorization and Policy Management services:

A step by step guide to install Argus Authorization Framework is provided here

Connector

The connector uses two configuration files:

  • $CATALINA_HOME/conf/soa3/connector.properties (mandatory)
  • $CATALINA_HOME/conf/soa3/services.properties (optional)

The file connector.properties contains the following properties:

  • SOA3_ENDPOINT the endpoint of the other services of soa3 (default http://localhost:8080)
  • SERVICE_NAME the name of the current instance (default soa3)
  • AUTHENTICATION_SESSION the lifetime of a security session in minutes (defautl 5 min)
  • CERT_FILE x509 certificate in pem format (default /etc/grid-security/hostcert.pem)
  • KEY_FILE x509 key in pem format (default /etc/grid-security/hostkey.pem)
  • TRUST_DIR x509 truststore (default /etc/grid-security/certificates)
  • TRUST_FILE_EXTENSION extension of the ca files in the truststore (default .0)
  • AUTHORIZATION_ENABLED default true
  • GCUBE_SCOPE the scope for IS queries (default /gcube)

If in the entire infrastructure a single SOA3 instance exists, using the certificate and keys in the standard folders (or not using certificates and keys because they are managed by Apache HTTP Server), the default configuration works well.

The file services.properties, if exists, contains a list of key=value representing the names and the endpoints of other soa3 instance in the infrastructure. This configuration is needed if a security ticket must be propagated and validated in the infrastructure across multiple SOA3 instances (more details in SOA3 Connector).

Security

For security reasons, it is recommended to run the container in HTTPS mode. It is strongly suggested to use Tomcat combined with Apache HTTP Server and mod_jk, setting a certificate trusted by the GHNs.