ECL connector is a middle-ware component in ECL infrastructure that facilitates the implementation of ECL services and tools. ECL connector provides a simple solution that have API for ECL protocol, supports discovery and registration of services with the ECL registry. ECL API allows repository to configure one or more services (for e.g. Search/Expose, Request/Deliver etc.). These services act as different endpoints in SOAP container. (for e.g. Axis). ECL Connector provides two sets of API. A standard API to connect an existing repository to the ECL network (API to publish a service). The second set of API functions allows the developers to communicate with the ECL registry, and send and receive ECL messages to different ECL services (API to consume ECL services). Below is brief description of some terms used in this document.

1. ECL security profiles

   A security profile represents the a message description and how different security tokens are embedded in the message.

2. Security token

   A token is information data in form of string or bytes that could be inserted in a SOAP message. A security token is a token that will hold a particular type of security information. For example, Signature, Encryption, SAMLAssertion token, Username token etc.

3. ECL Registry

   The main role of ECL registry is to enable discovery of the repositories and services by the end-users as they become available. The secondary goal is to provide the end-user applications with the information that will allow them to communicate with the discovered repositories immediately without the need of modifying the application code. The registry is build on top of the UDDI registry.

4. Certification Authority

   ECL security profiles depend on PKI infrastructure. Certification authority is an entity that guarantees the link of public key to the holder of the private key of a particular key pair in PKI infrastructure. Each entity client or repository on ECL network that want to use ECL security profile would need an organizational Certification Authority.

5. Identity Provider

   Identity provider is an entity who is able to authenticate users and issue attributes. Each ECL client that want to use an ECL service using federated profile, should have an identity provider that could issue assertions.

Secure ECL Connector should provide API for securing the ECL service and ECL client. This document highlights important decision for implementing Secure ECL Connector.

Further this document is divided into two sections

1. Implementation decisions for secure ECL connector on client side

   1. Configurable security parameters

      Secure ECL connector should be implemented so that it could be used with different security profiles. Implementation for each security token should be kept separate from each other. Care should be taken so that profiles could be re used for different services using similar profiles.

   2. Security profile

      It is necessary that secure ECL connector are developed using particular types of security profile. This security profile would dictate the sequence of security tokens in the SOAP message. The profile would depend the service that this secure ECL connector would try to consume.

   3. Certification authority

      ECL Connector should have an entity that could authenticate and issue security credentials, for e.g. Certificate. ECL Connector should authenticate and obtain its security credentials from this entity. The validity duration and other parameters depends on the organization security infrastructure. But it is advisable to issue only short term security credentials (Certificate) to ECL Connector. Also, ECL Connector should discard all the credentials when disconnecting from ECL network, and re authenticate and re obtain on reboot.\

   4. Identity provider

      ECL connector should have an entity that could issue attribute assertions. This assertions hold information about person who authenticates to a Identity provider. ECL connector should request new attribute assertion for each request to achieve higher security. Caching attributes is highly discouraged.

2. Implementation decisions for secure ECL connector on repository side

   1. Security profile

      Developer should first decide on which security profile they want to implement to secure their service. ECL provides choice of two profiles, Repository controlled (Username) or Federated security (Assertion based) profile.

   2. Adopt a standard

      Security ECL connector could be implemented in different ways. It is advisable to implement according to some existing standard. OASIS Web Services Security is one such standard. WSS4J is an implementation of that standard. To get familiar with WSS4J please visit http://ws.apache.org/wss4j.

   3. Attribute verification

      Secure ECL connector would be responsible to authenticate incoming attribute assertion and authorize access to requested resource. This requires a mechanism to validate and verify attribute assertion. A policy engine is needed to authorize access to a resource. OpenSaml provides API to validate and verify attribute assertion, and XACML provides a frame work to develop policies to protect access to resource. A converter is needed to run incoming SAML based attribute assertions against XACML based policy engine.