Presence and IntComm WG

[Jamey Hicks <>]

Jill B Gemmill wrote:

> It depends on how you choose to implement.  See the H350 cookbook 
> http://lab.ac.uab.edu/vnet/cookbook/  for a full discussion-here's the 
> main point; (a) yes, you could store pwd in LDAP and authenticate 
> there directly or (b) if, as is typically the case, the proxy does not 
> have global password reading privileges,but you still want SSO, then 
> you use your enterprise password to authenticate so that you can 
> obtain your stored Videoconferencing credentials. This can be 
> transparent to the enduser and feels like SSO.
>  

Cool. 

Unfortunately, section 5.3.9 on SIP Authentication options in version 
1.0 of the cookbook is empty.  I'm so dismayed.

Section 7.1.2 on the CGI SIP client does not say what authentication 
architecture is used by this client.  It is nice that it is H.350 
compliant but it would be a more informative example for the cookbook if 
it explained how it did so.

Oh, I see, section 11.2.3 describes this.  A forward reference from 
section 7.1.2. would be helpful.

Section 11.2.10 answers my question: user agent authenticates to LDAP 
server and then fetches SIPIdentitySIPURI and SIPIdentityPassword etc 
from LDAP CommObject server  (which might be different than main 
enterprise LDAP server).

This to me seems to address provisioning more than single sign on but 
does seem like a good architecture.  Now we only have to provision the 
UA with the LDAP server and username, instead of SIP server and 
username.  What we need are standard system-wide mechanisms for finding 
directory server(s) and username for Windows, Linux, and OS X.  Getting 
this info from IE and Mozilla would probably be enough to cover nearly 
all users.  I think it would be a good thing to add to the cookbook.

Relating H.350 to my experience with HP, I am able to run an LDAP server 
but I have no way to add the references to it in the main server until 
we're ready to do a production deployment.  However, I can layer this 
pilot LDAP server over the enterprise server so that the message flow 
would be the same as Figure 20 in Section 11.2.3.

Jamey