Some
weeks ago, I stated that we should consider any scenario which was sufficiently
well defined and suggested that people make an alternative proposal ASAP. There
have been no takers.
Keep
in mind the goal of this demonstration is interoperability. Based on the
concall, it appears that the majority are committed to implementing
Browser/artifact and nothing else. Krishna was interesting in sending and
receiving assertions, perhaps you could come to some mutual agreement with
him.
We
(and perhaps others) will be implementing the three SOAP binding responders,
based on our repository and policy engine. If you want to build an app that
operates by making requests to these, we will work with you.
If you
want to create a SOAP transaction scenario based on the draft SOAP Profile or
made up out of whole cloth, I suggest you make a very specific proposal right
away and see if others are willing to interoperate with it.
Hal
-----Original Message-----
From: Anne Thomas Manes
[mailto:]
Sent: Friday, May 03, 2002 10:56
AM
To: Philpott, Robert; 'Don Bowen';
Subject: RE: [saml-dev] Questions
about dry run
Have
we determined that we will in fact only use browser
artifacts?
If
so, I think we're really limiting the scope of the demo.
Anne
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: Friday, May 03, 2002 8:36
AM
To: 'Don Bowen';
Subject: RE: [saml-dev] Questions
about dry run
Hey guys - Here's a
more detailed proposal on the network configuration.
First - re: network
addresses. I'm assuming we will NOT be using DHCP.
It tends to play
havoc with some server software/frameworks.
If we want
multiple names for the same system, it doesn't work well. The reason this
is important should be clear by the end of this message.
The down side is
that everyone must configure the network on their systems with fixed IP
addresses. I'm going with the 192.168.x.y proposal from
Don.
First, "x" depends
on the alphabetically sorted company name:
X - company
name
1 -
baltimore
2 -
crosslogix
3 -
entegrity
4 -
netegrity
5 -
novell
6 -
oblix
7 -
quadrasis
8 -
rsa
9 -
sigaba
10 -
sun
11 -
systinet
12 -
Tivoli
13 -
verisign
Using Prateek's
suggested system naming I now recommend setting "y" as
follows:
Y - demo
function
1 -
portal
2 -
application
3 -
receiver
4 -
responder
So, for example,
the RSA portal system can be found at IP address
192.168.8.1
At a minimum, each
company will have 4 entries. This assumes that the system names are
actually set to "portal", "application", etc. If the systems where
these demo functions are hosted really have different system names than
those used above, then we just need to add additional entries for those
addresses. For example:
192.168.8.1
portal.rsa.com
# RSA
portal host
192.168.8.1
philpott-lap.rsa.com # actual
system name where the portal runs
192.168.8.2
application.rsa.com # RSA content
provider host
192.168.8.2
ct009.rsa.com
# actual system name where the application resides
192.168.8.3
receiver.rsa.com
# RSA artifact receiver host
192.168.8.3
ct009.rsa.com
# the artifact receiver is also the content provider host
192.168.8.4
responder.rsa.com # RSA SAML
SOAP binding responder host
192.168.8.4
philpott-lap.rsa.com # the SAML
responder is also on the portal system
I will put together
a complete etc/host file using the default settings above. If folks
want additional entries for the specific IP addresses, you'll need to send
me the IP addresses and machine names that you'll be using. Please use
the format:
192.168.x.y
machine.company.com # any comment you want
The next issue is
whether to use a DNS server or individual etc/host files.
There are pro's and
con's to using an etc/host file. Pro's - easy to modify, no DNS system
to manage, individual systems don't have to have their network config
changed to account for the DNS server. Con's - easy to get out of
synch, changing the file means updating it on all systems (and we'll have a
lot of systems).
My preference would
be to use a DNS server. I've asked our comm/IT group to set one up for
me on a laptop so it will be easy to take out to the show in SF. It
looks promising, but if they decide they can't do it for me, I'll either
need another company to step up to the plate and bring one properly
configured, or we'll have to go with etc/host files. I'll let you know
when I hear definitively from them. The advantage of the DNS server is
that there's just one place to update and all systems can take advantage of
it.
Does all of this
make sense to folks?
Rob
Philpott
RSA
Security Inc.
The
Most Trusted Name in e-Security
Tel:
781-515-7115
Mobile:
617-510-0893
Fax:
781-515-7020
mailto:
-----Original
Message-----
From: Don
Bowen [mailto:]
Sent: Friday, May 03, 2002 1:05
PM
To:
Subject: [saml-dev] Questions about dry
run
I have a few questions about the dry run, which I
need to secure the right facilities at Sun. My apologies that this has not
been confirmed yet, but being out of the country and trying to
coordinate it make things difficult.
Robert
Philpott has already asked several questions, but I still haven't seen any
replies. PLEASE review these
questions, which I have inserted below in
case you no longer have it:
Hey folks - I'm lining up
network access for the dry run. I've asked them to allow http, ftp, email,
and VPN
protocols
through the firewall. Anything else?
Other network
questions:
1.Do we want a DHCP
server set up for the local network?
2.What about a DNS server? I
would think it would be easiest to just configure an etc/hosts file that we
all
share, but I thought
I'd ask. I'm not sure I'll have time to configure a system for this
here, so I would probably need
someone else to step up to the plate.
3.Regardless of whether
we want DHCP, I assume a bunch of the boxes will need static
addresses. We should
agree on ranges of address for each company to
use. Someone want to propose something?
I did
propose something for address ranges, but have seen no reply to that either.
Here is that proposal again for your
comment:
What about a netmask of
255.255.255.0 and 192.168.x.y where:
x would range from 1-N (N being number of
participants, assigned in alphabetical order)
y would be 1-M (M being the number of machines a
participant needed)
Additional information that I need includes:
- How
many people from each company are planning to attend?
- How many
machines will each of you bring with?
- What would you expect to be
provided?
I'm not
trying to be pushy at all, but without input from all participants on these
questions and issues we can't make the
necessary progress. If someone
wanted to volunteer to create a network diagram that shows all participants,
their
machines and any other equipment that would be great.
I will
be putting together an agenda sometime today or over the weekend for the
call this next Tuesday. Feel free to
send input. I'm leaving Munich for
Paris at noon and just can't do it any sooner.
Don;
