Title: Proposed SAML defaults for interoperability event
-----Original Message-----
From: Ryan Eberhard
[mailto:]
Sent: Monday, April 22, 2002
1:28 PM
To:
Subject:
[saml-dev] Proposed SAML defaults for interoperability
event
Prateek, et. all,
Here is an attempt to put some values to the TBD
items in your proposed interoperability scenario for Catalyst. Please
comment and let me know if I've missed any open issues.
1. Out-of-band exchange of trusted roots for SSL
and signing certificates
If we will
support SSL and document signing for this demonstration, we need to exchange
trusted roots for SSL client and server certificates and signing keys.
We suggest that we exchange a single trust root for both SSL certificates
and signing in the form of a PKCS#12 object.
[Prateek Mishra] I
don't see a need for explicit signing of SAML assertions in this
demonstration. Server-side SSL is required to support the
"portal" SAML responder service. The remaining issue is how the
"content"-site authenticates to the portal. The choices here are (1)
password (2) client-side certificate. I would accept either but lean towards
(1).
For SSL, intermediate CA certificates and the EE
certificate are transmitted as part of the protocol; however, there appears
to be no matching procedure specified for XML dsig or SAML. Therefore
the PKCS#12 object would need to contain any intermediate CA certificates
and the signing certificate.
2. SSL Cipher suite
As per the requirement of draft-sstc-bindings-model-14 and the
recommendations of draft-sstc-sec-consider-04, each implementation that will
support SSL must implement (at least) the following cipher suite (assumes
minimum of SSL):
SSL_RSA_WITH_3DES_EDE_CBC_SHA
3. Well-known URL's for portal sites,
applications sites, source responders and destination artifact
receivers
We've identified four URL's
that need to be provided by each implementer:
- Portal URL: Main portal link -- The URL that
normally begins a user's session at the portal
- Application URL: Main application link -- linked to by other
vendor's portal sites
[Prateek Mishra] I assume this is a
URL at the "content" site? In other words,
this refers to actual content whereas Destination Artifact
Receiver URL is just that what its name says. In terms of the
Browser/artifact profile, this URL is what TARGET is set
to.
- Source Responder URL: For
call from artifact receiver
- Destination
Artifact Receiver URL: For re-direct from source intersite transfer
service
To make the demonstration as clear as possible to
our audience and to get up and running as quickly as possible, we suggest
that the four URL's from each implementer follow a common pattern. For
example, each vendor's portal site would be at DNS
"portal.<dns_suffix>", so Entegrity's portal would be at "https://portal.entegrity.com/" and
RSA's portal would be at "https://portal.rsa.com/"
So, the full suggestion is as follows:
Portal URL: https://portal.<dns_suffix>/
Application URL: https://application.<dns_suffix>/application/
Source Responder URL: https://responder.<dns_suffix>/responder/
Destination Artifact Receiver URL: https://receiver.<dns_suffix>/receiver/
[Prateek Mishra] Agreed, this is a good scheme.
Clarity in demonstration is a major goal here!
This
scheme relies on the ability of each vender to set-up default documents in
each of the four context roots that traverse to your internal URL scheme, if
appropriate. The context roots are provided so that venders are free
to have all of their services and software on anywhere from one to four
machines (by giving the various DNS names the same IP
address).
If this suggestion does not work for anyone's
implementation of their responder or artifact receiver, we can fall back to
exchanging these URL's through e-mail.
On our closed test networks, we'll most likely
achieve this by editing local "hosts" files, but the benefits of well-known
names to clarify what is going on for viewers seems required.
4. Registration of source and destination ID's
for browser/artifact profile
Source ID's
will be generated by taking the SHA-1 hash of the responder URL, as per the
recommendation in the "Artifact Format" section of
draft-sstc-bindings-model-14. Destination ID's will be generated by
taking the SHA-1 hash of the destination artifact receiver URL.
5. Signatures
We recommend that SSO Assertions be signed and the signatures be
required and verified at destination sites. Other documents, such as
Requests could be signed, but this should not be required for the
demonstration.
[Prateek Mishra] OK, so I guess you are proposing this as
an additional requirement for the demonstration. Notice that this is not
actually part of the Browser/artifact profile but an extra.
I can
see its advantages BUT at the same time I am concerned that people may
conclude that there is some deep linkage between the browser/artifact
profile and digital signing (NOT!). One design goal for the browser/artifact
profile was to avoid dependency on digital signatures. I would like to
discuss this further on the con-call with other
participants.
The cipher suite for signatures should be:
SHAwithRSA.
6. Required Attributes
We suggest having a known set of users and attributes from
each portal. If we take your users: "joe", "ravi", and "alice", and a
set of attributes that define membership level at the portal: "gold",
"silver", "bronze", we can easily create the usage flows envisioned in your
document.
Here are our suggested specifics:
AttributeName = "MemberLevel"
AttributeValue = "gold" | "silver" | "bronze"
Joe has membership level "gold".
Ravi has membership level "silver".
Alice has membership level "bronze".
Each vendor would be required to show the
following:
A. Something only Gold members
can do.
B. Something only Gold or Silver
members can do.
C. Something all members
can do.
D. Unauthenticated users are
re-directed to the portal for login.
We suggest that AttributeValues be defined
by a schema that has simpleContent and derives from string (or is string),
i.e. extra attributes only, and that the xsi:type mechanism be used.
Similarly, if the schema for AttributeName is extended, it should also be
limited to simpleContent. This way, portal sites can be guaranteed of
getting a string pair for AttributeName and
AttributeValue.
[Prateek Mishra] Works for me. We should choose a formal
namespace for the attribute names, how
about:
http://www.oasis-open.org/Catalyst2002/attributes
Ryan Eberhard
Product Architect
Entegrity
Solutions, Inc.
E-Mail: mailto:
Phone: 508-624-9600, x138
