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