On Mon, 2009-12-21 at 13:26 -0500, Carolyn Beeton wrote: > So far our basic idea for where to associate peers using TLS with an > internal user id so that permissions can be applied to calls going > through sipXecs has been to add it in the ITSP configuration somewhere > (see some of the comments in > http://track.sipfoundry.org/browse/XX-6398). Although this would work > for calls coming through sipXbridge, it doesn't help with calls which > arrive at sipXproxy. So I thought a more general design would look > like this: > > new Trusted Peers menu item (maybe under Users?)
Perhaps "Peer TLS Identities"? > contains list of trusted peers (FQDN/IPaddr), with Add Trusted Peer > button The UI structure sounds good. My impression is that the "trust" is based on the identity domain name in the presented certificate of the TLS connection, so the list of "trusted peers" is really a list of certificate "subject names". I'm not sure that I have the terminology right there. I think the official term is "subject name" or "subjectAltName", but I expect that users will say "certificate SIP domain name". (Also, are we willing to base trust on the subject name of a certificate, or only on the SIP subjectAltName?) In any case, we need to make it clear that it is the SIP domain in the certificate that determines the identity, not the origin of the connection. > clicking on any trusted peer goes to Permissions page for the internal > user for that trusted peer, with the internal user appropriately > hidden from the user (maybe). I don't see a need to hide the peer identity (user-part); we just need to make sure that users don't have to construct them themselves. > clicking Apply or OK creates (if necessary) a new special internal > user id for that trusted peer (~~pi~<domain>) with the configured > permissions, and replicates the peeridentities.xml mapping file with > the trusted domain name and the internal user to be used for that > domain. > > Quick help for the page: "To allow calls from an authenticated peer to > use resources that require permissions, add the domain as a Trusted > Peer (specify FQDN or IP address) and configure the permissions for > it. The peer must use TLS to communicate to this system, and the > Certificate Authority used to sign certificates must be installed on > both systems." Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
