Guys, Please have the discussion on the OGSA-wg mailing list so everyone can see _____ From: Duane Merrill III [mailto:dgm4d@virginia.edu] Sent: Tuesday, October 16, 2007 5:40 PM To: Alan Sill; Andrew Grimshaw Cc: Alan Sill; Shannon Hastings; Hiro Kishimoto Subject: Re: OGSA-WG activities on the Express Profile Shannon and Alan, It sounds as if the caGrid getServiceSecurityMetadata() operation has similar intent as the OGSA Security Profile (OGSA-SP, a.k.a., "Express Profile") documents: to advertise and facilitate interoperable, secure communication (or to cleanly determine if interoperability is not possible). The mechanism for discovery is quite different, however. In part, the OGSA-SP documents are profiles on WS-Addressing: how to convey secure-communication requirements within endpoint references (EPRs). If we were to apply the OGSA-SP to your use-case below, the EPR used by a client to interact with a resource would indicate that the endpoint requires a TLS transport layer (possibly also indicating a requirement for mutual-authentication at the TLS layer). Why do this within the EPR? The EPR datastructure plays a crucial role for addressing resources in the OGSA architecture and is extensively incorporated into many of its service interfaces (e.g., notification, execution management, directory services, resource management, etc.). The utility of the grid derives from the dynamic composition of services, and EPRs are how services refer to and address each other. They encapsulate the "invocation context" for a resource: everything one needs to know to communicate with it. Publishing security requirements elsewhere (e.g., within WSDL, or exposed through reflective service operations) incurs extra communication cost, availability and interoperability risks, etc. How are communication requirements expressed? The OGSA-SP documents use the newly ratified OASIS WS-SecurityPolicy standard to convey secure-communication requirements. Although resources are free to express arbitrary security requirements, the OGSA-SP documents define well-known, composable security policies for common security mechanisms. (And are perfectly extensible as new mechanisms are introduced.) For example, the OGSA-SP presently contains composable policies for server-authenticated TLS, mutually-authenticated TLS, UsernameToken authentication, mutual-X.509 authentication, digital signature and encryption of document elements, etc., most of which defer completely to sections of the WS-I Basic Security Profile. In this fashion, the OGSA-SP also serves as a location for minor mechanism clarifications and refinements as Web services security mechanisms are adapted to the Grid environment. As for the status of the OGSA-SP within the OGF document process, the OGSA-SP is on schedule to enter public comment within the week. The latest drafts of the OGSA-SP documents (and a potentially-languishing use-case document) can be found at: https://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-wg/docm an.root.working_drafts.security_profiles_use_case The OGSA-SP documents themselves are architected in a hierarchical, extensible fashion. The OGSA-BSP Secure Addressing document defines the general attachment mechanism for conveying security policy within EPRs as well as how to make them tamper-resistant through digital signature. The OGSA-SP Secure Transport document defines well-known policies for de-facto transport-level secure communication configurations. The OGSA-SP Secure SOAP Messaging document defines analogous policies for de-facto message-level security mechanisms. If you have someone at OGF and are interested in more detail, I will be presenting the OGSA-SP documents at the OGSA Express Authentication Security Profile session on Thursday afternoon, 3:15 pm - 4:45 pm, and would enjoy discussing them further. Cheers, Duane ----- Original Message ----- From: "Alan Sill" < <mailto:Alan.Sill@ttu.edu> Alan.Sill@ttu.edu> To: "Duane Merrill" < <mailto:dgm4d@virginia.edu> dgm4d@virginia.edu>; "Andrew Grimshaw" < <mailto:grimshaw@virginia.edu> grimshaw@virginia.edu> Cc: "Alan Sill" < <mailto:Alan.Sill@ttu.edu> Alan.Sill@ttu.edu>; "Shannon Hastings" < <mailto:hastings@BMI.OSU.EDU> hastings@BMI.OSU.EDU>; "Hiro Kishimoto" < <mailto:hiro.kishimoto@jp.fujitsu.com> hiro.kishimoto@jp.fujitsu.com> Sent: Tuesday, October 16, 2007 2:36 PM Subject: OGSA-WG activities on the Express Profile
Duane and Andrew,
Can you catch us up, including Shannon, on the activities with respect to the Express Profile and related documents, as they might relate to the use case described below? Shannon works with the CaGrid group, and says that they have someone out at OGF who might be able to interact with you about this if you are there. Meanwhile, a few web links and a status update as regards the use case documents and draft profile might be useful.
Thanks, Alan
Begin forwarded message:
From: Shannon Hastings < <mailto:hastings@BMI.OSU.EDU> hastings@BMI.OSU.EDU> Date: October 16, 2007 12:43:22 PM CDT To: <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L@LIST.NIH.GOV Subject: Re: operations added by Introduce Reply-To: caGrid Users discussion Forum < <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L@LIST.NIH.GOV>
Please do. We have recently become aware of another similar effort within the grouper group. Maybe this is the same effort. Steve is out at OGF this week so when he gets this email he can try to find those folks as well.
Thanks, Shannon
Shannon Hastings co-Director Software Research Institute Department of Biomedical Informatics Ohio State University
Office: (614) 292-9461 Lab: (614) 292-9845 <mailto:hastings@bmi.osu.edu> hastings@bmi.osu.edu
-----Original Message----- From: caGrid Users discussion Forum [mailto:CAGRID_USERS- <mailto:L@LIST.NIH.GOV> L@LIST.NIH.GOV] On Behalf Of Alan Sill Sent: Tuesday, October 16, 2007 12:27 PM To: <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L@LIST.NIH.GOV Subject: Re: operations added by Introduce
FYI, there is now an effort to define an architecture for specification, advertising and discovery of security requirements of exactly this nature in the context of the OGSA-WG "Express Profile" as a profile under WS-Security. If you are interested in this work, I would be happy to put you in touch with members of that group so you can read the profiles and use cases, and comment.
Thanks, Alan
On Oct 16, 2007, at 10:48 AM, Shannon Hastings wrote:
To be even more specific just in case you are concerned about security.
getServiceSecurityMetadata is an operation that is always public on a service. What it does is tell any client what it required to talk to the service. It contains no more information than that. It enables a client to know that he cannot talk to the service without a using TLS for example.
The other three methods are part of the wsrf spec regarding resource property access. These methods will use whatever security setting you put on your service. If you say that your service is secure and set authorization requirements at he service level in introduce, than these methods will also inherit this security. So you have total control of whether your resource properties are available. Now keep in mind, there are resource properties of the service, not the service properties (which should be used for internal configuration and are not available through any operations).
Shannon Hastings co-Director Software Research Institute Department of Biomedical Informatics Ohio State University
Office: (614) 292-9461 Lab: (614) 292-9845 <mailto:hastings@bmi.osu.edu> hastings@bmi.osu.edu
-----Original Message----- From: caGrid Users discussion Forum [mailto:CAGRID_USERS- <mailto:L@LIST.NIH.GOV> L@LIST.NIH.GOV] On Behalf Of Shannon Hastings Sent: Tuesday, October 16, 2007 11:41 AM To: <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L@LIST.NIH.GOV Subject: Re: operations added by Introduce
These are required operations of any caGrid service. They are provide access to querying the resource properties of the main service as well as the security configuration of the service. This security information is just metadata about the requirements needed to connect to the service. This enables a client to know that it will need a certificate, or will need to use SSL. You should not disable these operations. For more information on them. The resource property ones are related to the WS specifications and the getSecurityMetadata is a caGrid only operation which you can read about at caGrid.org in the Introduce technical guide.
Shannon
Shannon Hastings co-Director Software Research Institute Department of Biomedical Informatics Ohio State University
Office: (614) 292-9461 Lab: (614) 292-9845 <mailto:hastings@bmi.osu.edu> hastings@bmi.osu.edu
-----Original Message----- From: caGrid Users discussion Forum [mailto:CAGRID_USERS- <mailto:L@LIST.NIH.GOV> L@LIST.NIH.GOV] On Behalf Of Joel Schneider Sent: Tuesday, October 16, 2007 11:27 AM To: <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L@LIST.NIH.GOV Subject: operations added by Introduce
I noticed that a service created using Introduce has the following four operations, in addition to the operations I defined by hand:
getResourceProperty getMultipleResourceProperties queryResourceProperties getServiceSecurityMetadata
This service in question was originally created using Introduce 1.0 as an analytical service, and later migrated to Introduce 1.1.
The presence of these additional operations raises a number of questions.
1) What is the purpose of the additional operations?
2) If these operations are not required by my service, is there an easy or recommended way to remove or disable them?
3) From a security perspective, I'm concerned these operations might expose the service's ServiceConfiguration to a remote user. Is that the case? (Where is the code which implements these operations?)
Help with these questions would be much appreciated.
Best regards, Joel
-- Joel Schneider National Marrow Donor Program Software Developer (Contractor) 3001 Broadway Street NE phone: 612-617-8321 Minneapolis, MN 55413 email: <mailto:jschneid@nmdp.org> jschneid@nmdp.org <http://www.marrow.org/> http://www.marrow.org/
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: <mailto:Alan.Sill@ttu.edu> Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================