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.