Shibboleth Developers

[Peter Saint-Andre <>]

First, a quick introduction. I come from the Jabber community, which 
is best-known for developing open-source instant messaging and presence
technologies. Those technologies are based on a set of wire protocols
for streaming XML between entities on a network. The core protocols 
have been formalized in the IETF under the name Extensible Messaging 
and Presence Protocol (XMPP). 

Some introductory text on Jabber/XMPP technologies and protocols is 
here:

http://www.jabber.org/about/overview.html
http://www.jabber.org/about/techover.html

Gory details are here:

http://www.jabber.org/ietf/

There are many kinds of entities on Jabber/XMPP networks: clients, 
servers, bots, and specialized components for things like groupchat 
(a la IRC), content syndication (think RSS notifications), and 
workflow applications. Since this may be different from what folks are 
accustomed to in Shibboleth, it's probably valuable to explain the XMPP 
network topology a bit. We have a client-server architecture, in which 
a client authenticates with a server in order to gain access to the
network. Once a client authenticates, it can communicate with other
clients that use the same server, with other servers and with clients
connected to those servers (if server-to-server communications are
enabled), and with add-on services that are hosted by various servers on
the network. It seems to me that some of the more interesting use cases
for Jabber/XMPP involve access to such services. Therefore in the 
following use cases I take as an example a user's interaction with a 
groupchat room that is hosted on a conference service outside the user's
domain. 

I see two possible models for applying SAML/Shib to XMPP:

1. User's server acts as source for attributes; user delegates to his
   or her server the authority to act on the user's behalf regarding
   access by XMPP services to the user's attributes

2. User's server provides handle only, and services acquire attributes 
   from a dedicated attribute authority rather than from user's server

There may be more sophisticated approaches, but my ignorance of
SAML/Shib prevents me from seeing them yet. With much help from 
Steve Carmody, I've written up descriptions of these two models...


MODEL #1: XMPP Server as Attribute "Proxy"

1. User authenticates with XMPP server by providing credentials 
consistent with local access policies (e.g., Digest-MD5 password or
X.509 certificate); local access policies may need to be adjusted or 
strengthened in order to participate in the following transactions 
(the text below assumes that Kerberos is used).

2. XMPP server generates an RSA key pair, then forwards a Kerberos 
service ticket and the public key to the KCA server, which 
authenticates the user.

3. KCA server creates a new short-term certificate for user with 
Kerberos principal as subject name. The certificate contains a 
non-critical X.509 extension with pointer to AA.

   NOTE: in deployments that do not use Kerberos, Steps #2 and #3
         might be replaced by the following:

         2a. XMPP server creates an SSL tunnel to the local SAML 
             Authn Authority, authenticates, and obtains a signed 
             SAML Authn Assertion.
         3a. Assertion contains the public key used to create the 
             SSL tunnel (XMPP server must use the same key to create 
             SSL tunnels with XMPP services, which will then use a 
             "holder-of-key" confirmation method to ensure that the 
             assertion applies to the XMPP server).

4. XMPP server contacts the AA over an encrypted channel (TLS/SSL). 
Local, trusted copy of certificate of Shib AA is used to verify that 
XMPP server is communicating with the proper AA. XMPP server performs 
mutual authentication with Shib AA using its own certificate and 
private key.

5. XMPP server presents user cert and requests attributes for user.

6. Shib AA consults ARPs to determine XMPP server's right to access
attributes for user, then delivers list of attributes to XMPP server 
over encrypted channel (TLS/SSL).

7. User requests to join chatroom on remote XMPP-based conference 
service (note that this request is routed first through user's XMPP
server, then to the XMPP server hosting the service, then to the 
conference service itself).

8. Conference service queries XMPP server for attributes.

9. XMPP server provides signed attribute bundle to conference service.

10. Conference service makes access decision and returns error or 
success to user.

Pros:
  a. Forces Shibboleth handling onto XMPP server (where complexity 
     belongs).
  b. Simpler for XMPP service to implement (services are not as smart
     as servers on the XMPP network).

Cons: 
  a. XMPP server provides full attribute bundle to all services.
  b. Requires development of XMPP binding for SAML.


MODEL #2: Direct Service Communication with AA

1. User authenticates with XMPP server by providing credentials 
consistent with local access policies (e.g., Digest-MD5 password or
X.509 certificate); local access policies may need to be adjusted or 
strengthened in order to participate in the following transactions (the
text below assumes that Kerberos is used).

2. XMPP server generates an RSA key pair, then forwards a Kerberos 
service ticket and the public key to the KCA server, which 
authenticates the user.

3. KCA creates a new short-term certificate for user with handle as 
subject name (or more likely encoded as part of subject name -- e.g., 
as common name). The certificate contains a non-critical X.509 
extension with pointer to AA.

4. User requests to join chatroom on remote XMPP-based conference 
service.

5. Conference service queries XMPP server for handle.

6. XMPP server provides handle to conference service (based on 
server-defined or user-defined access policy).

7. Conference service requests attributes directly from AA.

8. AA provides relevant attributes to conference service.

9. Conference service makes access decision and returns error or 
success to user.

Pros:
  a. Only the relevant attributes are provided to service, not the 
     full bundle -- provides better respect for privacy.
  b. Requires only communication of handle over XMPP (thus simplifying
     the XMPP protocol development).

Cons:
  a. Forces Shibboleth communications onto XMPP services, which as
     noted are not generally as smart as XMPP servers and which also
     tend to be written in a greater diversity of languages (Python,
     Perl, etc.).

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php