Docstoc

Burton

Document Sample
Burton Powered By Docstoc
					From: Dan Blum [mailto:DBlum@burtongroup.com]
Sent: Sunday, December 04, 2005 5:50 PM
To: Weil Timothy
Subject: RE: caBIG - Technology Evaluation of a Federated Identity
Management Model for GRID Computing

It was difficult to determine from the document what stage the caBIG project was at and
which standards and requirements were prioritized.

To quote from the document: “While the evaluation resulted in the identification of
several technologies that have the potential to meet caBIG™ requirements, several
products are in early development stages. Their evaluations demonstrated that those
immature products are either not ready to deploy or do not currently fulfill all of the
caBIG™ requirements. To fully support the federated authentication and authorization
architecture, every technology needs to be further customized to support additional
functionality.”

This is very concerning. While federations require some customization, there does not
appear to be much emphasis on finding ways to reuse commercial products such as web
services platforms, web services management tools, or web access management tools.

Would also suggest some standards for the grid which would intercept where industry is
going with identity management, now that SAML is fully evolved and some of the WS-*
specifications have matured and are in standards process at OASIS.

   1. Person to application authentication: E-Authentication (EAI) framework
      addresses browser based authentication and almost certainly will migrate to the
      SAML 2.0 standard. Interoperability and product support might be maximized by
      following these specifications.
   2. Application to application authentication: There was no EAI spec for application
      to application authentication when I reviewed it. Would recommend using WS-
      Security with SAML or X.509 tokens for application authentication in any case. It
      was difficult to determine from the document whether this was or was not the
      caBIG architecture.
   3. Attribute based authorization: Attribute statements from the standard SAML 2.0
      profiles where possible, and federation-defined attributes where necessary for
      attribute based authorization.
   4. Attribute and token management: Obtain and manage attributes through various
      methods involving directory services, discovery services (perhaps leveraging WS-
      SecurityPolicy and WS-Trust). Most of the customization effort would occur here,
      so it would be important to begin with a simple approach or to allow endpoints to
      implement through any method.

With these standards, it is more likely that commercial products could be used in the grid
with less customization.
Concerning proxy certificates. Solutions that require exporting private keys to a proxy
should not be used.

While a domain such as caBIG is certainly entitled to create and map to its own internal
tokens and this might be done without affected external interoperability, it was not clear
how the proxy certificate would be used, and so difficult to determine if it added any
assurance that would not be present in SAML. However, there is a concern that the proxy
certificate will require customization of the applications being used in the grid, or
customization of the security infrastructure controlling grid resources. It was not clear
why the proxy certification were used rather than the SAML assertions that might be
consumed directly by many off the shelf applications or security infrastructure
components within the grid without the need – or less need – for customization.


Section 3.3.1 - Social security numbers should not be used in identifiers in assertions for
this environment.

Section 4.2 – the use of the proxy certificate was not part of the E-Authentication
architecture when I reviewed it in 2004. There was discussion of a step down translator
that might allow a user with a certificate to obtain an assertion for authentication, but this
had not be implemented or specified in detail as of mid 2005.

Section 4.2 - how are grid applications classified; can high risk (life sustaining
applications) be put on the grid? Can medium risk applications (those holding sensitive
intellectual property, patient medical information (or other privacy-related) or supporting
high value applications be put on the grid?

Section 4.2 – trust agreements would be simplified if caBIG followed E-Authentication
as much as possible. An issue is that E-Authentication did not, as of when I reviewed,
contain any provisions for application to application (Web services) communication or
for attribute exchange. These could be added through WS-Security as recommended
above.

				
DOCUMENT INFO