MW-E2ED Conference Call
August 1, 2007
 
**Attending**
Chas DiFatta, Carnegie Mellon University (chair)
Mark Poepping, Carnegie Mellon University
Paul Hill, MIT
Michael Gettes, Internet2
Steve Olshansky, Internet2
Dean Woodbeck, Internet2 (scribe)
 
**Action Items**
 
[AI] {Chas} will call Matt Zekauskas to discuss suggestions for EDDY use cases on a future MW-E2ED call.
 
[AI]{Paul} will provide information on the location of Shib logs and the format of the logs on MIT’s web auth and IdP servers. He will provide a URL for the run book for the servers.
 
[AI]{Michael} will provide the information on the location of Shib logs and the format of the logs and serve as the Service Provider (SP) test case.
 
[AI]{Chas and Mark} will create a Perl shim that integrates the Shib log data into the EDDY CER factory.
 
[AI]{Chas and Mark} Within three weeks, the EDDY team will then create a simple CER and a simple storage agent, as well as a simple web user interface to access/search the data.
 
**Suggestions for Use Cases**
 
This discussion was deferred until Matt Zekauskas from Internet2 can join the call. [AI] {Chas} will phone him.
 
**EDDY and Shibboleth**
 
Most of the call involved a discussion of the potential for EDDY and Shibboleth to work together. One suggestion was that, long-term, the EDDY team explore what it would take to be included with the distribution of Shibboleth and Signet and Grouper.
 
In the short-term, developing a use-case for using Shib and EDDY together would be helpful. One such use-case would involve capturing log data from a Shib installation and moving it into EDDY.
 
For example, if an institution has an application with access controlled by Shib, and users are receiving error messages when trying to access the application, could the relevant Shib logs be moved into EDDY to help define and diagnose the problem?
 
One concept would be to take Shib logs from IdPs and SPs and get them into an EDDY CER, then allow people federated access to those logs. The key benefit to using EDDY is the ability to generate reports and graphs that demonstrate any problem areas, without disclosing any of the underlying data.
 
Paul mentioned that such a use-case could be valuable to MIT and the university’s project to use Shib for access to four major web applications. The MIT development group is about to hand over control of the IdP and web-auth servers to the operations group. During the pilot phase, however, the developers will provide the first tier for support. They will not have direct access to the servers but will need access to the log data. Such data will allow the development of metrics – such as the number of users trying to authenticate to an application but fail.
 
There was a suggestion to approach the Shib developers and/or Internet2 to use the TestShib environment for this. After further discussion, it was decided that using real data would be more advantageous.
 
[AI]{Paul} will provide information on the location of Shib logs and the format of the logs and serve as the test data for an Identity Provider. He will provide a URL for the run book for the web auth and IdP servers.
 
[AI]{Michael} will provide the same information from his server and serve as the Service Provider test case.
 
In general the working group believes that these tests should help take some of the load off of the Shib development team by managing the log data via EDDY. At some point, EDDY could automate some of this process by issuing messages when it sees known problem areas. In developing this aspect of EDDY, Chas said it is important to know the type of problems that people are trying to solve. Working backward, then, that tells the EDDY developers the types of analytics needed and the types of events to look for.
 
In relationship to the Shib use-case, it would be helpful to develop a list of questions that need to be answered. For example, a user from MIT can’t connect to a resource at Duke, for which that user should have access. The user (and the system administrator) will want to know why that person can’t connect. Paul suggested looking at the Shib user email list archives to get a feel for the types of problems that people are having and, by following the email thread, how those problems are being solved.
 
[AI]{Chas and Mark} The EDDY team agreed to create a Perl shim that integrates the Shib log data into the EDDY CER factory. The CER will include the log time stamp, host name, log file name and a single line of log data.
 
[AI]{Chas and Mark} The EDDY team will then create a simple CER and a simple storage agent, as well as a simple web user interface to access/search the data. This will need to happen within three weeks, so the Perl script for MIT is ready before Paul turns control of the servers over to the operations group.
 
Once the Shib data is successfully imported into EDDY, a next step will be developing policies and procedures for access.
 
**Next Call – To Be Determined via Email**