July 2007 - ogsa-wg - lists.ogf.org

Re: [ogsa-wg] [OGSA-D-WG] Definition of "data service"
by guru prasad 05 Jul '07

05 Jul '07

I have the following opinion about the proposed definition for a data service: "A service that exposes the capabilities or data of one or more data resources within a service-oriented architecture." The definition just tells me that Data Service just exposes the capabilities and/or data of data resource(s). But, it does not tell me if I can access this service to invoke those capabilities or the data of a data resource. If this is true, then, 'service' is too strong a term. It should be 'data resource descriptor'. Else, 'service that exposese the capabilities or data' has to be rephrased. Because it is not only exposing but also allowing the user to access those capabilities. I also agree to what bob natale had to say. The definition of data resource should evolve and be included with the definition of data service. Allen Luniewski <luniew(a)us.ibm.com> wrote: >From the Data Architecture glossary: Data sink: A data resource that receives the data copied by a data transfer mechanism from a source. Data Source: A data resource that contains the data to be copied to a sink via a data transfer mechanism. Informally, Data Architecture, and DMI for that matter, use these terms to denote the end points of a data transfer operation. A data resource is defined as: An entity (and its associated framework) that provides a data access mechanism or can act as a source or sink. (This is what currently on Grid Forge but source/sink really mean data source/sink). So, a data resource is the "thing" that both holds data and provides mechanisms for accessing its contents. Think of a data resource as something like a relational database or a file system as we have had for decades while the Data Architecture defines interfaces (services) that "front" a data resource, making it a participant in the service oriented architecture being defined by OGSA. Allen Luniewski IBM Cross Brand Services IBM Silicon Valley Laboratory 555 Bailey Ave. San Jose, CA 95141 408-463-2255 408-930-1844 (mobile) guru prasad <guru_bn(a)yahoo.com> Sent by: ogsa-wg-bounces(a)ogf.org 07/05/2007 10:54 AM To Mario Antonioletti <mario(a)epcc.ed.ac.uk>, Dave Berry <daveb(a)nesc.ac.uk> cc ogsa-d-wg(a)ogf.org, ogsa-wg <ogsa-wg(a)ogf.org> Subject Re: [ogsa-wg] [OGSA-D-WG] Definition of "data service" This brings me to this question: What is the difference between and data source and a data resource? Is former just the container for data and latter is responsible for managing one or more data sources? Mario Antonioletti <mario(a)epcc.ed.ac.uk> wrote: Hi, > Currently we're looking at something like the following: > > A service that exposes the capabilities or data of one or more > data resources within a service-oriented architecture. I think it should be "the capabilities and data" as opposed to "or". Similarly for the definition below. However, I think the one above is more succinct and thus gets my vote. > or > > A service that exposes the capabilities of one or more data > resources within a service-oriented architecture. These capabilities > might include data access, data transfer or data management. Mario +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+ -- ogsa-wg mailing list ogsa-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg --------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.-- ogsa-wg mailing list ogsa-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg --------------------------------- Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.

3 2

Definition of "data service"
by Dave Berry 05 Jul '07

05 Jul '07

We invite comments on the definition of "data service" for the OGSA Data Architecture (and hence the OGSA Glossary). Currently we're looking at something like the following: A service that exposes the capabilities or data of one or more data resources within a service-oriented architecture. or A service that exposes the capabilities of one or more data resources within a service-oriented architecture. These capabilities might include data access, data transfer or data management. We think either of these would be a significant improvement on our previous definition. The emphasis in these new proposals is on linking data resources into an SOA, which fits nicely with the OGSA definition of a service: A software component participating in a service-oriented architecture that provides functionality and/or participates in realizing one or more capabilities. Our previous definition mentioned specific types of interfaces, which we think is too specific and not resistant to change: A service that is primarily intended to provide access to data stored in one or more data resources. A data service will provide one or more of the data access, data source or data sink interfaces defined in the OGSA Data Architecture. Comments welcome, especially before Monday's OGSA-WG call. Dave Berry Deputy Director, Research & E-infrastructure Development National e-Science Centre 15 South College Street, Edinburgh, EH8 9AA +44 131 651 4039 www.nesc.ac.uk <http://www.nesc.ac.uk/>

5 4

express profile documents
by Blair Dillaway 05 Jul '07

05 Jul '07

Hi Duane , Here are some additional comments on the express profile specs dated June 28, 2007. Overall I think these are considerably improved over the initial drafts. Secure-Addressing: - Line 69: "Extend the requirements of the WS-I ..." doesn't sound right. Perhaps "Address additional grid interoperability requirements not covered in WS-i..." - Line 86 "client to engage in secure communication." How about "client to engage in secure communication and effectively use an OGSA web service". This at least acknowledges concerns raised by David Chadwick about providing the tokens needed to authZ actions at the service. - Line 173: It should be WS-SecurityPolicy 1.2, not 1.5. - Line282: Add to end of the paragraph - "The INITIATOR may need the RECIPIENT's token to supply a verifiable key used for message-level encryption of an initial request message. - Section 4.3: If we're specifying a 'secure endpoint reference' then we should say something about how these EPR documents are distributed. There are several possible attacks from modifying these documents in transit (man-in-the-middle attacks, failing to sign and/or encrypt the message correctly). One option is to provide for signing of these documents by the service, in which case we should spec how they are signed. This is the most scalable approach. One could also assume distribution via trusted server over TLS/SSL, but that's likely unacceptable in a lot of environments. Secure-Transport - Line 248, 252: You reference the ciphersuites in WS-SecurityPolicy. This is a fine list of strong suites, but unfortunately doesn't include a cross-reference to the TLS/SSL standard ciphersuite identifiers. You provide an example translation on Line 384. A simple mapping table would likely help out people reading this spec who are familiar with the TSL/SSL suite names. - Line 312: Providing to EPR document signing would help address the issue you raise regarding EPRs coming from untrusted sources. Secure-Soap - Line 285: It says ".. this Profile requires encrypted communication". Based on prior discussions, I had thought it was agreed integrity protection was a MUST but confidentiality was optional? - Section 7: I still have a problem with the wording here. Stating in C0701 that "UsernameToken credentials SHOULD NOT be used for message authentication..", and then having Section 7.2 explain how to indicate they should be used for message level client authentication, seems contradictory. C0701 also says username tokens "are not cryptographically verifiable.". Of course, if one uses password digest (with nonce & timestamp) one can get cryptographically strong verification the sender knew the password and the token wasn't pasted in from some other message. Was your intent in C0701 to warn people that username tokens should be used with caution since they: 1) don't provide a basis for ensuring overall message integrity; 2) the binding between the token and message is weak? Perhaps just remove C0701 since it's the only numbered security consideration in the document and the requirements in Section 4.2 already ensure it can't be used unless you're using secure transport. Regards, Blair Dillaway

1 0

Taverna workflows
by Donal K. Fellows 05 Jul '07

05 Jul '07

It's been an action on me to find out about Taverna. Since the workflow session today was cancelled (national holidays? pah!) I'll report what I've learned so far here before I forget due to vacation. :-) Taverna is a data-oriented workflow system (as opposed to control-oriented, though it also supports control links between processors) for automating tasks as seen from the client-side; it's intended to replace "human workflows" which involved cutting and pasting chunks of text between web pages (previously a time-consuming and error-prone process). It's not designed to handle cases with complex recovery from failures, but is instead focussed on automated handling of sets of data. It's GUI-oriented (though there is a command-line execution module) and as such it has got a number of features to enable scaling of the complexity of workflows to scientifically-useful levels: in particular, it has recursive decomposition and a way to mark processing nodes as "not interesting" and hence normally hidden. One limitation is that Taverna essentially assumes that the processing nodes are free to use (both by the user *and* by anyone else) which has a consequence in terms of its (non-existent) security model[*]. It's also not designed with dynamic instantiation of services in mind (there's a plugin for service discovery, but it's not integrated into the workflow system itself, just the GUI design tool). In short, if you're doing scientific workflows that use local components and free static services available over the web, Taverna is very good. But it's got substantial weaknesses for domains where services are secured, costly or dynamic. Far more information than I've mentioned is available online at http://taverna.sourceforge.net/index.php?doc=docroot.html I hope this is informative. :-) Donal. [* I understand that there's work ongoing to add some kind of security support, but I don't know how that's progressing. It's not in the latest production release for sure. ]

3 3

WS-SecurityPolicy becomes an OASIS Standard
by Hiro Kishimoto 04 Jul '07

04 Jul '07

Hi all, As I mentioned at the OGSA Express Authentication Profile call, WS-SecurityPolicy becomes an OASIS Standard. ---------------------------------------------------------------------- WS-SecurityPolicy becomes an OASIS Standard Members have approved version 1.2 of WS-SecurityPolicy as an OASIS Standard. WS-SecurityPolicy defines a base set of assertions that describe how messages are to be secured in the WS-Policy framework. Congratulations to Web Services Secure Exchange (WS-SX) TC co-chairs, Kelvin Lawrence of IBM and Chris Kaler of Microsoft, and to all WS-SX TC members for this accomplishment. http://lists.oasis-open.org/archives/tc-announce/200707/msg00001.html -- Hiro Kishimoto

1 0

No OGSA call on July 5
by Hiro Kishimoto 03 Jul '07

03 Jul '07

Hi all, June 4th is US holiday and many US folks have vacation on July 5th. Thus I would propose to have NO call on July 5th. If you want to have a call on this Thursday (Service Level Terms or Workflow), please let me know. Thanks, -- Hiro Kishimoto

1 0

Teleconference minutes - 2 July 2007 - Security / Logistics
by Andreas Savva 03 Jul '07

03 Jul '07

Teleconference minutes are on gridforge: Security (M. Behrens) https://forge.gridforum.org/sf/go/doc14654?nav=1 Logistics (A. Savva) https://forge.gridforum.org/sf/go/doc14655?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Re: [ogsa-wg] Open Science Grid: TIGRE site does not show up in ReSS ISSUE=3712 PROJ=71
by Alan Sill 02 Jul '07

02 Jul '07

Hmm. Idle batch queue was supposed to be open to all grid users. Does TIGRE have its own queue? WIll have to review this again tomorrow... On Jul 2, 2007, at 4:23 PM, Chaffin, David wrote: > I mentioned previously that there aren't any tigre users defined to > lsf. > cms appears to be the only grid users that are defined. > > David

1 0

Re: [ogsa-wg] Open Science Grid: TIGRE site does not show up in ReSS ISSUE=3712 PROJ=71
by Alan Sill 02 Jul '07

02 Jul '07

Queue rearrangements appear to have been destructive to all except CMS OSG jobs: alansill@tigretest ~]$ globusrun-ws -submit -F https:// antaeus.hpcc.ttu.edu:9443 -Ft LSF -streaming -c /usr/bin/id Delegating user credentials...Done. Submitting job...Done. Job ID: uuid:ab39016c-28de-11dc-ba50-003018a434f4 Termination time: 07/03/2007 20:56 GMT Current job state: Failed Destroying job...Done. Cleaning up any delegated credentials...Done. globusrun-ws: Job failed: The executable could not be started. idle: User cannot use the queue. Job not submitted. I get this when mapped as wither a TIGRE or CDF user, but not when I assert a CMS proxy. On Jul 2, 2007, at 3:44 PM, Alan Sill wrote: > Don't knwo why OSG monitoring is failing on antaeus, will check it > out. 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(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 0

Notes from Joint OGSA WG AuthN/AuthZ call
by Alan Sill 02 Jul '07

02 Jul '07

OGSA AuthN/AuthZ joint call Chris David Mark Morgan Andrew Grimshaw FrankSiebenlist Jack Hiro Kishimoto Alan Sill Andreas Savva Stephen Agenda items: OGSA-AuthZ update (David Chadwick) OGSA-AuthN update (Alan Sill) David summarized the current state of the OGSA-AuthZ work. No progress or changes have taken place since OGF-20 on the document set from the AuthZ work groupl Jargon for below: PDP = policy decision point PEP = policy enforcement point PIP = policy information point GFD-66 and 67 (65?) status GFD-66 was intended to describe the relation between PDPs and PEPs Previous version of GFD-66 based on SAML 1.1 was implemented by several groups and found to be insufficient. An architecture document was written by David and others to propose 3 protocols: one for pull of credentials from an IdP or AA according to any of several protocols profiled by OASIS and others, an XACML protocol, and a credential validation service profile defined according to WS-trust. Alan requested that David get a document number for this architecture document and David agreed to move this along the path to formalization. It would be good to publish this as an informational document, with the 3 protocols pulled into separate documents. Frank said that progress at Argonne on this has been slowed by work being done for GT4.2 - all security programmers have been pulled onto that work and have not had sufficient time available for standards work. GFD-66 had value but does not extend to sufficiently realistic complex real-world use case requirements, for example validating signed credentials, interactions with PIPs, etc. For requirements gathering, David put up a wiki but got very few submissions. Stephen points out that people see a need for security but do not see the relevance of the work done here, and socialization of the work being done here is not sufficiently seen as connected to real-world needs. Alan agreed that this is an important component of the work and is exactly what Duane, mark and Andrew have been trying to do in the requirements-gathering work they have been doing for the short-term AuthN documentation work they have been done. Frank did not understand the disconnect, as the XACML work for example has been driven by strong communication between developers and community segments that have requested this work. Andrew says that the exercise of writing a use-case document has proven itself even in circumstances in which the use cases are thought to be well- known. Stephen and Alan felt this to be true even though writing such documents can be a chore. People are often stuck on simple cases when the community doing work on standards is often focused on more advanced use cases. Andrew pointed out that documenting even the simple use cases is of value and must be written down to get rid of this barrier for users; some of the work being done for the HPC profile was driven by this need. Last week David sent out a document written from the point of view of Authorization meant to match some of the current "simple AuthN" work. Mark more or less simultaneously requested such a document. Discussion followed as to whether AuthZ can be folded into the current security profile "express" documentation work being done, or instead whether another document to address "express authZ" should be written. Andrew prefers simple short documents over grand scheme documents at this stage. Another document in this series entitled "OGSA Security Profile 2.0 - Authorization" would be helpful. David agreed to look at this and will go through the current set from this perspective. Moving on to authentication topics Alan is ready now to restart work on the OGSA-AuthN topics. Motivations here include examining the technical requirements of implementations and ensuring that the documentation and standards set offered by OGSA is sufficiently flexible and well-specified to allow interoperable implementations based on different technologies. As an example, Alan asks why Ws- Security is so SOAP-oriented, when grid implementations can be written based on the same WSDL and XML that could provide code using different RPC methods? Other motivations include ensuring that Shibboleth grid integration can be done on a well-defined standards basis within OGSA, and while this is largely an AuthZ question, we need to make sure that the OGSA-AuthN pieces and basis for this work are sufficiently documented, understood and specified. A documentation call series will be started sometime in July to get this work going. Simultaneously, work should be continued to complete the "express profile" documentation series. Hiro asked about the timing of the next joint call. David has Sep. 13 down as the next joint call. Hiro offered time at the Sunnyvale F2F Aug. 13-16. 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(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

7 19