Date: Oct 23, 2007 Present: VO Services: Gabriele Garzoglio, Ted Hesselroth, Igor Sfiligoi, Valery Sergeev EGEE: Oscar Koeroo, Alberto Forti Globus: Frank Siebenlist, Rachana Ananthakrishnan, Yuri Demchenko * Summary: - discussed the document on obligations common to the AuthZ Interoperability Group. Topics: -- need to investigate some types of the obligation attributes (e.g. list of integer) -- no formal XACML way of declaring obligation dependencies (e.g. MultipleGIDs makes sense only ig UIDGID or Username is specified) -- do we need a PoolName obligation i.e. unresolved PoolAccount name? This is a GPBox use case to be discussed at the security meeting at CERN -- when using the AFS token obligation, the handler must reject it IF the channel was not encrypted. -- we may not need the PrivilegeMask obligation anymore; using ACL's instead. - discussed PEP -> PDP communication. SAZ (site authorization service) needs more attributes than the typical request for local id mapping. Request context will use to pass attributes like DN, FQAN, CA, VO and to pass PEP capabilities - action items: -- Rachana will send a correction to the XACML example of List of Integer. -- Rachana will do tests with an Array of integers to see how this works in an obligation. -- Oscar will check if base-64 string is fine to represent an AFS token. -- Yuri: example of XACML interfaces will be published to this list -- Alberto: send what user attributes are encoded in the XACML for authorization via GPBox ------------ * "Obligations Common to the AuthZ Interoperability Group" document. Draft at http://home.fnal.gov/~garzogli/privilege/AuthZInterop/tmp/AuthZInterop%20XACML%20Profile%20v0.4.doc - Is the declaration for "list of integers" ok in the doc? It should be a complex data type, unbounded. We can create it. Rachana will send a correction to the XACML example. She can do tests with an Array of integers to see how this works in an obligation. Do we need tools or a wrapper to deal with complex types ? - How do we constraint the fact that an obligation needs another one? In principle, we could do it at the level of the application or externally. We are not aware of standard external methods e.g. in XACML. We will enforce it in the implementation of the obligation handler. - If it bad if the AFS token conveyed through the obligation is sniffed over the network? Yes. It must be securely transported. The handler will use the "AFS token" obligation only when privacy and integrity are enforced. Oscar has access to the full environment from the handler, so he can check. Oscar will check if base-64 string is fine for an AFS token. - Username: it will return the resolution of the pool account name. GPBox may need an obligation to return the pool name e.g. PoolName. In GPBox the PEP resolves the pool name to an account name. This will be discussed at the security meeting at CERN. PRIMA would not know how to deal with it. - RootPath and HomePath: Home path is relative to RootPath (it isn't a full path). In general, you do not strictly need UIDGID, but our use case does. - Priority: The higher the integer the higher the priority. Priority is related to the place in the data request queue. - Privilege Mask. May not use it because of the ACL in Chimera. We may use this in 1 year. ---------- * Requirements for beta version of the library, including new requirements from SAZ. This is the context: - What requirements do we want the beta version of the library to satisfy? I'd like to go over the original list and add / select requirements http://cd-docdb.fnal.gov/cgi-bin/RetrieveFile?docid=2339&version=1&filename=AuthZInterop-Jul10-07.ppt Valery: SAZ implements an authorization service using white/black-lists. The SAZ client (PEP) receives yes/no from the SAZ server (PDP). The SAZ client is stand-alone or integrated with a resource gateway. PEP can send a proxy in the request (e.g. as a string) or PEP can parse the proxy and send only the relevant attributes. We'd like to do the latter. SAZ server takes decision based on DN, CA (issuer), VO, role. SAZ does not issue any obligation. In the future, we might need to extend SAZ server with time restrictions using e.g. an obligation with "Not before" and "Not after" attributes. Yuri: we are interested in time restrictions Igor: From the PEP, we should pass all info that we know about the proxy. We can pass attributes as a base-64 encoded string or attrib. by attrib. In the future we might need attributes that are not relevant today e.g. level of delegations, certificate chain, etc. How is it done today? Rachana: for the AuthZ framework in the GT context, PIP pulls off different info and push it in the authz framework. In GT 4.0.x, the attributes are stored in the authorization context. You need the right attribute id to extract the info. Today, we only need DN and issuer. We have a special VOMS PIP that knows how to parse VOMS attributes. The syntax is attributeid = value, where value can be any java object. These attributes will be available in the message context. In XACML we can do it in request context. With SAML, we could push only a restricted number of attributes. Frank: in GT, we could create a SAZ PIP that collects all the required attributes from the certs. It will be part of the request context. Igor: we'd like to have a PIP that can extract all attributes. Frank: we have to standardize names and data types for each attributes. All: we agree Alberto: for GPBox, we put user attributes in the XACML . To generalize this, we still need to agree on the attribute ids and data types. Today, our PEP has DN and FQAN, in the . Oscar: can you send a snippet of an example: we may be able to adopt it. Alberto: yes Frank: may require extension: SAZ may need more than GPBox. GG: We agreed to use to communicate PEP and PDP capabilities. We can use to communicate user attributes. Oscar: when is Joe Bester coming back from paternity leave? Frank: end of Oct.