RE: [saml-dev] Proposed SAML defaults for interoperability event

[Hal Lockhart <hal.lockhart@entegrity.com>]

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:pmishra@netegrity.com]
Sent: Tuesday, April 23, 2002 10:52 AM
To: 'Ryan Eberhard'; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] Proposed SAML defaults for interoperability event

 

-----Original Message-----
From: Ryan Eberhard [mailto:ryan.eberhard@entegrity.com]
Sent: Monday, April 22, 2002 1:28 PM
To: saml-dev@lists.oasis-open.org
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:ryan.eberhard@entegrity.com
Phone: 508-624-9600, x138