I have reorganized and appended my notes on our Monday meeting. I believe that having this conversation was very useful. At the end of the meeting, we both felt that we should meet again in the month time-scale to have a more focused discussion on specific topics. These are some of the topics open for discussion: - Globus is investigating the use of XACML assertions for PEP/PDP communication: we would like to be involved in the discussion. Currently, the Privilege project uses SAML + XACML obligations as implemented by the PRIMA library. Our medium/long-term goal would be abandoning PRIMA for the common XACML / GT protocol. - CAS seems to implement a model generic enough to be used as a VOMS or a GUMS server. We did not have time to go in the details of what concepts in CAS map to the privilege concepts (roles, identity mappings, etc.), even if we started the discussion. It would be interesting doing this exercise together, in order to uncover potential use cases / features that are not implemented by the CAS model. CAS could be an alternative solution to GUMS, in the long-term. - We need to define the OSG roadmap and priorities for Globus. This can be done through bugzilla submitting tickets as OSG. The type of discussions that we had on Monday seem a good way of exposing commonalities, wish lists, requirements. - Globus would be interested in talking about Auditing. Probably Philippe Canal would be the best contact for this. Cheers Gabriele ----------------- Notes on the meeting between the Privilege Project and the Globus Toolkit Mon Oct 23, 2006. Agenda and material: http://cd-docdb.fnal.gov/cgi-bin/DisplayMeeting?conferenceid=239 Present: Rachana Ananthakrishnan, Lisa Childers, Gabriele Garzoglio, John Weigand, Tanya Levshina, Vikram Andem, Igor Sfiligoi, Eileen Berman, Keith Chadwick, Ted Hesselroth ------------ GLOBUS Overview - Rachana Ananthakrishnan works with Frank Siebenlist - The toolkit provides client-side libraries to talk to authorization services - Globus is looking into a Kerberos plug in for authorization - GT separates validation of DN from validation of attributes. There is one call out to validate DN and another call out to check validity of attributes. Then the DN and attributes can be used on authorization decisions. - XKMS protocol to do validation - Need to define OSG roadmap and priorities for Globus. This can be done at bugzilla submitting tickets as OSG. - proxy can be delegated as impersonation proxy (all attributes are inherited) or independent proxy (someone created my proxy, but I have nothing to do with it for resource access). This should be RFT3820 - Globus uses the XACML model -- PIP (Policy Information Point) e.g. parameter PIP (soap message passes a parameter e.g. args in the put resource properties soap interface: a PIP can extract the parameter in memory so that later can be used by a PDP ) -- PDP (Policy Decision Point) can say Permit, deny, not applicable, undetermined (?). In the future, Globus wants to enhance PDP call back with XACML obligations. - Globus Overview; slide 14: PIP and PDP are classes instantiated in the memory of the host. The PDP can get attribute info from the message context (local thread memory at the host) and do a call out to external services (e.g. GUMS). The local caching can be done implementing a PDP (Vikram is looking into this to fix caching problems of PRIMA GT4). SAZ call out can be another PDP. - GT 4.0 limitations: you have to use deny / permit / ... (no obligations) AND there is not a std way of storing attibutes. In GT 4.2, attributes can be stored in XACML (slide 15), so the framework can reuse them and implement functionalities for you. Today each PDP can get different attributes, but they have no way of exchanging this info because they are not stored in a std way. - Attribute are characterized in 3 types using XACML: subject bag (attributes about the subject), action bag (parameter used for that operation), resource bag (parameters on the state of the resource e.g. job state). There is an additional "empty bag" (attributes about everything else or the context). Attribute merging takes place in the empty bag. In the Privilege model, PDP are owned by the same person that owns the resource. The XACML model can describe an admin that gives access rights on a resource owned by another entity. The decision includes who took the decision: for this model, one needs attributes about other entities. This model is useful for cross-domain trust. For example, teragrid needs to trust the OSG VOMS for a VO. - Future Globus roadmap -- Caching at the level of the framework -- Call back of PDP to PIP (on demand attributes propagation) - VOMS roles could be modeled as XACML Environment attributes: we'd need to investigate this more. ------------ VOMRS - Purse: incubator GT project. Step before VOMRS. Download certificate from Purse. Does not interface to VOMS or any other service. - It would be interesting investigating a possible collaboration between VOMRS and Globus to manage VO information in CAS. ------------ GUMS - we do mapping on DN + attributes + hosts: we need at least this for something that can possibly replace GUMS. - It would be useful to understand in detail how CAS could be used to replace GUMS. ------------ PRIMA - Globus has a plan to implement an XACML-based PDP - Globus will involve Privilege when discussing the how to format the XACML queries for an XACML PDP. ------------- Fermigrid - Wishlist: Unique ID across log files, common time stamps format - Discussed Auditing and Accounting: Philippe Canal is the right contact person. -------------- gPlazma - In principle one could use an extension to GUMS to handle storage attributes. -------------- gLite Security Model - Preserving the order of fqan is important (e.g. primary vs secondary GIDs): the attributes from the PIP should be returned as lists, rather than sets.