AA Planning Call - 06-02-2007

From GEANT2-JRA1 Wiki

Contents 1 Dial In Info 2 Participant List 3 Agenda 4 Minutes

Dial In Info

This call will take place via skype. The participants in the list below will be called on skype conferencing. If you are interested in joining the call, please inform Loukik or Maurizio or Jeff or Candido

Time: 1500 hrs UTC

Participant List

Loukik, Maurizio, Candido, Jeff

Agenda

1. As an Introduction, discuss some sequence diagrams illustrating the various things that need to be done
   1. Candido - general explanation
   2. Loukik & Jeff - how does it map with our current service - which components might get involved, new components, pS-base, etc
2. Things to do from perfSONAR 'Resource' or 'Service' point of view
   1. TLS & SAML Assertions
      1. what is it, why do we need it, how do we make use of it (in Tomcat/Application Servers)?
      2. Which one will be end up using? Are we going to use both? Maybe a discussion comparing the benefits of both?
   2. Checking & Reading X.509 Certificates
      1. What libraries are available?
      2. What can be read from these certificates?
   3. Converting X.509 certificate (or the contents of the certificate) into other formats
      1. Why do we need this?
      2. Whats available?
   4. Adding or modifying SOAP libraries
      1. Why do we need it?
      2. What packages are available for doing this?
      3. How and what do we do?
   5. XACML
      1. What is it? Why and how do we use it?

Minutes

1. Candido - General Explanation
   1. All perfSONAR Resources will need to accept two types of messages - X.509 over TLS and SAML Assertions.
   2. Tomcat supports setting up TLS connections. Tomcat also has libraries which will allow applications to read X.509 certificates
   3. Action: Candido to email his experiences with making use of tomcat libraries to read X.509 certificates (sample implementations if available)
   4. openSSL could be used by perl implementations for reading X.509 certificates.
   5. Candido mentioned that TLS and SSL are the same
   6. To work with SAML Assertions, openSAML could be used. The question is where will these SAML assertions be contained within the SOAP message. Two possibilities exist (at least two). Possibility (1) is to have it in the SOAP header. To do this, some kind of SOAP reading and modifying libraries are needed. Possibility (2) is to have them in the SOAP body. Loukik mentioned that in order to have it inside the SOAP body, we will have to put it within the NMWG message (i.e., inside <nmwg:message> </nmwg:message>). This is because perfSONAR makes use of document/literal standards which requires an xml document inside the SOAP body. Candido mentioned that it might be easier to have it inside the message. Loukik mentioned that NMWG guys will need to be involved to analyze this more. All agree that there might be more reasons for having the assertion in the SOAP header or elsewhere. All agree to wait for Jeff's comments on this topic in the next phone call. ACTION: Candido to send an example of a SAML assertion.
   7. LK asked "Are there libraries available which will help the resource in identifying whether the client is using X.509 or SAML?"
      1. Candido didn't seem to be sure if there were libraries. He mentioned that this might be part of a method within the programs written by us
2. Loukik - Other questions from perfSONAR resource point of view
   1. Loukik was wondering if there will in total be two message sequences to achieve generation Authorization (usually understood as Authentication) and Authorization in relation to a specific dataset (i.e. is this user allowed to see this data that he/she is asking for). Loukik thought that all this would happen in two different messages. In the first message, the service will take the certificate or the assertion and try to get it verified (for integrity, validity,etc). If valid, the service will then try to make a second request asking if the client/user is allowed to see the data (or make a measurement, etc) that he or she is requesting.
   2. Maurizio mentioned to Loukik's above question that this two-message approach would complicate things and its better to achieve it in one message only.
   3. Loukik then mentioned that two phase prototyping approach could be taken. In phase 1, the resource/service will send only the certificate or assertion and try to seek its validity. In phase 2, the resource/service will send both the certificate/assertion and a summary of the request being made. This two-phased approach is advantageous because he expects the second part to take more time due to discussions on how to summarize requests (which will be required to help the authorization component to make decisions). Further discussion might be necessary on this topic. ACTION: Loukik to describe his idea of phases
3. Candido's current work
   1. Candido is implementing classes (for perfSONAR) which will allow creation of SecurityToken objects, AuthZRequest classes, AADispatcher classes (refer to flow chart shown in his email to perfsonar-dev list). (Loukik was quite surprised by this because he was probably sleeping which all this was discussed earlier and hence everything was new to him ;) ).
   2. Candido mentioned that he is aware of perfSONAR structure to a certain extent. Loukik mentioned that this work will need to be more integrated within perfSONAR classes. ACTION: Candido to email some class diagrams for all the classes that he has designed/planning to implement.
   3. Next call: Idea is to have weekly phone calls - Next call Tuesday 13th Feb, 1500 hrs UTC