[saga-rg] Re: SAGA and Security

[Andre Merzky]

Hi Dane, 

thanks for the remarks and corrections - I should have known
that its not _that_ easy as I thought ;-)  It would be
perfect to have you at the Wednesday session!

Quoting [Dane Skow] (Feb 13 2006):
> 
> Hi Andre,
> 
> I have some reservations with this summary of our discussion but as I  
> indicated, I think I don't understand the scope/abstraction levels  
> you are after. We seem to be mixing several things here in this  
> discussion. I believe you've been talking primarily with Olle so  
> perhaps it's my confusion. I will try to attend your session at 10:30  
> on Wednesday, though it conflicts with the CAOPs session we'll also  
> need to cover.
> 
> Within the OGSA architecture in GGF we can make some simplifying  
> statements about a common paradigm. However, if the goal is to  
> provide an API generic across ANY Grid infrastructure, the task is  
> more difficult.

The reason for that is that we need the SAGA API now, and
running on current Grid middleware.  If in the (far or not
so far) future there is only OGSA, and its widely deployed
and adopted, we obviously should step back and check what
tighter relationshio we should have to OGSA.

> We can also make simplifications if one assumes the API is for  
> accessing Grid services and does not expect to efficiently adapt to  
> local communications between individual users.

I am not sure if I understand that part.  Are you targeting
at solutions which introduce latencies which do not matter
if compared to (slow) remote ops, but are significant if
compared to (fast) local ops?  What would those look like?


> I'm having a hard time understanding whether the desire is to  
> understand "the" common grid security model (there are some things we  
> can say pretty broadly now for the common ones in GGF:  x509  
> credentials are the common denominator for grid identification/ 
> authentication, etc), 

yes.

> to find/build a common library set for building  
> tools to implement common security goals in applications (eg. set/ 
> read an ACL for accessing a file/service, etc),

no (although that would be useful for our implementation)

> or to identify what  the elemental security actions are
> for a broad set of grid services.

yes.

Let me give some examples, in the form of use cases.

  - Ann creates a stream server.  A client Bob connects, 
    Ann wants to authenticate and authorize that client.  
    Should she
    - check for bobs distinguished name
    - ask a remote service for AA of Bob
    - ask for a shared secret
    - rely on out-of-band security (fine grained firewall or
      so)

  - Ann creates a file.  She wants Bob to read it, but not
    Charlie.
    - should she set ACLs on the file?
    - chould she call chmod/chgroup on the file?  
    - What is the user/group name of bob/charlie?
    - should she add bob Subject ID to a allow list, and
      charlies to a deny list?  What are the defaults?

  - Ann runs a remote job, and want to allow bob to kill it,
    and charlie to suspend/resume it.
    - should she maintain allow/deny lists per operation?
    - should she include callacks (i.e. callouts) in the
      applicsation whcih ask for permissions for a
      distinguished name
    - should she change ownership of the job to bob or
      charlie or both?

You see, we touch security in various places, and various
paradigms.  For each of them we would need to understand
what security actually _means_.  Does GGF have a notion of a
user?  Of a access/deny list?  ACLs? ... ... ...


> As I mentioned in our talk, I believe we have lessons to
> learn here  from how IETF has handled the job of
> integrating security into  application/protocol design.
> The answer is clearly NOT to have  external experts come
> in a "sprinkle security pixie dust" (not what I
> understand you to be asking for by the way)

Well, its not that far off... ;-)


> but rather to  
> consolidate on a common toolkit of security tools/protocols that are  
> well understood/reviewed and have developers consider possible abuses  
> of their protocols/services/software. Somehow we need to figure out  
> how to make this work in GGF. 

We considered tat: use callouts for streams, ACL for
services, and ACLs for jobs.  Would that be implementable
though?  No idea...


> I (and I'll be Olle) will be happy to  work with you on
> how to make this happen.

Many thanks!  So, lets continue per mail or on Wednesday.
We certainly are happy that we got your interest :-)

Cheers, Andre.

PS.: Disclaimer: the statements above are my personal
opinion.  I think we have widely varying ideas about
security in our group, but we are not qulified enough to
make good decisions - and I am the least qualified one I
guess... :-P



> Cheers,
> Dane
> 
> On Feb 13, 2006, at 10:58 AM, Andre Merzky wrote:
> 
> >Hi group,
> >
> >we managed to corner the Security Area ADs at GGF in Athens,
> >and to get some statements from them in respect to:
> >
> >  "What security paradigms are generically available in
> >   Grids, and what should be exposed to the end user?"
> >
> >Well, their answer was basically, that there is no agreed
> >upon approach in the scope of GGF, so, the best we can do is
> >to look at Grid implementations, and abstract/generalize
> >their security paradigms.
> >
> >A viable approach in their opinion would be to base security
> >settings on strings, and allow the implementation to interpret
> >them accordingly.  That approach is very close to what we
> >have right now for sessions, and what we want to have for
> >streams.
> >
> >Shantenu and I discussed that shortly, and would like to
> >propose as follows:
> >
> >  - for the time being, keep security  out of the API where
> >    not absolutely necessary
> >  - where absolutely necessary (case by case), keep exposure
> >    of security paradigms simple and generic
> >
> >I think the notion of context that we have in the SAGA API fits
> >that approach well:  by default they are invisible.
> >
> >We would be happy to get comments, also from the Cc'ed
> >Security ADs (hope we interpreted your answer correctly).
> >
> >Cheers, Andre & Shantenu.
> >
> >
> >-- 
> >"So much time, so little to do..."  -- Garfield
> >



-- 
"So much time, so little to do..."  -- Garfield