[ogsa-wg] OGSA-WG activities on the Express Profile
Hiro Kishimoto
hiro.kishimoto at jp.fujitsu.com
Wed Oct 17 09:33:06 CDT 2007
Hi Duane,
Minor procedural comment.
> 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.
I would say the OGSA-SP is on schedule to make WG final call in this
week and submit to the OGF editor for public comments in the following
week.
Thanks,
----
Hiro Kishimoto
-------- Original Message --------
Subject: Re:OGSA-WG activities on the Express Profile
From: Duane Merrill III <dgm4d at virginia.edu>
To: Alan Sill <Alan.Sill at ttu.edu>, Andrew Grimshaw <grimshaw at virginia.edu>
Cc: "Alan Sill" <Alan.Sill at ttu.edu>, "Shannon Hastings"
<hastings at BMI.OSU.EDU>, "Hiro Kishimoto" <hiro.kishimoto at jp.fujitsu.com>
Date: 2007/10/17 6:39
> 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/docman.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" <Alan.Sill at ttu.edu <mailto:Alan.Sill at ttu.edu>>
> To: "Duane Merrill" <dgm4d at virginia.edu <mailto:dgm4d at virginia.edu>>;
> "Andrew Grimshaw" <grimshaw at virginia.edu <mailto:grimshaw at virginia.edu>>
> Cc: "Alan Sill" <Alan.Sill at ttu.edu <mailto:Alan.Sill at ttu.edu>>; "Shannon
> Hastings" <hastings at BMI.OSU.EDU <mailto:hastings at BMI.OSU.EDU>>; "Hiro
> Kishimoto" <hiro.kishimoto at jp.fujitsu.com
> <mailto: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 <hastings at BMI.OSU.EDU
> <mailto:hastings at BMI.OSU.EDU>>
> >> Date: October 16, 2007 12:43:22 PM CDT
> >> To: CAGRID_USERS-L at LIST.NIH.GOV <mailto:CAGRID_USERS-L at LIST.NIH.GOV>
> >> Subject: Re: operations added by Introduce
> >> Reply-To: caGrid Users discussion Forum <CAGRID_USERS-L at LIST.NIH.GOV
> <mailto: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
> >> hastings at bmi.osu.edu <mailto:hastings at bmi.osu.edu>
> >>
> >>
> >> -----Original Message-----
> >> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
> >> L at LIST.NIH.GOV <mailto:L at LIST.NIH.GOV>]
> >> On Behalf Of Alan Sill
> >> Sent: Tuesday, October 16, 2007 12:27 PM
> >> To: CAGRID_USERS-L at LIST.NIH.GOV <mailto: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
> >>> hastings at bmi.osu.edu <mailto:hastings at bmi.osu.edu>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
> >>> L at LIST.NIH.GOV <mailto:L at LIST.NIH.GOV>]
> >>> On Behalf Of Shannon Hastings
> >>> Sent: Tuesday, October 16, 2007 11:41 AM
> >>> To: CAGRID_USERS-L at LIST.NIH.GOV <mailto: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
> >>> hastings at bmi.osu.edu <mailto:hastings at bmi.osu.edu>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS-
> >>> L at LIST.NIH.GOV <mailto:L at LIST.NIH.GOV>]
> >>> On Behalf Of Joel Schneider
> >>> Sent: Tuesday, October 16, 2007 11:27 AM
> >>> To: CAGRID_USERS-L at LIST.NIH.GOV <mailto: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: jschneid at nmdp.org <mailto:jschneid at nmdp.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: Alan.Sill at ttu.edu <mailto:Alan.Sill at ttu.edu> ph.
> 806-742-4350 fax 806-742-4358 :
> > ====================================================================
> >
More information about the ogsa-wg
mailing list