I'm open to suggestions on the right way to refresh the credentials of running
jobs. It seems to me that 
we need service data for the ManagedJob instances telling us the DN and
expiration time of the job's 
credential, and we need that service data to be updated when we refresh the
job's credential.

I believe that according to Sumin's testing, when we delegate a new credential
to the ManagedJob 
instance, the ManagedJobImpl refreshCredentials() method isn't called.  Is that
expected?

Also, if we just want to delegate a credential to a service, is there a
recommended service method we 
should call?  I guess we want a method as close to a no-op as possible because
we're just interested in 
doing the delegation.  Is findServiceData() a good method to use for refreshing
service credentials?

I do not think that I made my test result clear. What I observed is that if we 
use findservicedata() to refresh the credential, the credential do get 
refreshed because it does not throw "expired credential" exception even though 
the original credential is expired already. However, refreshCredentials() 
method does not get called. If we add a method to update the termination time 
and call this method when we refresh the credential, not only the termination 
time is updated, but also refreshCredentials() method is called.

I am not sure what is the reason. I guess that when we call findservicedata() 
to refresh the credential, some method in ManagedJobImpl's superclass  is 
called. However, if the newly added method is called to refresh the 
credential, refreshCredentials() in ManagedJobImpl is called.

I think we need a dummy method in ManagedJobImpl. Whenever this method is 
called, refreshCredentials() method will be invoked. And we can update the 
info on the new credential in refreshCredentials() method.

thanks.

Sumin
 

If the delegated proxy (DP) has expired then client attempts to authenticate to
the MJS 
should fail.  But that does not appear to be what you are reporting.  Can you
confirm this?

If the MJS DP has not expired and you attempt to delegate via FSD, what is the
result?

Hi, Martin

We CAN successfully refresh the credential when the old one is soon-to-be 
expired. However, the current Gobus does not provide all the interfaces we 
need. For example, it does not provide an interface to check the job 
credential's termination time. (How can we know when to refresh the credential 
if we cannot get the termination time? :-)) We have to modify the source code 
to 1) add service data such as the job credential's termination time and  2) 
add a method to update the termination time when the credential gets refreshed.
We are wondering whether or not Globus can add such features, since they are 
critical for job credential refresh.

Thanks.

Sumin

There are plans for a new GT service to manage credential delegation
(delegation 
service - DS).  The current plans are that a client can delegate a credential
(user proxy) 
to the DS and then tell the MJS or RFT to use the credential from the DS.  This
will not be 
in place for GT 4.0, but should be in a subsequent GT release.

Would your needs be satisfied if the DS offered state change notifications? 
For example, 
if you could receive a notification every hour for the # of valid hours left on
the delegated 
credential?

For the MJS to offer this same information would seem redundant.

-Stu

I'd prefer an interface whereby I could query the lifetime of DS credentials
rather than requesting an 
(unreliable?) notification. Also, I'd want to be able to query the MMJFS data
to find out what DS 
credentials my jobs are using, so I don't need to track that separately. And
first, I'd like to be able to 
query the MMJFS to find out what jobs I have running, i.e., which jobs I own or
which jobs are running 
with my identity, again, so I don't have to track that separately.

Agreed.  Those requests are reasonable.  The idea is that a client would tell
the MJFS, 
here is the key (or ID) to the DC that has been created in the DS.
Then the MJFS would fetch the DC from the DS and publish the key so a client
can 
retrace it's steps to find out info about the credential it delegated to the
DS.  The 
notification was just an example, the same information could be queried from
the 
delegated service.

I believe the functionality requested has been implemented in GT 4.0 beta
(3.9.5).  A client can query a 
delegation service resource for credential lifetime and subscribe for
notifications if desired.

A client can find the delegated creds used for each job by querying the RP
serviceLevelAgreement and 
looking for the jobCredentialEndpoint stagingCredentialEndpoint.

The job lifetime and the delegatedCred lifetimes are separate and should remain
so.  If a client wants 
them to be the same, then they can make it so.