Mapping User/Password to SASL Exchanges

[Henry B. Hotz]

On Jun 22, 2010, at 5:57 PM, Howard Chu wrote:

> Henry B. Hotz wrote:
>> 
>> On Jun 22, 2010, at 2:53 PM, Henry B. Hotz wrote:
>> 
>>> Suppose I have a defined Java API which specifies arguments Username and Password for opening a new session. The implementation and protocol is officially unspecified, so we can do whatever we want with those arguments.
>>> 
>>> How can/should I map between those arguments and SASL if I want to implement the real connection using SASL? Is there any "prior art" like this?

I didn't exactly get an answer to these questions, did I?  I suspect what OpenLDAP does isn't *directly* applicable, but I'd be interested in any thoughts you have.

>>> I'm thinking that the username should map to either the authentication ID, and the "password"
>> 
>> Should say: "username should map to the authorization ID".
> 
> Pretty sure you were right the first time. In the default case when an app 
> only provides a single username, it *must* be the authC ID. You can't do any 
> authC check without it, while the authZ ID is always optional.

I'm assuming that the credential (used in place of an ordinary password) contains the authC ID, leaving the authZ ID unknown.  Therefore the authZ ID needs to be provided.  

There are a bunch of questionable assumptions that go into my logic.  For example, I'm assuming that a general purpose, unique mapping between authC and authZ IDs isn't possible.  I'm assuming that the mapping needs to be unique.

>>> could be either some kind of description like MECH:[credential location] or an actual binary blob, or maybe empty (in favor of some system properties). If someone else has defined a translation like this in a generic way, I'd like to go with that.
>>> 
>>> If it matters, the actual example is a JMS implementation.
> 
> If you aren't able to do an interactive conversation to get more info, that 
> limits your selection of mechs. Putting a mech prefix in there is interesting; 
> who selects it? Not the user I would assume.


I'm assuming the programmer, because he knows the deployment will use e.g. Kerberos authC identities.  (Another one of my questionable assumptions.)  There's an implied question there as to whether that specification should be in the "password" at all.

I think it's reasonable to assume we specialize the open method to support multiple round trips.  (I may be wrong for other JMS vendors.)  The question is how do we propose to create actual secure connections, given a defined API which says you provide a username and a "password".  That calls for some serious conceptual remapping.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu