RE: [security-services] Credentials Collector proposal for SAML 2.0...

["Jahan Moreh" <jmoreh@sigaba.com>]

Hal -
In reading Carlisle's proposal and your original paper, it seems to me that
Carlisle's "CC as a Translator" is analogous to your "Pass-through" method.
The caveat being that the Translator CC explicitly translates credentials
before forwarding it to the AA. In your paper you argue that a weakness of
the Pass-through method is "In the typical case, where the CC is imbedded in
a Web server filter, the web server would not able to access any of the
application data.".

I would argue that the a Web server filter that requires access to
application data is acting as a relying party. That is, I imagine a Web
server filter to act as both CC and a Relying Party. However, these roles
are distinct. I.e., the Web server should know when it is acting as a CC and
when it is acting as a RP. The bottom line is this: once the authentication
process is done, the SE is in possession of an assertion which is then
presented to the RP and the application session ensues from there. In this
context, the Web server (acting as a relying party) can set up its own
secure session with the SE and have access to the application data.

If my argument holds water, then I think Carlisle's "CC as a Translator" is
a very good initial step because fundamentally it allows SEs to remain
unchanged.

Thanks,
Jahan


----------------
Jahan Moreh
Chief Security Architect
310.286.3070
-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Tuesday, April 01, 2003 6:53 AM
To: Carlisle Adams; security-services@lists.oasis-open.org
Subject: RE: [security-services] Credentials Collector proposal for SAML
2.0...


Carlisle,

This doesn't seem to have attracted much discussion.

I agree that architecture "CC as Translator" is what most people want.
("Combined CC and AA" is what SAML supports today, e.g. Browser/artifact
Profile and "CC as Local Authenticator" has always seemed dubious to me as a
candidate for standardization, since the trust required of the CC by the AA
suggests that they will be part of the same security domain.)

Your paper addresses in more detail issues I only alluded to in my original
paper.

However, the fundamental question remains. How can this architecture be
realized (with or without WS-Trust) without either a) favoring weak
(password) authentication over strong (cryptographic) authentication or b)
causing the architecture (and therefore the trust relationships) to change
completely from one authentication to the next, depending on the type of
mechanism chosen.

The problem is not so much the authentication itself, but the state that
must be carried forward into the session begun with a cryptographic
handshake.

Given purely technical considerations, I would favor the Shared Sesion Key
scheme I outlined in my orginal paper. I would even be willing to work with
you to flesh out the details. However, the practical reality is that most
implementations use SSL, for example, as a blackbox and have no convenient
means for exporting and importing session keys, not to mention doing only
half of the protocol.

Those who do not understand the last three paragraphs should refer to my
paper at:

http://lists.oasis-open.org/archives/security-services/200206/msg00007.html

Hal
-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Tuesday, March 11, 2003 2:16 PM
To: 'security-services@lists.oasis-open.org'
Subject: [security-services] Credentials Collector proposal for SAML 2.0...


Hi all,
I've finally gotten around to updating and filling out the Credentials
Collector proposal.  I've tried to take into account the brief discussions a
few of us have had so far on this topic.  Further comment/discussion is
welcome, on the list and perhaps in an upcoming concall.
Carlisle.
<<SAML Credentials Collector.doc>>