Hi Andrea,
The local name is used to set up a GridMap object for the delegated resource, to ascertain access rights on refresh of the delegated credential. I think it should be feasible to remove the gridmap file dependency and allow for any authorization mechanism and set up a simple identity authorization based on the authorized subject DN of the creater of delegation resource. I can file an enhancement request for this. If you are looking to work on this and can provide a patch, it would be most useful! Any service in the container has access to the delegated credential. The authorization for retrieval of credential determines of the credential is retrieved for the user who delegated, which is explained here: http://www.globus.org/toolkit/docs/4.0/security/delegation/developer-index.h tml#id2530447. I agree that this is a cause of concern if malicious service is deployed in the container. We don't have any immediate plans to enhance this feature, but if you are looking into this, we will certainly work with you. If you would like to discuss this further, you can use the delegation service development list, [EMAIL PROTECTED] I don't have performance numbers per invocation, but I wouldn't expect the getCertificateChainRP to be slower. Was this the case in all subsequent calls to the service or only on the first invocation of the service? The first method invoked on the service causes all the security properties to be loaded by and some other initialization steps. Rachana _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrea Turli Sent: Thursday, February 14, 2008 9:49 AM To: [email protected] Subject: [gt-user] About delegation Service Hi all, I'm evaluating the adoption of the GT4 Delegation Service in my project. Studying the documentation and making some tests, I have noticed two things: service implementation depends on grid-map file and it supports persistence of credentials delegated by default. In fact: * Delegation Factory Service needs the grid-map file. Looking at the source code, I have discovered that information retrieved by grid-map file (basically the "local name" of a unix's user) are used to label the persisted resource, correct me if I'm wrong. Could you explain me why do you need the local name to store the delegation resource? if it is not strictly needed maybe delegation service could be grid-map independent and in this way developers can use it inside a different authorization mechanism (not based on local grid map file). * Credential Storage: as far as I have understood, correct me if I'm wrong, any service deployed in the container can access the persisted credentials without any restriction. Maybe this could become a security issue in some cases (i.e.: if I cannot control the behavior of a deployed service) or not ? For these reasons, I want to ask if it is (or will be soon) possible to disable the grid-map file dependency and the persistence mechanism in GT4 Delegation Service through, for example, setting jndi properties ? Moreover I'd like to know if it is normal that the invocation to static X509Certificate[] getCertificateChainRP(String delegationUrl, ClientSecurityDescriptor secDesc) is significantly slower than public static EndpointReferenceType delegate(String delegationServiceUrl, GlobusCredential issuingCred, X509Certificate certificate, int lifetime, boolean fullDelegation, ClientSecurityDescriptor desc) And if yes, how can I speed up this invocation? Sorry for the long post ... Thank you in advance, Andrea
