[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ggf-ogsa-sec-wg] Two documents
Ian,
Now that you have asked .... :o)
The two roadmaps (and the ppt) are more organizational than
technological - and rightfully so. They have pioneered the ideas and
evangelized the concepts. We need to work on the tasks identified in
them. Also the current OGSA/OGSI concepts have evolved to a higher plane
and we need to evolve the security to the same plane.
We have done a good job at internalizing WSDL and web services -
i.e. look at them critically, absorb whatever made sense and contribute
when we had "kindlier-gentler-new-improved" ideas. Now we need to do
that with security - the paradigms out there, the proposed specs out
there and the pragmatic requirements now and in the future.
Now that I have a chance, let me address the OGSA security
documents :
In "The Security Architecture for Open Grid Services", I am fine
with the figure "Components of Grid Security Model" at a high level -
but it has IDS thru non-repudiation thru authZ policies. It is a good
guiding concept, but we are far beyond that - we need to dig deeper. I
like the Fig 3-Building Blocks for GSA. It still is organizational - not
a security architecture. The time has come to start defining the
services and interfaces in terms of porttypes, operations and
serviceData.
I am not that comfortable with the "OGSA Security Roadmap"
because it talks about specifications that (almost) directly map into
the WS Roadmap. What is missing is a Grid Security Framework document of
some sort. Also there are too many specs and if we have one wg per spec,
we would end up needing to coordinate them - assuming we get enough
experts to volunteer to develop them. I think we have a set of usual
suspects who will show up in all the security related wgs. So aggregate
and provide grid context would be a good suggestion for that document.
The "OGSA Security Roadmap Discussion" (I assume it is Frank's)
has identified a few tasks which I can relate to and that is what I am
pushing for :
Slide 3/4 : Address Grid Security Requirements -
interoperability/pluggability/replaceability (am not worried about
replaceability, but want to evangelize pluggability of existing tools
and interoperability with different implementations)
Slide 5 : OGSAF'fy, define profiles/mechanisms/...
I know I might get a few push backs - let me say it any way - I
rush in where angels fear to tread ! We have the same slides - boxes of
existent and non-existent ws-* specs tiled together - that is neither
architecture nor framework- it is just organizational. We need to
explicitly say what security means to grid - the features, the APIs(ie
services) and the wire formats. For example section 7 defines in
aggregate the granular services - let us define them - how they will
look like, why where and how we would use them.
Now to more current operational issues - if we just tie all the
security requirements together with porttypes, operations and
servicedata we have the first pragmatic security substrate - we should
address features from identity thru auth C and Z thru policies ... If we
also add the wire formats for the popular specifications, (including
answers to questions like which spec ? When ? How do the specs layer ?)
we have the first working set of GridSecurityServices.
In short ...
<executive_summary>
The roadmap documents are a good start, but we need to elaborate
and also incorporate the current concepts from the new drafts of the
OGSA/OGSI docs. The security needs to be congruent with the OGSA/I and
keep pace with the evolution.
</executive_summary>
Sorry for the long rambling, I am almost sure all of us are
thinking almost in the same direction ... It is a question of
conceptualization and organization (of wgs) and then pure work ...
cheers
> -----Original Message-----
> From: owner-ogsa-sec-wg@gridforum.org
> [mailto:owner-ogsa-sec-wg@gridforum.org] On Behalf Of Ian Foster
> Sent: Monday, February 17, 2003 7:57 PM
> To: ksankar@cisco.com; ogsa-sec-wg@gridforum.org
> Subject: RE: [ggf-ogsa-sec-wg] Two documents
>
>
> Do the two original "OGSA Security Roadmap" documents address
> any of this,
> do you think?
>
>
> At 07:42 PM 2/17/2003 -0800, Krishna Sankar wrote:
> >Hi all,
> >
> > Read thru the e-mails and the two documents. Here
> are some of my
> >observations (as usual in random order :o)):
> >
> > I was also lost in the beginning when I saw the
> documents. But
> >as I read thru them carefully (had a lot of time during my
> >coast-to-coast flight today) I realized a few things. Both
> are profiles
> >- the application of a specification to some aspects of the
> grid domain.
> >The reason they seem disjoined or surprised us, is because
> of the lack
> >of a security framework and address the wire formats for two
> features.
> >They are an excellent starting point and we need more of them - most
> >proably as tech notes/specification expertise and then merged into a
> >general security framework.
> >
> ><soap_box>
> > What we need is a compact, cohesive & coherent security
> >framework - architecture and associated infrastructure. The framework
> >should address the *core* security services (identity, authC, authZ,
> >policies, delegation, firewalls, ...), the operations, porttypes and
> >extension points. The serviceData they expose is also very important.
> >
> > The OGSI draft is coming out nicely and once it is
> discussed and
> >ratified at GGF7, we could define a security architecture and
> >infrastructure based on the OGSI paradigms. We need the security
> >service/object system architecture and the infrastructure
> wire formats
> >underneath the architecture.
> >
> > Whether it should be a single wg or not is for us
> to discuss. I
> >think the *core* can be developed by a single wg. Remember we are
> >talking about the security substrate based on a SOA -
> specifically web
> >service paradigm.
> >
> > We also keep in mind the pragmatic aspects - i.e.
> develop a core
> >and then incrementally add more features. One of the
> discussions I would
> >like to have, is with the Globus team, to seek the security
> requirements
> >- short, medium and long term.
> ></soap_box>
> >
> > In the Security Context Document, on Page 7 or so
> mentions that
> >"new xml-elements were defined to render GSSAPI..." but
> didn't see any
> >WS-Trust in the document. Am I missing something ?
> >
> > In the use of SAML ... document, 5th paragraph
> states "This spec
> >does not define a mechanism ... WS-Trust will be used to
> define this" -
> >Am not sure the WS-Trust would define a mechanism. Anyway we
> can discuss
> >later ...
> >
> > Also the "Use of SAML..." document is a good addition to the
> >authZ wg. We have a section for XML protocols and
> specifications where
> >this document would fit in very well.
> >
> > I think both documents need the PortTypes,
> operations and the
> >serviceData sections.
> >
> > May be it is a good idea to have a top level
> GridSecurityService
> >with security operations and securityServiceData. Then the bottoms
> >approach can define the services, operations and data based on that
> >framework - just a thought.
> >
> >cheers
> >
> >
> > > -----Original Message-----
> > > From: owner-ogsa-sec-wg@gridforum.org
> > > [mailto:owner-ogsa-sec-wg@gridforum.org] On Behalf Of Michael Helm
> > > Sent: Monday, February 17, 2003 10:06 AM
> > > To: ogsa-sec-wg@gridforum.org
> > > Subject: Re: [ggf-ogsa-sec-wg] Two documents
> > >
> > >
> > > "Olle Mulmo" writes:
> > > > list and asked up-front how we are to deal with
> bottom-up approaches
> > > > in this WG (see mail archives), as they will surely
> appear sooner or
> > >
> > > How about "pragmatic" ... bottom-up has strange connotations!
> > >
> > > > My non-initiated suggestion is to break this WG into
> two: a research
> > > > group that continues the work on the roadmap, laying out
> > > the long-term,
> > > > high-level architecture; and a WG that operates in the web
> > > services space,
> > > > discussing the nitty-gritty protocol details of various
> > > service specs.
> > >
> > > I think this is an excellent idea. One of my colleagues
> has suggested
> > > that this is a whole entire area, and should be broken up into
> > > a zillion wg's, probably one for every spoke on the
> famous wagon-wheel
> > > slide. Having gone thru such a transition in another
> place, I have
> > > some reservations about that. But a split as Olle described looks
> > > helpful. Some of us are interested in the architecture, but are
> > > unsure what exactly needs to be done ; there are many dependencies
> > > in the architecture on things that don't exist in standards bodies
> > > that have just begun work, as well as opportunities to do work
> > > in areas that look more mature (like xkms or saml). Decoupling
> > > at least releases an inhibition against starting work.
> > >
>
> _______________________________________________________________
> Ian
> Foster
> http://www.mcs.anl.gov/~foster
>
> Math & Computer Science Div.
> Dept of Computer Science
> Argonne National Laboratory The University of Chicago
> Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A.
> 630 252 4619 (fax 5986) 773 702 3487 (fax 8487)
>
>