EMI JRA1.3 SRMSEC Meeting

JRA1.3

Date: 2011-01-14

Present: Alex Sim, Jean-Philippe Baud, Paul Millar

Updates on recent activity

Written SRM-over-SSL document as starting point.

There is a document that is a first-draft of how SRM could work over SSL.

Prototype server and client

With the release of dCache v1.9.11-1, we have client and server implementation of SRM-over-SSL with some limitations. The command-line client can speak GSI or SSL, but requires a command-line option to specify which one to use. The dCache server can listen on GSI and SSL connectors or both. The server's support for srmCopy uses either GSI or SSL but which one to use is a configuration option. There's no support for delegation.

Setting up a reference end-point

Paul reported that he is in the process of setting up a reference SRM instance for people to test against. He anticipates this being ready in roughly a week's time (21st January).

EMI delegation

Within EMI there is now a task-force looking into standardising software components use of delegation. This is currently based on the GridSite delegation protocol. Paul is chairing that task-force.

OGF standardisation

Paul has requested a BoF session at the next OGF meeting to investigate whether establishing GDS as an OGF standard makes sense. This will likely involve creating an INFO document first, describing GDS.

What still needs to be done?

Here's the current list:

  • Basics of SRM-over-SSL document
  • Which delegation service to use?
  • Delegation service discovery
  • Only delegating when needed.
  • Migration strategy.

Nobody could think of any additional items.

Which delegation service to use?

Nobody could think of a use-case for supporting multiple delegation services and everyone agreed that GridSite delegation was a reasonable choice.

How to discover delegation service?

Everyone agreed that clients can assume that the GSD endpoint is the same as the SRM endpoint (but with a different handler).

FTS already does this for Axis (Java).

Thanks to Jean-Philippe's work in tested gSOAP-based servers, we know this is is possible for C-based servers.

Only delegating when needed

Paul described this issue: as a guideline from security, clients should delegate only when it is necessary. This poses a problem for SRM as the client initiates the delegation process; the server knows which operations require delegation but has no mechanism to communicate this to the client.

Paul proposed a solution: add an additional Return Status Code (TStatusCode). This could be called something like SRM_DELEGATION_REQUIRED.

It may be possible to add this extra return status code while remaining backwards compatible if servers ensure that SRM_DELEGATION_REQUIRED is never returned to GSI clients. The rational is that, in the WSDL, TStatusCode has type xsd:string with a restriction: a set of valid values. A client should be unable to distinguish between a server that uses the current SRM 2.2 WSDL and one that uses a WSDL with SRM_DELEGATION_REQUIRED but elects never to return SRM_DELEGETION_REQUIRED.

Further investigation was needed to see if this is backwards compatibility is really the case.

Paul proposed to make this change to the WSDL for the reference machine, to allow some checks.

Migration strategy?

There was some discussion on how to roll out SRM over SSL. One issue is whether we need to support a "mix-mode"; for example, one possible roll-out strategy is:

  1. Start roll out new software
    1. servers that support both GSI- and SSL- based communication.
    2. clients support GSI- and SSL- based communication, using GSI by default.
  2. manually test that clients can talk to servers using SSL.
  3. update client's configuration to use SSL by default. They would use GSI only as a fall-back.

This is "mixed-mode" because the grid would support both GSI- and SSL-based SRM.

Jean-Philippe felt that updating software will take some time (measured in years). This would require a mixed-mode.

Alex mentioned that the process is much simpler in OSG. OSG are able to upgrade sites pretty much in "one go" (a process taking a few months). However, OSG instances need to work with instances from European partners, so the security interoperability is very important.

Feedback on this meeting

People felt that the DESY phone system was reasonable quality. Jean-Philippe felt making a phone call was simpler, but Alex felt using Evo would be preferable. Paul was happy with either option.

The decision was to try Evo for the next meeting, so we can better compare the two.

DTNM

We agreed to have roughly monthly meeting, during the first full week of a month, but that we can hold ad-hoc meetings if some topic comes up that people feel needs more intense discussion.

This places the next scheduled meeting some time between 7th and 11th February. Paul will send a Doodle poll around to figure out what time is best for everyone.

-- PaulMillar - 14-Jan-2011

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2011-01-14 - 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