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:
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" <Alan.Sill@ttu.edu>
To: "Duane Merrill" <dgm4d@virginia.edu>;
"Andrew Grimshaw" <grimshaw@virginia.edu>
Cc: "Alan Sill" <Alan.Sill@ttu.edu>; "Shannon
Hastings" <hastings@BMI.OSU.EDU>;
"Hiro Kishimoto" <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
> respect to the Express Profile and related documents, as they might
> relate to the use case described below?
> 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 <hastings@BMI.OSU.EDU>
>> Date: October 16, 2007 12:43:22 PM CDT
>> To: CAGRID_USERS-L@LIST.NIH.GOV
>>
Subject: Re: operations added by Introduce
>> Reply-To: caGrid Users discussion Forum <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 Hastings
>> co-Director
>> Software Research Institute
>> Department of Biomedical Informatics
>>
>>
>> Office: (614) 292-9461
>> Lab: (614) 292-9845
>> hastings@bmi.osu.edu
>>
>>
>> -----Original Message-----
>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
>> L@LIST.NIH.GOV]
>> On Behalf Of Alan Sill
>> Sent: Tuesday, October 16, 2007 12:27 PM
>> To: 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
>>>
>>>
>>> Office: (614) 292-9461
>>> Lab: (614) 292-9845
>>> hastings@bmi.osu.edu
>>>
>>>
>>> -----Original Message-----
>>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
>>> L@LIST.NIH.GOV]
>>> On Behalf Of Shannon Hastings
>>> Sent: Tuesday, October 16, 2007 11:41 AM
>>> To: 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 Hastings
>>> co-Director
>>> Software Research Institute
>>> Department of Biomedical Informatics
>>>
>>>
>>> Office: (614) 292-9461
>>> Lab: (614) 292-9845
>>> hastings@bmi.osu.edu
>>>
>>>
>>> -----Original Message-----
>>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
>>> L@LIST.NIH.GOV]
>>> On Behalf Of Joel Schneider
>>> Sent: Tuesday, October 16, 2007 11:27 AM
>>> To: 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)
>>> phone:
612-617-8321
>>> email: jschneid@nmdp.org
http://www.marrow.org/
>
> Alan Sill, Ph.D
>
> Adjunct Professor of Physics
> TTU
>
> ====================================================================
> : Alan Sill,
> : e-mail: Alan.Sill@ttu.edu
ph. 806-742-4350 fax 806-742-4358 :
> ====================================================================
>