Currently unresolved issues

This page contains a list of currently unresolved issues that need to be discussed. Some are specific to the GDS, which isn't yet agreed upon.

This page is split into two parts. Those questions that are mainly about how the SRM server behaves are first, followed by those questions about the SRM client. The distinction isn't always clear; if so then the question is in the server-part.

Server issues

These are issues mainly about how the server behaves.

1. Which delegation service will we use?

(I believe) our options are:

  1. gLite/GridSite Delegation Service (GDS),
  2. the IVOA RESTful service,
  3. something RESTful Globus are providing in the future.

To my mind, given our time frame, our only realistic option is GDS. However, this is subject to whether GDS is being supported during EMI. I'm working on getting clarification on this; for Java GDS is being supported by HIP, for the C-support is from CESNET.

The rest of this page assumes we're using GDS.

2. How do clients discover the delegation service?

(I believe) our options are:

  1. Use the same end-point as the SRM,
  2. Use an end-point derived from the SRM end-point,
  3. Provide a service-discovery mechanism.

Option a. is what FTS does and I think is the easiest, conceptually.

Option a. will work for Axis-based Java software and gSOAP-based C software.

Option b., would be a work-around if a. is not feasible for gSOAP.

I think no one is currently in favour of option c.

For RESTful services, this would depend on the namespace of the service.

3. The client tries to use an SRM operation that requires delegation, but without first delegating?

A client has requested an SRM operation that requires delegation; however, the server has no delegated credential for the client. What should the SRM do?

There are two decisions here: when should the SRM do something and what should it do.

Options for when:

  1. Immediately,
  2. When the operation is taken off the queue to run,
  3. As soon as it notices (somewhere between a. and b.)

Options for what should the SRM do with the request:

  1. Fail it with SRM_INVALID_REQUEST
  2. Fail it with a more descriptive error code (e.g., SRM_DELEGATION_REQUIRED).
  3. Treat it as if the client called srmSuspendRequest. Client may call srmResumeRequest once they have delegated.

4. The client requests an operation that requires delegation and the delegated certificate has expired?

This is similar to the previous scenario, except that the client has delegated a credential in the past. However, time has elapsed between the client's delegation and the SRM request and, in that time, the delegated credential has expired. What should the SRM do?

Again, there are two decisions here:

First, when should the SRM do something:

  1. Immediately,
  2. When the operation is taken off the queue to run,
  3. As soon as it notices (somewhere between a. and b.)

Second, what should the SRM do with the request:

  1. Fail it with SRM_INVALID_REQUEST
  2. Fail it with a more descriptive error code (e.g., SRM_DELEGATION_REQUIRED).
  3. Treat it as if the client called srmSuspendRequest. Client may call srmResumeRequest once they have delegated.

5. Should SRM insist in a minimum delegation credential lifetime?

An SRM [must not | should not | may | should | must]* reject a request where the client has provided a delegationID corresponding to a valid credential but where the certificate has only a "very short" lifetime (e.g., a few seconds) remaining?

* -- as per-RFC 2119.

6. What should happen if a delegated credential expires before the operation starts?

SRM operations may take some time before they start. In that time, the user's delegated credential expires. What should the SRM do?

Again, there are two decisions here:

First, when should the SRM do something:

  1. Immediately,
  2. When the operation is taken off the queue to run,
  3. As soon as it notices (somewhere between a. and b.)

Second, what should the SRM do with the request:

  1. Fail it with SRM_INVALID_REQUEST
  2. Fail it with a more descriptive error code (e.g., SRM_DELEGATION_REQUIRED).
  3. Treat it as if the client called srmSuspendRequest. Client may call srmResumeRequest once they have delegated.

7. What should happen if a delegated credential expires after an operation starts?

A delegated credential is valid when a queued SRM operation is started but expires while the operation still requires use of the delegated credential.

An example story is when a client has requested srmCopy with a list of sourceSURL in the TCopyFileRequest and each sourceSURL is for a different storage-elements. The SRM start processing these requests sequentially and, before starting the final request, the delegated credential expires.

(I believe) our options are:

  1. Return an overall status of SRM_PARTIAL_SUCCESS. The file-level result for those files transferred while the certificate was valid are as normal; for the file transfers that failed SRM_FAILURE is returned.
  2. Suspend the transfer, as if the client called srmSuspendRequest. Client can call srmResumeRequest when proxy has been renewed.

8. What if the client renews a proxy certificate before the operation has started?

GDS supports the renewProxyReq operation. This allows a client to update the delegated credential, for example, if the existing credential is about to expire. What should happen if a client renews a proxy certificate after submitting an SRM request to the server?

(I believe) our options are:

  1. Fail the request with SRM_INVALID_REQUEST,
  2. Ignore the new proxy certificate,
  3. Accept the new proxy certificate.

9. What if the client renews a proxy certificate after the operation has started?

The client can call the renewProxyReq operation to create a new delegated credential if an existing one is about to expire. What should happen if a client does this after the SRM has started to process the request and while the credential is still needed (e.g., multiple files being transferred from different storage-elements).

(I believe) our options are:

  1. Fail the request with SRM_INVALID_REQUEST,
  2. Ignore the new proxy certificate,
  3. Accept the new proxy certificate.

10. What happens if a client calls destroy on a certificate after submitting an SRM request but before the operation has started?

GDS supports the destroy operation, which "destroys the delegated credentials associated with the given delegation ID immediately."

The requested SRM operation has been accepted and queue, but the client then calls destroy before the operation has started.

There are two decisions here: when to do something and what that something is.

First, when should the SRM react?

  1. Immediately after destroy is called,
  2. When the operation is taken off the queue to run,
  3. As soon as the SRM notices (somewhere between a. and b.)

Second, what should the SRM do with the request:

  1. Fail it with SRM_INVALID_REQUEST,
  2. Fail it with a more descriptive error code (e.g., SRM_DELEGATION_REQUIRED),
  3. Treat it as if the client called srmSuspendRequest. Client may call srmResumeRequest once they have delegated.

11. What happens if a client calls destroy on a certificate after an SRM request has started?

The requested SRM operation has been accepted and started, but the client then calls destroy before the operation has completed.

(I believe) our options are:

  1. Return SRM_PARTIAL_SUCCESS, with the individual file result of SRM_FAILED for all parts that were unsuccessful.
  2. Put the operation into suspended state, as if the client called srmSuspendRequest.

Client behaviour

These are questions about how the client should behave.

1. How do the clients know which SRM operations require delegation?

(I believe) our options are:

  1. Leave this unspecified (as is currently),
  2. Formally state which methods require delegation and a mechanism to update this list,
  3. Provide a mechanism for a client to discovery the list from the server.

I would like us to improve upon the status quo here.

2. Before submitting an SRM operation that requires delegation, does a client always delegate?

The SRM server stores delegated credentials. An SRM client may have already delegated a credential in the recent past that could be used for this operation. If so then further delegation is unnecessary: the server could use the existing credential.

Should a client delegate, under these circumstances?

Note that GDS will throw an exception if a client attempting to delegate to an already-delegated delegationId and allows the client to discover how long an already delegated credential is valid for.

3. What Delegation-ID should clients use when generate a proxy certificate?

GDS has the concept of an auto-generated (or default) delegation ID. If the client leaves the delegationId String empty then the GDS server will generate one automatically, based on a hash of the existing credential's DN and FQANs.

(I believe) our options are:

  1. Clients try to use the default delegation ID,
  2. Clients always generate a unique delegation ID,
  3. Leave this unspecified.

There are advantages to a. and b. (Paul favours a.)

4. How does a client communicate the delegationID to the server?

When a certificate has been delegated, there is a reference (delegationID). How should this delegationID be communicated to the server?

There are two decisions: how it is transported and what encoding to use:

Transport:

  1. using the authorizationID parameter,
  2. using a key-value pair with TExtraInfo[].

Encoding:

  1. as the raw delegationID
  2. as a simple URI (e.g., delegationid:01892833)
  3. as a URI that also mentions which service was used (delegationid:gds:01892833).

5. How does a client tell a server it created a credential without delegationID

If the client delegated a credential without specifying a delegation ID then (Paul believes) there is no way the client can discover the hashed value used by the server as the delegation ID.

If so then the client that specified an empty delegation ID must indicate this by some other means.

Possible options include:

  1. specify an empty string,
  2. specify a keyword, for example DEFAULT
  3. take an invalid delegation ID (e.g., @DEFAULT@ ), apply any encoding (see previous item) and sent that.

6. What responsibility does the client have WRT expiring credentials

The delegated credential has a finite lifetime, so can expire.

The getTerminationTime operation provided by GDS allows a client to monitor how long before a delegated credential will expire. This gives the client the opportunity to renew the credential.

What is the client responsible for?

(I believe) our options are:

  1. Returning accurate information to end-user if the SRM operation fails due to credential expiring.
  2. Periodically monitoring the credential and renewing if credential is about to expire.

-- PaulMillar - 01-Nov-2010

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2010-11-03 - PaulMillar
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback