[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Credentials Collector proposal for SAML 2.0...
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]