July 2005 - ogsa-d-wg - lists.ogf.org

Data Use Case Scenarios document
by Stephen Davey 10 Aug '05

10 Aug '05

Hi everyone, Attached is the beginnings of a list of Data Use Case Scenarios, which also includes the template sub-sections for each use case described. I have basically taken the original OGSA use case template and merged the "Use Case Situation Analysis" section into the "Summary" section 2.1 and renamed section 2.4 slightly. I have also deleted sections 2.5 & 2.6 since security and performance considerations will be part of the Data Architecture document and would probably have just led to repetition. This then leaves the sections: 2.1 Summary 2.2 Scenarios 2.3 Involved Resources 2.4 Functional Design 2.5 References Hopefully these sections will be all that is needed for the Data (infrastructure) Use Cases that we have. Any comments can be discussed on Wednesday 15th June. Cheers, Stephen. ------------------------------------------------------------------- Stephen Davey, NextGrid Software Architect, National e-Science Centre, 15 South College St., Edinburgh, EH8 9AA, UK Tel: +44 131 6 509820

2 1

Teleconference Agenda for 3 August 2005
by Allen Luniewski 29 Jul '05

29 Jul '05

The next teleconference of the OGSA Data Architecture working group will be held on Wednesday, August 3, 2005 at the usual time of 8:00am PDT / 11:00am EDT / 4:00pm BST / 5:00pm CEST. As a reminder, here is the teleconference information: UK Dial In: 0845 245 0224 US Dial In: 1 866 838 0046 International Dial In: +44 1452 542309 PIN: 369 786 Agenda for the August 3 teleconference: 1) Early discussion (2 minutes) Note taker assignment Roll call Minutes approval (http://tinyurl.com/cscc2) Agenda bashing 2) Action report (5 minutes) - Mario to ask an OGSA-DAI staff member to write something on the security issues around OGSA-DAI [Ongoing] - Dave to consult OGSA WG security design team [Ongoing] - Dave to revamp section 3 of the architecture document [Ongoing] - Mario to ask an OGSA-DAI staff member to write something on the security issues around OGSA-DAI - Dave to consult OGSA WG security design team - Dave to revamp section 3 of the architecture document - Bill to scope the proposed WG for byte-level transfer. 3) Use Case Scenarios Document Discussion (50 minutes) See Dave Berry's note of 26 July for the latest version. We will use this time to discuss issues with the use cases and to plan evolution of the document. 4) Wrap up (3 minutes) AOB Allen

1 0

OGSA-D Minutes (July 27 + GGF14)
by Dave Berry 28 Jul '05

28 Jul '05

I've added recent minutes to GridForge: Notes of the GGF14 Sessions: http://tinyurl.com/bzh4g Minutes of the July 27th telcon: http://tinyurl.com/cscc2 Note that I will be on holiday next week, so it's over to Allen to organise the call. Dave.

1 0

FW: ogsa data scenarios v0.3
by Dave Berry 26 Jul '05

26 Jul '05

All, Here is Stephen's revision of the OGSA Data Scenarios document. I would like to allocate some time in a future telcon to discuss this and how it fits with the architecture document. (E.g. the names of services and interfaces in the two documents should be chosen to agree with each other). Some of tomorrow's discussion on data transfer may affect the replication scenario, as that requires data transfer functionality. Best wishes, Dave. _____ From: Stephen Davey Sent: 26 July 2005 15:03 To: Dave Berry Subject: ogsa data scenarios v0.3 Hi Dave, Attached is my latest data architecture scenarios doc with the final additions to the data replication use case. In the intro section I have also tried to divide up the data scenarios into simplified architectural patterns which hopefully capture the characteristics of the different use cases. Please forward it to everyone if you are happy with it. Cheers, Stephen. ------------------------------------------------------------------------ ----- Stephen Davey, NextGrid Software Architect, National e-Science Centre, 15 South College St., Edinburgh, EH8 9AA, UK Tel: +44 131 6 509820

1 0

Regrets -- week of July 25-29
by Fred Maciel 23 Jul '05

23 Jul '05

Hi, On the week of July 25-29 I'll be in the SNIA/DMTF Technical Symposium. Regards, Fred Maciel Hitachi America R&D

1 0

FW: Aug F2F session schedule
by Dave Berry 22 Jul '05

22 Jul '05

All, An OGSA Data F2F is currently scheduled for the afternoon of Thursday August 18th, in Sunnyvale, California. This is part of a week of OGSA-related sessions - see the attached [lan for the full timetable. Best wishes, Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: 19 July 2005 07:28 To: 'ogsa-wg' Subject: Re: Aug F2F session schedule (Re: [ogsa-wg] Teleconference minutes - 13 July 2005) Hi all, The attached is what we've agreed on the call today. We've put "OGSA-naming" into Wednesday morning and one of OGSA-WG session into Thursday morning. Since several folks will catch noon flights we will start 8am on Thursday and Friday. In order to balance duration of morning and afternoon sessions, Monday - Wednesday sessions are 9am-12:30pm and 1:30-5pm (3.5 hours each). Thanks, ---- Hiro Kishimoto Hiro Kishimoto wrote: > Thanks Andreas, > > Please correct if I am wrong, but the following is not exactly > the same I remember. > > >>** Schedule >> >> - ByteIO requested an earlier slot (not Friday) >> - Mark has to leave early and Neil cannot make Friday >> - Considered and rejected moving Naming to Friday >> - It is likely that ByteIO will not need a half-a-day slot. > > > <HK> > I said that if we will review there working draft, we need half-a-day. > </HK> > >> - Agreed that having a regular session on Friday is not a good >> idea. Friday morning should be reserved for wrap up. >> - And that the sessions could start earlier on other days to >> accomodate the extra session. >> >> - Agreed to start early on Thursday and put ByteIO in that slot. > > > <HK> > I think we agreed to put ByteIO in Tuesday morning (starting 9am). > And put OGSA-naming to Thursday morning (also starting 9am). > > See attached ppt slide. > </HK> > >> - WSDM conflict >> - Jay/Fred could not contact Heather yet. >> >> - Not sure about Allen L's schedule. (Affects Data session) > > > I touched with Allen and he is likely to come and prefers to have > OGSA-data session later that week. > > Let's confirm these during minutes approval today. > ---- > Hiro Kishimoto > > Andreas Savva wrote: > >>Minutes attached. >> >> - August F2F update (fixed: Aug 15-19, @Sunnyvale) >> - OGSA WSRF BP 1.0 Security section review >> - Other business >> >>https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050713 /en/1 >> or >>http://tinyurl.com/5fxfd/minutes-20050713/en/1

4 3

OGSA-D telcon for July 27th - transfer
by Dave Berry 21 Jul '05

21 Jul '05

Dear all, Next week's telcon will be on Wednesday (20th June), at the usual time of 8:00am PDT / 10:00 am CDT / 11:00am EDT / 4:00pm BST / 5:00pm CEST. The main topic will be data transfer. PIN for this call: 369 786 UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 Here is a provisional agenda. 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval (http://tinyurl.com/9k2gd) Agenda bashing 2) Action report (2 min) - Stephen to tidy the scenarios draft and circulate it to the list - Mario to ask an OGSA-DAI staff member to write something on the security issues around WS-DAI - Dave to consult OGSA WG security design team. - Dave to revamp section 3 of the architecture document 3) Data transfer discussion (40 min) - Following on from discussions at the London F2F and GGF14. - Are we agreed on a multi-level approach? - Can we characterise the low level? - Can we characterise the high level? - Do we have sufficient use cases? - Do we need to engage with the JSDL spec? 4) Planning (10 min) - Topics for telcons - F2F meeting, Thursday Aug 18th, Sunnyvale, California - Timetable for next GGF (Document submission - Sep 16th?, GGF - Oct 3-6) - Writing tasks - Use of trackers 5) Wrap up (3 min) AOB DONM Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: [ogsa-d-wg] OGSA-D telcon for July 20th - security
by Dave Berry 21 Jul '05

21 Jul '05

All, I attach the minutes from yesterday's call. These are also on GridForge. Dave. > -----Original Message----- > From: owner-ogsa-d-wg(a)ggf.org > [mailto:owner-ogsa-d-wg@ggf.org] On Behalf Of Dave Berry > Sent: 19 July 2005 09:58 > To: ogsa-d-wg(a)gridforum.org > Cc: David Chadwick; Takuya Mori; Frank Siebenlist; Von Welch > Subject: [ogsa-d-wg] OGSA-D telcon for July 20th - security > > Dear all, > > This week's telcon will be on Wednesday (20th June), at the usual time > of 8:00am PDT / 11:00am EDT / 4:00pm BST / 5:00pm CEST. We will have > one or more guests from the security area joining us. We > will also make > plans for the August F2F in Sunnyvale. > > PIN for this call: 369 786 > > UK Dial In: 0845 245 0224 > US Dial In: 1866 838 0046 > International Dial In: +44 1452 542309 > > > Here is a provisional agenda. > > 1) Early discussion (5 min) > Note taker assignment > Roll call > Minutes approval (http://tinyurl.com/cpfrt) > Agenda bashing > > 2) Action report (5 min) > > - Allen and Dave to mail co-chairs of other groups re our GGF sessions > [Done]. > - Dave to mail list with a summary of his discussion with > NeSC security > people. > - Stephen to update replication use case. > - Ann to organise the security notes we've taken so far into > a coherent > memo that we can take to the security working groups. > - Dave to revamp section 3 of the architecture document. > - Update on Liaison with other groups (e.g. security, GFS) > > 3) GGF report (5 min) > > - Data transfer session > - Outreach session > - Transaction session > - Other related workgroups etc. > > 4) Security discussion (30 min) > - How does existing security work impact the "data" space? > - What special security requirements does the data > architecture impose? > > 5) Planning (10 min) > > - Topics for telcons > - F2F meeting, Thursday Aug 18th, Sunnyvale, California > - Timetable for next GGF (Document submission - Sep 16th?, GGF - Oct > 3-6) > - Writing tasks > - Use of trackers > > 6) Wrap up (5 min) > AOB > DONM > > > Dave Berry > Research Manager, National e-Science Centre > 15 South College St., Edinburgh > Tel: +44 131 6514039 > >

1 0

FW: Re: Summary of a conversation on security
by Dave Berry 20 Jul '05

20 Jul '05

David's e-mail bounced. -----Original Message----- From: David Chadwick <d.w.chadwick(a)kent.ac.uk> Organization: University of Kent MIME-Version: 1.0 To: Dave Berry <daveb(a)nesc.ac.uk> Cc: ogsa-d-wg(a)ggf.org, Takuya Mori <moritaku(a)bx.jp.nec.com>, Frank Siebenlist <franks(a)mcs.anl.gov>, Von Welch <vwelch(a)ncsa.uiuc.edu>, Richard Sinnott <ros(a)dcs.gla.ac.uk>, Ally Hume <ally(a)epcc.ed.ac.uk> Subject: Re: Summary of a conversation on security Hi Dave I have tried to answer some of your questions below, esp. the ones that refer to PERMIS Dave Berry wrote: > All, > > The following summarises an e-mail conversation I had with some NeSC > staff last month about security and data services. The questions and > observations were made by several different people. The summary of the > summary is that there still seem to be open questions in this area. > > Dave. > > > Question 1: > What is the relationship between the native authorisation provided by a > data resource and the authorisation provided by a third-party system > such as PERMIS? In essence these are two hurdles that the subject has to jump over before he gains access to the data. First he has to get past PERMIS, then past the local access control scheme. In some scenarios the local scheme may be subordinate to PERMIS (if it trusts it sufficiently), and can give total access rights to the PEP (ie. the PEP is deemed to be an administrator). The PEP calls PERMIS to make decisions about the access control policy, and then it enforces the decision (grant or deny). In this case the only local access controls will be administrator/all. In other scenarios this is not feasible nor desirable. For example, when granting access to individual data fields in a database, it isnt possible to write a PERMIS policy for this since you would have to repeat the data items in the PERMIS policy (as targets). Thus you still need the internal access control lists for fine grained control. Some data resources offer very detailed authorisation > control, even to the level of an individual element in a very large > database. It would seem impractical to reflect this level of > authorisation in an external authorisation system. > Exactly my point above > Question 2: > OGSA-DAI and DAIS both allow users to create new resources (e.g. result > sets from a query on a data resource). Hence we need to provide some > access control to these resources to control who has access to them. Is > there a proposed solution to this that OGSA-DAI could look to adopt? > It is possible to create new PERMIS policies, since they are XML data structures, via a programmable interface. So the job that creates the data resource could also create a PERMIS policy for access to it. The job would then need to tell the SOA to sign this policy, and the PEP to load it, then it could be enforced. The automated management of policies is not currently part of the PERMIS release, but it is something we will be working on as part of the TrustCoM project over the next 18 months. > > Observation 1: > You can do VO authorisation in different ways and at different levels of > granularity. For example, in BRIDGES we do a check when users log in to > the portal. They then get to see whatever services are appropriate with > their role in the VO. Following on from this, we can do all sorts of > finer grained authorisation "at the service level" based on who they are > and what they are trying to do. Thus do they get access to the National > Grid Service, ScotGrid or just the Condor pool when running a BLAST job. > > You can define whatever policies you deem appropriate for data access > and release and do the checks at the authorisation level, but ideally we > want to have a model which scales. Hard-coding policies for table, > column, row access/use would work, but it ain't likely to scale up. > Another approach is also to look at static "user views" of the DB and > map these onto VO roles etc. This also has merit and would probably be > the most straightforward way to do the VO authorisation - DBMS > integration. > > We are looking at patient consent and controlled attribute release > combined with a distributed, delegated trust model. We want to support > scenarios where patients can decide for what purpose their data/records > can be used, e.g. Cancer research, and we automate this into our > authorisation process including doing checks such as only if ethical > committee X has agreed to it. > > > Observation 2: > Assume your OGSA-DAI build is PERMIS protected. The "Create New > Resource" method can be protected at the VO level by a PERMIS policy. > Users are granted or denied access based not on their authenticated > identity but their role within the VO. So in your PERMIS policy you will > have a role defined which will carry the privilege of being able to > "Create New Resource" on your OGSA-D service. It is up to the Attribute > Authority at the resource to assign these roles in a trusted manner to > users, then as long as the AA is trusted by the policy (which it > necessarily does), the authorization has been done at as fine-grained a > level as you wish. > > [Dave: This is fine as far as it goes, but it doesn't seem to answer the > question of what access control should be assigned to the newly created > resource. Perhaps we need some externalisation of these roles so that > the operation that creates the resource passes in a role (or some other > authorisation token). Obviously each "creation" role would have to > specify which access roles could be assigned by the creator.] > > > Observation 3: > A major problem that we encountered with developing the PERMIS story at > the VO level was a Catch-22 in that we want to restrict who can retrieve > what data, based on what the data is, but we can only find out what the > data is by retrieving it. By which time it's too late and the user has > got the data anyway, whether or not they're authorised. > > The problem seemed to be inherent in the per-method mechanism that SAML, > and therefore PERMIS, uses to enforce authorization. David Chadwick > brought this up at the A&A working group at the GGF13 and proposed that > SAML be developed to include a per-parameter mechanism. If a parameter > could be sent along with the authorization request then this would allow > a trusted third-party to retrieve the data from the DB and make a > decision about what data to release to the user, before it gets back to > them. GGF OK'd this and David Chadwick has a project to implement this. > This probably has implications as to how much control the DBA must give > up but we're not sure what they are yet... > > There are at least two issues here. Firstly the passing of the parameter from the user's request to the PDP. SAML does not support this, so we have to move on from the current OGSA Authzn profile to a more functional one. XACML does support the passing of parameters, so it is likely that XACML will become the profile for OGSA Authzn v2. Secondly, once the parameter is available to the PEP, who makes the authorisation decision, is it the PEP or the PDP or the DB itself? i) PDP. PERMIS is already capable of making the decision providing the PEP retreives the data item from the DB and passes this along with the user parameter to PERMIS. ii) PEP. PERMIS cannot currently pass the policy back to the PEP for it to make the decision. Thus would fall under the banner of returning conditions or obligations from the PDP to the PEP, which PERMIS currently does not support. Although in our plans we do propose to add obligations to PERMIS in due course (sorry I cant give timescales for this yet). iii) DB. The PEP could pass the parameter to the DB and let it make the decision as part of its local access control mechanism. But this is a decision for the application builder to determine. I hope the above are helpful to you regards David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

Summary of a conversation on security
by Dave Berry 20 Jul '05

20 Jul '05

All, The following summarises an e-mail conversation I had with some NeSC staff last month about security and data services. The questions and observations were made by several different people. The summary of the summary is that there still seem to be open questions in this area. Dave. Question 1: What is the relationship between the native authorisation provided by a data resource and the authorisation provided by a third-party system such as PERMIS? Some data resources offer very detailed authorisation control, even to the level of an individual element in a very large database. It would seem impractical to reflect this level of authorisation in an external authorisation system. Question 2: OGSA-DAI and DAIS both allow users to create new resources (e.g. result sets from a query on a data resource). Hence we need to provide some access control to these resources to control who has access to them. Is there a proposed solution to this that OGSA-DAI could look to adopt? Observation 1: You can do VO authorisation in different ways and at different levels of granularity. For example, in BRIDGES we do a check when users log in to the portal. They then get to see whatever services are appropriate with their role in the VO. Following on from this, we can do all sorts of finer grained authorisation "at the service level" based on who they are and what they are trying to do. Thus do they get access to the National Grid Service, ScotGrid or just the Condor pool when running a BLAST job. You can define whatever policies you deem appropriate for data access and release and do the checks at the authorisation level, but ideally we want to have a model which scales. Hard-coding policies for table, column, row access/use would work, but it ain't likely to scale up. Another approach is also to look at static "user views" of the DB and map these onto VO roles etc. This also has merit and would probably be the most straightforward way to do the VO authorisation - DBMS integration. We are looking at patient consent and controlled attribute release combined with a distributed, delegated trust model. We want to support scenarios where patients can decide for what purpose their data/records can be used, e.g. Cancer research, and we automate this into our authorisation process including doing checks such as only if ethical committee X has agreed to it. Observation 2: Assume your OGSA-DAI build is PERMIS protected. The "Create New Resource" method can be protected at the VO level by a PERMIS policy. Users are granted or denied access based not on their authenticated identity but their role within the VO. So in your PERMIS policy you will have a role defined which will carry the privilege of being able to "Create New Resource" on your OGSA-D service. It is up to the Attribute Authority at the resource to assign these roles in a trusted manner to users, then as long as the AA is trusted by the policy (which it necessarily does), the authorization has been done at as fine-grained a level as you wish. [Dave: This is fine as far as it goes, but it doesn't seem to answer the question of what access control should be assigned to the newly created resource. Perhaps we need some externalisation of these roles so that the operation that creates the resource passes in a role (or some other authorisation token). Obviously each "creation" role would have to specify which access roles could be assigned by the creator.] Observation 3: A major problem that we encountered with developing the PERMIS story at the VO level was a Catch-22 in that we want to restrict who can retrieve what data, based on what the data is, but we can only find out what the data is by retrieving it. By which time it's too late and the user has got the data anyway, whether or not they're authorised. The problem seemed to be inherent in the per-method mechanism that SAML, and therefore PERMIS, uses to enforce authorization. David Chadwick brought this up at the A&A working group at the GGF13 and proposed that SAML be developed to include a per-parameter mechanism. If a parameter could be sent along with the authorization request then this would allow a trusted third-party to retrieve the data from the DB and make a decision about what data to release to the user, before it gets back to them. GGF OK'd this and David Chadwick has a project to implement this. This probably has implications as to how much control the DBA must give up but we're not sure what they are yet...

2 1