• Date: 19 Dec 2007
• Time: 9 AM Chicago, 3 PM London, 4 PM Rome (conversion to other timezones)
• Duration: 1,5h
  • traditional phone: +39 051 054 6636 (or any other on this list)
  • SIP-based phone: instructions
  • PIN: 1020
• Shared screen session information:
  • URL: http://glue-wg.glance.net
  • Key: 1912

Agenda

1. Policy in Main Entities - artf6080
2. artf6095 - Values when Unknown
3. planning telecon in Jan08
4. AOB

Participants

• Sergio Andreozzi (CNAF)
• Marco Canaparo (CNAF)
• Paul Millar (DESY)
• Laurence Field (CERN)
• Balazs Konya (Lund University)

Minutes

Item 1

Discussion on policy

Balazs suggests to have AuthorizationServiceURL property in endpoint artf6080: Sergio reports feedback from talk with security people the short summary is that from the security area viewpoint, it is not advised to model the concept of policy in GLUE for the following reasons:

• GLUE is mainly targeted at describing service capabilities and status to be published via information service;
• the information service is not considered the right place where to publish authorization information;
• if we model the concept of policy, information consumers may be driven to use the info service as a policy decision point in order to discover where athorization is granted for a certain user/group/vo;
• the actual authorization decision is performed based on local authorization services or distributed authorization services which policies are not in sync with the potential ones in info services

• Stephen: for EGEE, there is need for basic authZ info like this: VO names, VOMS FQAN and (ALLOW)/DENY is enough

• JP: in TeraGrid we do not publish any policy information;

• Stephen: how do you know what resources can you use?

• JP: the client services know by static configuration which resources they can access; TeraGrid maintains an "internal" database with association among users and authorized services
• Balazs states that ARC won't have a distributed authorizatiion service; every service will have its own authZ service with local policies; no mechanisms for automatic policy distribution is envisioned;

we agree what follows:

1. refine definition of policy in order to state the coarse-granular nature
2. JP to talk to colleagues in Teragrid in order to understand their viewpoint on this topic

discussion moves to support for description of many policy schemes:

• Balazs: we can have more policy schemes and rules for the same pair of instances (UserDomain, Endpoint)

• tentative solution: add the concept of policy set which is a set of rules according to a certain schema

<AccessPolicy>
   <PolicySet>
      <Scheme>...
	  <Rule>
	  <Rule>
   </PolicySet>
   <PolicySet>
      <Scheme>...
	  <Rule>
	  <Rule>
   </PolicySet>
</AccessPolicy>

AccessPolicy
     |
     |
   (*)
PolicySet

Use Case for policy-related info usage:

• in job submission, we want to filter resources by VO

 
<AccessPolicy>
   <Rule>VO:CMS</Rule>
   <Rule>VO:ATLAS</Rule>
   <Rule>VOMS:/CMS/production</Rule>
   <Rule>VOMS:/CMS/analisys</Rule>
   <Rule></Rule>
</AccessPolicy>

• open questions:
  • how do we support multiple schemes for the rules

Item 2

artf6095: Paul describes the two scenarios reported in his email Action on Paul to draft an appendix to address this problem: artf6104

Item 3

proposed telecons in Jan

• 16, 18
• 22, 24
• 29, 31 at least 2 of them in late morning for Australians