From: Meehan, Brad
Sent: Wednesday, December 22, 2004 6:17
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
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.
- 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
- 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
- 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
- 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
- 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
- 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.
- 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
- 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
- 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
- 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
- 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
- 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.