[saml-dev] Proposed SAML defaults for interoperability event

[Ryan Eberhard <ryan.eberhard@entegrity.com>]

Title: 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.

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
- 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/

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. 

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.

Ryan Eberhard
Product Architect
Entegrity Solutions, Inc.
E-Mail: mailto:ryan.eberhard@entegrity.com
Phone: 508-624-9600, x138