Category Archives: Cleaning the desk

LDAP schemas for IM and SIP

Over the years at Stockholm university I worked on lots of new technology. Some of that technology deserves a wider audience and in some cases I’ve been asked to provided detailed descriptions of some of the solutions we built. I’ll try to summarize some of the most (imho) useful stuff here for future reference.

I’ll start with something that Olle E Johansson over at edvina recently asked me about: LDAP Schemas for IM and SIP.

The production environment at Stockholm university was designed to be tightly integrated with focus on single points of administration for things like authentication, identity, etc. Kerberos and LDAP is (still) the religion.

Jabber

We started using jabber using ejabberd a couple of years ago and decided to use our LDAP-based identities (naturally). However we found that nobody had designed a credible virtual-host aware schema that was useful for IM applications. Here is the schema we came up with. It is pretty basic to say the least:


# jabberuser (at) 1.2.752.43.9.1
attributeType ( 1.2.752.43.9.1.1
NAME 'jabberID'
DESC 'The Jabber ID(s) associated with this object. Used to map a JID to an LDAP account.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# jabberuser (oc) 1.2.752.43.9.2

objectClass ( 1.2.752.43.9.2.1
NAME 'jabberUser'
DESC 'A jabber user'
AUXILIARY
MUST ( jabberID ) )

Since we used Kerberos to authenticate users this was really all we needed. Since jabberID is multivalued we often attached multiple jabberIDs to a single LDAP. This gave us a way to test new servers and domains wo setting up additional infrastructure. We used this together with the external authentication module of ejabberd (which I contributed to ejabberd specifically for this case, however it is now part of the standard ejabberd distribution).

SIP

The SIP case turned out to be slightly more complex. Since SIP still uses a simple share-secret based authentication mechanism by default we needed to stick passwords somewhere. At that time our Kerberos (Heimdal naturally!) didn’t do remote digest yet so we needed to keep the passwords outside our KDC. We decided to face our shame and stick them in LDAP.

Thus for SIP we needed to represent both information about SIP authentication and SIP message routing. This is analogous to the mail case where you keep the identity used to authentication to the SMTP/IMAP server logically (in the schema sense that is) separate from the attributes used to represent email aliases. This is what we came up with – I hope the comments explain some of the semantics.


# The sipLocalAddress is a (multivalued) attribute used to assocate
# uri:s with an entity to which sip messages can be addressed. This
# attribute can contain any uri scheme used in ENUM including sip:
# and tel:

attributetype ( 1.2.752.43.4.1.1
NAME 'sipLocalAddress'
DESC 'A uri (sip or otherwize) associated with this object'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# This is the unique user identifier and primary key into the location
# database of a sip server using this schema. The syntax of the value
# is an opaque IA5-string. No structure is implied (neither ,
# @ or otherwize) is implied and MUST NOT be assumed.

attributetype ( 1.2.752.43.4.1.2
NAME 'sipAuthenticationUser'
DESC 'The user identifier used for authentication.'
SINGLE-VALUE
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# Cleartext password used in MD5-based authentication.

attributetype ( 1.2.752.43.4.1.3
NAME 'sipPassword'
DESC 'The cleartext SIP authentication password.'
SINGLE-VALUE
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# Incoming messages to a sipRoutingObject is sent to this address. The
# implied semantic is that the sip-server regard the presence of this
# attribute as a REDIRECT which must be proxied to the client UA.

attributetype (1.2.752.43.4.1.4
NAME 'sipRoutingAddress'
SINGLE-VALUE
DESC 'A uri (sip or otherwize) used to route sip messages'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# A sipUser SHOULD be associated with a person, account or similar
# STRUCTURAL object class.

objectclass ( 1.2.752.43.4.2.1
NAME 'sipUser'
AUXILIARY
MUST ( sipAuthenticationUser )
MAY ( sipPassword ) )

# A sipRoutingObject MAY be associated with either a sipUser object or
# with a groupOfNames, groupOfUniqueNames or organizationalRole in which
# case forking of the call to those entries present in referring attributes
# who are also sipUser object is implied.

objectclass ( 1.2.752.43.4.2.2
NAME 'sipRoutingObject'
AUXILIARY
MUST ( sipLocalAddress )
MAY ( sipRoutingAddress $ telePhoneNumber ) )

This work was done together with Fredrik Thulin (who still works for Stockholm university), the lead developer of the YXA SIP-server where this stuff got implemented and deployed as part of the Stockholm university SIP infrastructure. The operational experience of this approach to SIP identity management has been good overall.

What would I have done different today?

Definitely I’d have used remote digest in Heimdal to keep all authentication secure inside my KDC. Passwords in LDAP are an abomination (imo). I would have tried to combine the two schemas into a single Presence/IM/VOIP schema since most of the semantics is either harmless or equivalent in all cases.

Comments Off on LDAP schemas for IM and SIP

Filed under Cleaning the desk