Title: Proposed SAML defaults for interoperability event
Not
signing Assertions is fine with us and removes major complications. We proposed
it only because we thought people would expect assertions to be signed and that
use of XML dsig would be expected.
What
do others think?
As far
as the SOAP binding goes, we would prefer mutual authentication (client
certificates) It is more secure and actually easier to implement. (no need to
manage passwords, do basic auth header, etc.) Since we propose to exchange trust
roots anyway, you can use the same key/certificate for both client and server
ends.
Hal
-----Original Message-----
From: Mishra, Prateek
[mailto:]
Sent: Tuesday, April 23, 2002 10:52
AM
To: 'Ryan Eberhard';
Subject: RE: [saml-dev] 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
