Leifs BCP

Andrew Cormack of ja.net talked at the REFEDS meeting today about recent work they have done on standardizing interfederation agreements. One interesting announcement was that they’ve picked up my old idea of associating a license with federation metadata. They ran this by a set of lawyers who basically said: “don’t call it a license, call it terms-of-use and you’re fine”.

This has the potential of simplifying federation operations (including federation peering) significantly since service-providers don’t have to be tied to federations by legal agreements. For multi-federation service-providers like Microsoft Dreamspark or Elsevier this is good news since they may in time get away from having to sign agreements with every federation on the planet.

While this may seem like a bad idea for federations whose business was driven by being able to charge SPs for inclusion in metadata in the long run everyone benefits from the identity business growing with the removal of a major obstacle.

I’ll admit that X.509 certs aren’t the most hot topic in the world these days but they do rear their ugly little heads now and again. Most recently I’ve been involved with the people working on deploying the new Terena Certificate Service (TCS). The TCS is a follow-up of SCS – a pan-European flat-rate certificate service negotiated by Terena. The second round of procurement got us a sweet deal with Comodo which includes unlimited flat-rate user, code and server certificates (!)

Reading Andreas excellent post on adding support for OAuth in simpleSAMLphp and talking to Thomas Zangerl at NDGF who is helping Henrik Austad of UNINETT work on the confusa CA server we’ll use for the emai/GRID certificate part of TCS, we realized that OAuth could also be used in conjunction with Java WebStart to provide secure key generation and enrollment for confusa. Here is a rough outline:

The CA web interface is a federated application – in our case using the Browser Web SSO SAML 2 profile implemented in simpleSAMLphp. Today confusa allows the user to login via one of the trusted IdPs and then upload a PKCS#10 certification request in a form. This CSR is combined with attributes provided by the IdP to provision the certificate.

This works but doesn’t provide a very nice user experience. Instead we could launch a Java WebStart application or applet which does key generation on the client and submits the CSR to the CA server. This approach has been implemented by others. The problem is how to authenticate the CSR and tie it to the authenticated user attributes. A session identifier could be used but would typically need lots of tweaking to be sufficiently time-limited and secure.

If we try to apply OAuth to this situation and view the established session as a protected resource that the user grants access to for the purpose of binding a public key to it we get the following translation of OAuth concepts:

• Consumer: The Java WebStart application
• Service Provider: The CA application (confusa in our case)
• User: The user requesting a certificate.
• Protected Resource: The established session at the web applicaiton containing the user attributes.

Since the User has already logged in an authorized the request and is provisioned with a consumer key and a pre-authorized request token as part of the launch JNLP file. At this point the JWS application can obtain an access token and use it to associate the CSR with the established session using a PUT request.

I’ll be the first to admit that this is a corner-case – the request-token is authorized before any OAuth protocol flows are initiated but nevertheless it shows that OAuth is a very nice idea adaptable to many situations.

We will look deeper into the security implications of this and this process is expected to get lots of scrutiny by the GridPMA when we submit the TCS Grid CPS to the EuroGRID PMA for review so the jury is still out on weather this gets deployed or not! Stay tuned.

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 )

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:

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.