UNICORE Security PT Work Plan

This page provides overview of the goals which are to be realized by this PT.

High-level goals:

  1. Support for AAI EMI infrastructure in UNICORE (new development).
  2. Enablement of site-central authorization with Argus in UNICORE.
  3. Interoperability with SAML-VOMS; It is related to the effort to extend SAML-VOMS to make it a UVOS replacement, however SAML-VOMS development is not covered in this PT.
  4. Adoption of common, standardized libraries.
  5. Research towards the best possible interoperability with other middlewares in terms of security.
  6. Maintenance of the existing components of this PT.
  7. Support of a priori assessment whether a given entity has access to a given grid site(s).
  8. Optimization of UNICORE security stack performance with usage of communication sessions and credentials storage.

The first four points of the above list are in the priority order. We assess (1) as an important feature for end-users, making UNICORE usage significantly easier. (2) can provide additional capabilities for UNICORE administrators, however features provided by site-central authorization service are not crucial for UNICORE as all typical authorization related operations can be achieved with users' attribute management (what is already available in site-central manner). Activities (3) and (4) bring no added value for UNICORE users and administrators however should slightly reduce software maintenance effort. Currently maintenance of related libraries requires minimal effort.

The priority of the goals 5. and 6. is hard to compare with the rest. Maintenance must be obviously done. The significance of increased interoperability is hard to assess as we are not yet sure to what extend it can be done and what are actual needs of the end-users (with respect to opportunities that need to be identified).

The last two goals are research topics. Resolving the issues backing the goals is important but it is hard to provide detailed roadmap before an approach is clearly defined. Those efforts also depends on other EMI actions as common authentication library and Argus integration.

Detailed plan

Support for AAI in UNICORE (new development).

1.1) Verification of the UNICORE server side with respect to short lived certificates: support for DN-based identification of entities everywhere.

-> Deliverable: list of required changes in the server-side code for SLC support (may be empty).

-> Effort estimate: 1PM

-> Estimated time: M10

1.2) Implementation of the changes identified in 1.1) and coordination of implementation of those changes in components managed by other PTs (if needed).

-> Deliverable: Demonstration showing that SLC change does not interfere with usage of any of UNICORE server components.

-> Effort estimate: 0-2PM

-> Estimated finish time: M11

1.3) Identification of requirements from UNICORE client side tools for EMI AAI solution.

1.4) Development of EMI-AAI client-side library for UNICORE useful for both HiLA, UCC and URC.

Enablement of site-central authorization with Argus in UNICORE.

2.1) Providing policy requirements covering current default policy and typical use-cases for ARGUS along with a list of relevant authorization attributes.

-> Deliverable: The list and requirements document.

-> Effort estimate: 0.25PM

-> Est. finish time: M3

2.3) Creation of Argus callout in XACML-entity. -> Deliverable: Callout available, demonstration showing that Argus receives proper request, and that valid answer is accepted by the callout. Demonstration should be done with Unicore/X using the callout. NOTE: Statement that this function is actually useful in practice is not required as to do this we need Argus implementing (2.1) and (2.2) lists.

-> Effort estimate: 1PM

-> Est. finish time: M8

Interoperability with SAML-VOMS
It is related to the possibly to use SAML-VOMS as a complete replacement of UVOS however SAML-VOMS development is not covered in this PT.

3.1) Agreement on common set of attributes.

-> Deliverable: The common set of attributes accepted by the SAML-security group.

-> Effort estimate: 0.25PM

-> Est. finish time: M4

3.2) Agreement on profile defining attribute encoding and querying details which are important in grid environment (based on Chemomentum+OMII Europe work?).

-> Deliverable: The (input to) the profile published by the SAML-security group.

-> Effort estimate: 1PM

-> Est. finish time: M6

3.3) Client side tools for the push mode authorization.

3.4) Implementation of the SAML profile (start in the first year)

3.4) Developing a consistent processing model for pushed credentials. Currently support for pushed credentials is implemented but not widely used and there are several unresolved issues as behaviour in case of expired assertions.

3.5) Testing client and server implementation of the push mode with SAML-VOMS.

3.6) Testing server pull mode with SAML-VOMS.

Adoption of common, standardized libraries

4.1) Evaluation of opensaml as a replacement of samly2 library.

-> Deliverable: Statement on applicability (missing features, stopping bugs)

-> Effort estimate: 1PM

-> Est. finish time: M9

4.2) Replacement of samly2 library (if feasible, i.e. if opensaml provides necessary features, what is likely).

4.3) Taking part in creation of the specification of a detailed list of features for common authentication library.

-> Deliverable: Detailed list of features required from the UNICORE side

-> Effort estimate: 1PM

-> Est. finish time: M3

4.4) Taking part in definition of the interface of the common authentication library.

-> Deliverable: (input to) the API definition of the library

-> Effort estimate: 1PM

-> Est. finish time: M7

4.5) Taking part in implementation of the common authentication library.

4.6) Adoption of the EMI common authentication library.

Research towards the best possible interoperability with other middlewares in terms of security.
5.1) Identification of possible convergence points and precise definition to what level interoperability is possible assuming different delegations models.

5.2) Implementation of identified interoperability opportunities.

Maintenance of the existing security components of this PT:
XACML entity, uas-authz, UNICORE gateway, XUUDB and UVOS (until repleaceable by VOMS), security libraries: securityLibrary, xfire-secutils, xfire-secutilsWithDSig, crl-util, samly2, xml-security-java6 (and auxiliary) plus all newly created/unified/changed.

-> Deliverable: Defined by quality assurance team from SA?.

-> Effort estimate: 3PM/year

Support of a priori assessment whether a given entity has an access to a given grid site.

Required for brokering and supporting client tools.

Optimization of UNICORE security stack performance with usage of communication sessions and credentials storage.

-- KrzysztofBenedyczak - 12-Dec-2010

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2010-12-12 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback