[ogsa-wg] OGSA-WG activities on the Express Profile
Andrew Grimshaw
grimshaw at virginia.edu
Wed Oct 17 08:23:52 CDT 2007
Guys,
Please have the discussion on the OGSA-wg mailing list so everyone can see
_____
From: Duane Merrill III [mailto:dgm4d at 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 at ttu.edu> Alan.Sill at ttu.edu>
To: "Duane Merrill" < <mailto:dgm4d at virginia.edu> dgm4d at virginia.edu>;
"Andrew Grimshaw" < <mailto:grimshaw at virginia.edu> grimshaw at virginia.edu>
Cc: "Alan Sill" < <mailto:Alan.Sill at ttu.edu> Alan.Sill at ttu.edu>; "Shannon
Hastings" < <mailto:hastings at BMI.OSU.EDU> hastings at BMI.OSU.EDU>; "Hiro
Kishimoto" < <mailto:hiro.kishimoto at jp.fujitsu.com>
hiro.kishimoto at 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 at BMI.OSU.EDU>
hastings at BMI.OSU.EDU>
>> Date: October 16, 2007 12:43:22 PM CDT
>> To: <mailto:CAGRID_USERS-L at LIST.NIH.GOV> CAGRID_USERS-L at LIST.NIH.GOV
>> Subject: Re: operations added by Introduce
>> Reply-To: caGrid Users discussion Forum <
<mailto:CAGRID_USERS-L at LIST.NIH.GOV> CAGRID_USERS-L at 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 at bmi.osu.edu> hastings at bmi.osu.edu
>>
>>
>> -----Original Message-----
>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
>> <mailto:L at LIST.NIH.GOV> L at LIST.NIH.GOV]
>> On Behalf Of Alan Sill
>> Sent: Tuesday, October 16, 2007 12:27 PM
>> To: <mailto:CAGRID_USERS-L at LIST.NIH.GOV> CAGRID_USERS-L at 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 at bmi.osu.edu> hastings at bmi.osu.edu
>>>
>>>
>>> -----Original Message-----
>>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
>>> <mailto:L at LIST.NIH.GOV> L at LIST.NIH.GOV]
>>> On Behalf Of Shannon Hastings
>>> Sent: Tuesday, October 16, 2007 11:41 AM
>>> To: <mailto:CAGRID_USERS-L at LIST.NIH.GOV> CAGRID_USERS-L at 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 at bmi.osu.edu> hastings at bmi.osu.edu
>>>
>>>
>>> -----Original Message-----
>>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
>>> <mailto:L at LIST.NIH.GOV> L at LIST.NIH.GOV]
>>> On Behalf Of Joel Schneider
>>> Sent: Tuesday, October 16, 2007 11:27 AM
>>> To: <mailto:CAGRID_USERS-L at LIST.NIH.GOV> CAGRID_USERS-L at 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 at nmdp.org> jschneid at 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 at ttu.edu> Alan.Sill at ttu.edu ph.
806-742-4350 fax 806-742-4358 :
> ====================================================================
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20071017/80633be0/attachment-0001.html
More information about the ogsa-wg
mailing list