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

[Carlisle Adams <carlisle.adams@entrust.com>]

Hi Maryann,

Responses are embedded below, prefixed with "[Carlisle]".

Carlisle.


-----Original Message-----
From: Maryann Hondo [mailto:mhondo@us.ibm.com]
Sent: Monday, March 31, 2003 5:53 PM
To: Carlisle Adams
Cc: 'security-services@lists.oasis-open.org'
Subject: Re: [security-services] Credentials Collector proposal for SAML
2.0...

Carlisle,
sorry it took me so long to get these to you.

Section 2 is labelled a "system" model but it seems to me to identify a
logical model....the CC could be part of the client,
part of the AA or an entity on its own.

[Carlisle]  Fair enough, although the text is pretty clear about the fact
that this describes three conceptual architectures.


In section 2.1 you say the SE sends credentials to the SE/AA and the CC/AA
issues a "new" SAML assertion....can you supply
a SAML assertion as a credential and how would this be authenticated using
a challenge/response?

[Carlisle]  Yes, it is possible to supply a SAML assertion (although I doubt
that this will be the common case).  If the assertion contains a
SubjectConfirmation of HolderOfKey, for example, then this can be used to
authenticate the subject in a challenge/response exchange.


In section 2.2 you say the "CC plays the role of a translator" but I don't
quite understand the difference between being a
collector and a translator....it seems different to me.  How does an AA
authenticate credentials of an SE with a CC in the middle?
Is this a session where the CC maintains two connections? one with the SE
and one with the AA? and mediates the interaction
since the reason you have a cc is to off-load auth support from an AA.

[Carlisle]  Yes, the CC maintains two connections, one with the SE and one
with the AA.  It translates messages and/or credentials from one syntax to
another.  The AA can authenticate credentials in the same way that it would
without the CC (e.g., it sends a challenge and expects a valid response, or
it checks the supplied password against the value it has stored privately).
The CC being in the middle does not prevent (or even substantially
complicate) the AA's authentication process.  Note that in this model, the
purpose of the CC is not to off-load auth support from an AA; rather, it is
to allow the AA to use only standardized message and credential formats.


In section 2.3
      my question is how do you discriminate between CC functions/behavior
and AA functions/behavior?
      what do you mean that the "cc is not known to a wider community"?

[Carlisle]  The dividing line between the CC functions/behaviour and the AA
functions/behaviour is simple:  the CC does the authentication and the AA
creates the assertions.  Relying parties in the rest of the world know and
trust (or are able to know and trust) the AA, but have never heard of the CC
and have no way of trusting it.  This is exactly the PKI model that is
common in many environments:  there is a Registration Authority (RA) that
does authentication locally and a Certification Authority (CA) that creates
certificates that can be trusted by relying parties beyond the local domain.


      also, do you think that SE's can really trust the CC without knowing
which AA or under what conditions the
      CC and the AA exchange data?  what about privacy ?
      would the SE be aware of which of the two roles the CC was playing?

[Carlisle]  SEs can operate in this way, but don't have to if they don't
wish to.  After all, the whole premise of this model is that the CC is local
to the SE (e.g., within the same organization), so it is much easier for SEs
to find out what the CC does and decide whether or not to trust it.


In section 2.4.2
      Is the type2  a way to supply more than one credential to produce a
single saml assertion that reflects
      all the credentials? could you give me an example of this?

[Carlisle]  TYPE 2 messages could carry multiple credentials, but may only
carry one.  The single SAML assertion that is created need not reflect all
the credentials.  The purpose of the assertion is to hold an authentication
statement that will be useful to some relying party community.  So, for
example, it might contain a name form for the SE that is different from one
or more of the name forms contained in the various credentials that were
supplied.


      Why wouldn't the combined CC and AA also accept type 2? can an SE
collect their own "sets" and make a single request to an AA?

[Carlisle]  TYPE 2 messages are non-standard (with respect to SAML).  If the
CC and AA are combined and they accept TYPE 2 messages, then there is
nothing for SAML to do -- this is essentially the current situation.


      Why is type 3 needed? isn't what the user gets really an
authorization request? rather than an authentication?
      Is it anticipated that this would be something like Maryann was
authenticated by IBM but CompanyXYZ  is accepting liability for
      the authentication based on the assumption that IBM did the right
thing?

[Carlisle]  TYPE 3 is still an authentication request, a request for a SAML
assertion containing an authentication statement.  In this model, the AA
trusts the CC to do the entire authentication step, so that no credentials
are sent to the AA.  The liability scenario you describe could be a valid
use case for this model, if CompanyXYZ acts as the AA.  However, in
practice, I don't know if AAs will typically accept liability in this way.


Hope this helps!

Carlisle.