[Standards-JIG] authorization: the next generation

Peter Saint-Andre stpeter at jabber.org
Wed Jul 14 15:49:35 UTC 2004


Warning: long post.

Authorization is control over access to a resource. On Jabber/XMPP
networks, such resources could be chatrooms, pubsub nodes, gateways,
files, etc. Right now, how do we grant access to, say, a chatroom? The
room may be members-only (see JEP-0045), in which case the room owner
needs to maintain a list of those who are authorized to access the room.
We have something similar in pubsub (JEP-0060): the owner of a pubsub node
can specify whitelists or blacklists of entities that are allowed to
subscribe to the node or publish to the node.

This is all well and good, but it doesn't scale well because humans need
to make the access decisions. A more flexible approach may be valuable.

Consider a real-life example I'm familiar with. In investment banks and
other securities firms, the SEC has mandated that traders can't talk with
analysts and vice-versa. Now let's say we have a chatroom about trading
gold futures. Who's allowed in? Well, the chatroom owner could maintain a
list of all the traders and allow only traders into the room. But why push
maintenance of the trader list onto the chatroom owner? Presumably data
about who is a trader and who is an analyst already exists in LDAP or
whatever. (Naturally, the problem become more complex if we want to enable
communications across organizations, since the conferencing service would
need information from multiple LDAP stores, but we'll get to that.) We
could hack together some LDAP checks, but then we'd need to do something
similar for pubsub feeds about gold prices and so on. Pretty soon we'd be
designing a generalized system for making decisions about access to XMPP
services. And given that this problem applies to files, websites, and all
sorts of other resources on the network, you'd think that someone has
already developed such a system.

Indeed they have: OASIS (the Organization for the Advancement of
Structured Information Standards) has developed something called Security
Assertion Markup Language or SAML, which is an XML framework for
exchanging authentication and authorization information:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

Perhaps the most advanced application of SAML is Shibboleth, a technology
for authorization of access to websites developed by the Internet2
consortium:

http://shibboleth.internet2.edu/

Over the last 9 months or so, I've been involved with Internet2's working
group on instant messaging to figure out how some of the authorization
concepts captured in SAML and Shibboleth could apply to XMPP. This email
outlines some initial thoughts. My intent is to start a conversation
within the Jabber community so that we can figure out if SAML is the right
approach to authorization going forward.

SAML bases authorization decisions on what are called "attributes" about
entities. An attribute could be anything that is significant in a
particular context. In the securities industry, one salient attribute
might be whether a person is a trader. In a university it might be whether
someone is faculty. In a hospital it might be whether a person is a doctor
or nurse in the ICU. And so on. An attribute can be passed around in a
secure way either directly or via a "handle" to the attribute, and then
provided to trusted entities that need to make access decisions. Other
entities on the network know that they can trust the attributes as much as
they trust the "attribute authorities" that vouch for this data.

(Read the SAML specs for information about how it all works -- once we
figure out if this approach makes sense, I can write up a JEP that
outlines it in more detail.)

I see two possible models for applying SAML to XMPP:

1. User's server acts as source for attributes about the user; 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 a "handle" only, and services acquire 
   attributes from a dedicated attribute authority rather than from 
   user's server.

With help from Steve Carmody at Brown University, I've written up
descriptions of these two models using Shibboleth...


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 (combined Kerberos
service and PK certificate authority), 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 Attribute Authority.

   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 Attribute Authority over an encrypted channel
(TLS/SSL). Local, trusted copy of certificate of Shibboleth Attribute
Authority is used to verify that XMPP server is communicating with the
proper Attribute Authority. XMPP server performs mutual authentication
with Shibboleth Attribute Authority using its own certificate and private
key.

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

6. Shibboleth Attribute Authority consults Attribute Release Policies 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 Attribute Authority

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 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 Attribute
Authority.

8. Attribute Authority 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.).

Another way to dip our toes into the goodness of SAML would be to make use
of the forthcoming SAML method for SASL authentication. There is supposed
to be an Internet-Draft on this soon and it may be a good first step in
integrating SAML.

Open-source Shibboleth code exists in both Java and C as far as I know,
but not in languages such as Python. This might make the integration task
easier, but that's something we can delve into if people think this
approach makes sense for more flexible authorization in future XMPP
services.

Thoughts?

Peter




 




More information about the Standards mailing list