On Thu, Mar 26, 2009 at 7:16 PM, Steven Newhouse <Steven.Newhouse@cern.ch>wrote:
Having to build adapters to translate (if possible) credentials in different formats is a compromise which is more reasonable than having to wait for all the middlewares of the world to move towards a common security infrastructure.
In the short term... documenting and defining the 2 or 3 security models is real progress. If a service only supports one of these I do not see this as a problem - for all the reasons given.
I do agree with this point here. But I would propose a question: What is the purposed of PGI? Does it only conclude all of the popular middlewares and propose a few conclusive profiles? Or does it give some proposal which is as general as possible, and needs those middlewares to change as minimal as possible? If the former one is the case, I agree with the "bridging" idea. And it is also what ARC has done and is doing: Trying to implementing some specific clients which can interoperate with those services hosted by different kinds of middlewares that require different security mechanisms. For instance, for interoperability with CREAM service, the client developed in ARC need firstly to contact the CREAM delegation service and delegate a proxy credential to that service, and secondly send real BES message to CREAM service together with the delegation ID which is got from the first step. The CREAM service itself will implicitly get the proxy credential by using the delegation ID, and then act on behalf of the client. Weizhong Qiang
Providing credential translation services to provide 'shims' (or bridges between these islands) as an interim solution makes this work. Its a low risk to individual services - they maintain their current stability - and can migrate over time to support both or the most 'popular' one - let the market decide!
Each service can then advertise the mechanisms it supports and clients can locate credential translation services as required. _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg