SAML 2.0 Interop - 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
1. 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).
2. 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.
3. 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.
1. RSA provided this service last year. Doing as much of this as possible prior to dry runs is advised.
2. 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.
3. 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.

samldemoprimary message