SAML 2.0 Interop - Thoughts on Technical WOrk in Support of InterOp Lab

Title: Message

FYI

 

 -----Original Message-----
From: Meehan, Brad 
Sent: Wednesday, December 22, 2004 6:17 
PM
Subject: Thoughts on 
technical work in support of Interop Lab

 

Below are some thoughts from Rob 
Philpott regarding the work and specific tasks involved in putting together the 
Interop lab.

 

Regards,

Brad

 

 

Here’s some groupings of tasks that 
had to be accomplished for last year’s SAML interop.  The groupings could 
be used to divide up the work, assigning a DRI (“designated responsible 
individual”) for each group. 

 

  
Demo 
  hardware/network 
  
    
Sun provided flat-panel LCD 
    monitors.  This was greatly appreciated as our cost to do it would be 
    quite large.  But we need to make sure the correct VGA cables and power 
    cords are available (in 2002, we had to scramble to find cables/power cords 
    since some of the monitors shipped without them). 
    
The interop machines were all 
    assigned static private-domain IP addresses and we all used etc/hosts files, 
    so someone needs to create/distribute/manage that file.  Last year’s 
    address assignments were listed in the previously distributed 2004 interop 
    document/report. Vendors were limited to 2 machines for the demo.  
    Other machines were permitted in the booth during testing, but for the demo, 
    we wanted all machines hidden under the tables. 
    
Make sure cabling requirements 
    are known.  We used a separate hub/router for the private 
    network. 

  
Coordinate with RSA Conference 
  staff re: technical logistics: 

  
    
Power requirements – need to 
    account for all systems, monitors, etc. 
    
Demo network – Make sure network 
    cables/router boxes were installed. 
    
Internet connectivity – Last 
    year, I believe they comp’ed us a couple of IP addresses for the booth (NO 
    firewall was provided).  It’s fairly expensive to go beyond this (i.e. 
    $125 per address). So last year we had used a comp’ed one and placed a 
    Linksys NAT router box on it with one drop running to each table (i.e. 2 
    vendors took turns sharing the line as needed). All systems connected here 
    needed to be DHCP clients.  Note that the interop machines were not 
    attached to the NAT router boxes. 
    
Ensure that table configuration 
    was workable.  Last year, when the pipe/drapes were up, we pushed the 
    tables to the edge of the 200x20 booth and everyone worked inside (it was 
    cozy, but manageable).  When the drapes came down, we demoed from the 
    outside,, so the tables had to be moved in to keep us in the 20x20 
    space.  Moving the tables has to be taken into account when running 
    power/network cables. 

  
Coordinate with RSA Conference 
  staff re: miscellaneous logistics: 

  
    
Last year, we got an extension 
    to the late registration that provided demo participants to get the 
    discounted conference fee.  This is a really nice thing to do for folks 
    given the effort they put in to make this a successful event. 
    
We need approval from the 
    conference folks to work late in the booth in the evenings even when the 
    show floor is closed to normal exhibitors. 
    
Publicize when the booth will be 
    available for start of testing. 
    
A couple of whiteboards on 
    easels were purchased and came in very handy during our interop 
    testing. 
    
Need to get exhibitor badges for 
    anyone needing access to the booth, especially when the main show floor is 
    not open.  This includes folks that will be doing demo “booth duty” if 
    these are different from the developers doing interop testing. 

    
Scheduling installation/teardown 
    of pipe/drape for the booth. 
    
Shipping info – where do vendors 
    ship h/w, literature, etc? 
    
A lockable box for storing demo 
    laptop’s overnight came in handy. 

  
Coordinate with the interop demo 
  marketing team: 

  
    
To avoid having too many vendor 
    reps present during the public demo, a schedule was put together that 
    resulted in only 1-2 folks being at each table at any time.  This was 
    workable since the purpose of the demo was to show SAML interoperability, 
    NOT the snazzy features of each individual vendor’s products (although there 
    was some of this which was unavoidable).  Folks were expected to stick 
    to the script. 
    
We had consistent vendor name 
    placards at each station.  Vendors weren’t allowed to bring their own 
    signage. 
    
We had planned to produce a 
    single poster for display that showed very high-level SAML flows that could 
    be referred to for a simple explanation of the demo scenario.  
    Unfortunately, by the time we got one put together, we had trouble getting 
    it printed and sent off to a Kino’s for producing the poster.  Doing 
    this in advance would be advised. 

  
Certificate 
  Authority 

  
    
Need a privately-managed CA to 
    issue, at a minimum, SSL server certs and Digital Signing certs.  
    
    
      
RSA provided this service last 
      year.  Doing as much of this as possible prior to dry runs is 
      advised. 
      
Last year we attempted to 
      support mutual SSL authentication on the SOAP channels, but had SSL 
      implementation interoperability issues, so we dropped it during 
      testing.  If we decide to try that again, we also need to issue SSL 
      client certs.  
      
I think it may be unlikely 
      that we will use encrypted SAML name identifiers, attributes or 
      assertions, so the certs probably won’t need to support 
      encryption. 

    
So we need a volunteer to set 
    up/manage the CA and issue certs for everyone.  We did this via email 
    last time, although the CA was also available at the show for any last 
    minute emergencies. 

  
Dry run coordination 
  

  
    
Last year, we did internet-based 
    dry run testing.  Because of the extent of the changes made between 
    SAML 1.1 and 2.0, limiting our testing to internet-based dry runs is, IMO, 
    very risky.  A f2f-based dry run is highly advised for anyone that did 
    not attend the Liberty-sponsored December interop.  Even if they did 
    attend that one, it would be helpful for reducing risk if they attended a 
    f2f one for this event. 

  
Miscellaneous technical 
  stuff: 

  
    
We need to agree on which 
    version of the SAML V2 spec’s are being used as the authoritative definition 
    for the interop. 
    
Prior to demos and/or dry runs, 
    it would be extremely useful if someone could distribute captures of real 
    protocol exchange for those things we agree to demo. 
    
Last year, use of GSA’s portal 
    required registering for application id’s, etc.  Will this still be 
    required?  If so, it was helpful to have this available over the 
    internet prior to the conference.