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.