[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ggf-ogsa-sec-wg] Re: Working towards the WG deliverables: archtitectureand roadmap


Frohner,

Thanks for your valuable comments.  I agree that WSDL interfaces for the security services are important to be defined for interoperable OGSA infrastructure. Based on the discussions in the past, at GGF meetings, etc.. the suggestion was to identify and agree on the services, their purpose and possibly the interaction between the services. This will help identify the components that make up the OGSA Security Infrastructure.

Next step is to identify and prioritize the services that need to be defined to make meaningful progress in the delivery and build out of an OGSA environment. This is the roadmap piece/document. During the GGF meeting, Dane suggested that we identify handful of services and prioritize them. Through the GGF process, we can then decide if those services need to be handled by a new WG, or one of existing WGs. This is similar to what OGSA WG is doing ..defining services that make up an OGSA environment, and encouraging formation of new WGs to handle those service definitions.

All we are proposing is to start identifying and defining the purpose of those services (in english and not WSDL) in the architecture documents and lay out a roadmap. This can serve as a reference security architecture  (similar to OGSA architecture serving to be a reference for all of OGSA related services) that we can rally behind. I am not undermining the importance of real interfaces and implementations. Formation of OGSA-AUTHZ WG is a good example of where we identified and decided on working on a particular service definition. But that is going to take time and we may also want to reconcile and work with other efforts in relevant standard groups, if any.

In short, I agree with your valuable comment and the need for moving forward by defining interfaces. At this time in this WG, we are trying to narrow the focus (thats what the charter did too) of these documents to identify the services and then let other WGs help drill down into interface definition.  Sounds reasonable?

Thanks
-Raj




FROHNER Akos <Akos.Frohner@cern.ch>
Sent by: owner-ogsa-sec-wg@gridforum.org

03/19/2004 03:13 AM

Please respond to
Akos.Frohner
To
Nataraj Nagaratnam/Raleigh/IBM@IBMUS
cc
ogsa-sec-wg@ggf.org
Subject
[ggf-ogsa-sec-wg] Re: Working towards the WG deliverables: archtitecture and roadmap





Hi,

I have raised my hand, so let me give you some comments to start with.
So far OGSA-Sec was hanging in the air without any real implementations
behind, so it is hard to comment on something, which I cannot test.

To make this group useful for the future I suggest a slight change on
the emphasis: you have a good top-level overview of the required security
services, so start describing those services in detail!

And start from a minimal set, which already exists today, although
not with web services interfaces. So wrap them in WS, agree on the
interface, so we can start using them. After this first cycle we can
feed back our experiences on the APIs and on the more sophisticated
services.

To give some example (according to your docs):

 Authentication: there are a couple of online CA proposals, which
   intend to provide a proxy for a session. Like MyProxy and once
   there was also the Virtual Smart Card project at SLAC.
   
 Delegation: the only feasible solution I know today is the GSI
   delegation, aka httpg. Have it documented here or anything
   similar. I know this is not ideal, because you cannot give
   sophisticated restrictions, but it works, and we want to use
   something in the services we write today.
   Once this is settled, we can move on to restrict it. But
   there are many groups out there dealing with policies, so
   the scope of this group should be really the protocol.

   Also think about internal API for the services, on how can
   they use the delegated credentials.

 Credential Lifespan and Renewal: the only solution I know of
   today is EDG's modified MyProxy service, which provides proxy
   renewal for long running jobs. Have it described, documented,
   so other can comment on it and/or give their solutions.

   This is a good place for joint activities with Scheduling
   (long running jobs) and Data area (long file transfers).

 Attribute services: CAS, VOMS, Permis provides attribute certificates
   and I am sure there are many other attribute provides in other
   formats (e.g. local account database w/o AC format), so gather
   them and standardise the way a user (push model) or a service
   (pull model) can access them.
   I can give a the WS interface of VOMS core as a starting point.

 Authorization: this should simply move to the OGSA-Authz group.

 Privacy, Confidentiality, Message Integrity: covered by XML
   security standards, so no need to describe them here again.

 Policy Exchange: covered elsewhere.

 Secure logging: I don't think it is OGSA specific, but rather
   a generic security issue. One can think of specialities on
   the subject (e.g. agreement on the logging format of DN to
   local username mapping).
   Once it is clear what has to be logged, then one can think
   of wrapping existing logging services in WS.

 ...

 and so on.

If this group can address the first four by June, I would be happy.

Cheers,
   Akos
--
FROHNER Ákos/CSO/IT/CERN -- http://cern.ch/hep-project-grid-scg