PP12: Identity Experiences from Open Metadir 2

Lisa Dusseault <lisa@osafoundation.org> Fri, 18 January 2008 19:55 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFxJU-0005Ag-3k; Fri, 18 Jan 2008 14:55:40 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFxJT-000597-BP for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 14:55:39 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFxJT-00058x-1Q for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:55:39 -0500
Received: from laweleka.osafoundation.org ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFxJQ-0003t1-VX for discuss@apps.ietf.org; Fri, 18 Jan 2008 14:55:39 -0500
Received: from localhost (laweleka.osafoundation.org []) by laweleka.osafoundation.org (Postfix) with ESMTP id 22FCC142217 for <discuss@apps.ietf.org>; Fri, 18 Jan 2008 11:55:39 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([]) by localhost (laweleka.osafoundation.org []) (amavisd-new, port 10024) with ESMTP id IsWq0pBYhMSk for <discuss@apps.ietf.org>; Fri, 18 Jan 2008 11:55:32 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D9BA3142254 for <discuss@apps.ietf.org>; Fri, 18 Jan 2008 11:55:31 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
To: Apps Discuss <discuss@apps.ietf.org>
Message-Id: <3F090B94-3CD1-4ACD-998C-114490225696@osafoundation.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-7--959370904
References: <47833E67.3010507@it.su.se>
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: PP12: Identity Experiences from Open Metadir 2
Date: Fri, 18 Jan 2008 11:55:28 -0800
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: -3.4 (---)
X-Scan-Signature: 9ce0328cdf9c90e4680655d09dccace5
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Begin forwarded message:

> From: Leif Johansson <leifj@it.su.se>
> 	Experiences from OM2
> Abstract
> The OM2 (Open Metadir 2) project was initiated by Roland Hedberg and
> Leif Johansson and started out as an attempt to build an open  
> framework
> for identity provisioning at the campus and inter-campus level. By
> drawing on our experiences of (and opinions about the limitations of)
> LDAP and WS-* and drawing on RFC3254 for additional moral support we
> are attempting a new spin on both the directory and the "SOA".
> This paper attempts to highlight some aspects of OM2 as input to the
> applications area of the IETF. In many ways the OM2 tries to be a
> good IETF citizen, utilizing as many "products" of the IETF as
> possible.
> This document outlines OM2 (from 10' feet) with the intent to show
> how the IETF has supplied "infrastructure" for the OM2 protocol. We
> also try to show where that infrastructure (and the "products" of
> other SDOs) was found lacking.
> 1. The OM2 vs WS-*
> OM2 is a message-oriented layered architecture where OWL-DL ontologies
> play the role that XML-schema play in the WS-* architecture. OM2  
> messages
> are XML serializations of RDF graphs adhering the OM2 message  
> ontology.
> The OM2 is transport neutral - any mechanism which can be used to
> reliably send an XML message from between two endpoints can be used to
> send OM2 messages. The OM2 has no concept of message routing. All
> communication is point-to-point and security is provided by XML-DSIG
> at the XML serialization layer. The OM2 uses a fire-and-forget  
> messaging
> model with optional semantics for error handling and message ACKs.
> When devising OM2 we (at least in retrospect) identified some  
> limitations
> of the current WS-* architecture which we attempted to rectify:
>  * No coherent addressing scheme. Dealing with multiple transports in
>    WS-* presents a real challenge for application developers since  
> there
>    isn't even a coherent way to address services without implicitly
>    choosing a transport. The OM2 introduces a simple "RFC2822-like"
>    address which isn't tied to any one transport of OM2.
>  * The lack of a scalable service directory. Clearly UDDI will never
>    fulfill this promise. Instead the OM2 uses the DDDS to resolve OM2
>    addresses to references to OM2 node metadata documents which are
>    RDF graphs adhering to the OM2 node ontology. These documents play
>    the role that WSDL/WS-Policy play in the WS-* architecture.
> On top of the OM2 message layer is the OM2 application layer -
> corresponding to individual services in the WS-* architecture. The OM2
> application layers are also specified by OWL-DL ontologies and the  
> "body"
> of an OM2 message contains (the XML serialization of) an RDF graph  
> which
> adheres to one of these ontologies.
> 2. The OM2 vs LDAP
> The main application of OM2 (which after all is in its infancy  
> still) is
> campus and inter-campus identity provisioning. This is a field with  
> lots
> of commercial vendors aswell as OpenSource tools. Initially OM2 was  
> seen
> as neutral technology with which to build gateways between vendor  
> systems
> and protocols. The requirement to handle multiple vendors view of what
> are suitable information- and operational models for identity  
> provisioning
> was what initially lead us to consider OWL as the schema language -  
> has been shown to be semantically equivalent to UML2.
> There are important differences in the expressive power of XML schema
> and OWL (and probably also ASN.1) which means that by using RDF and  
> there is less need to create simplified externalized information  
> models
> which is what often happens when building SOAP-based RPCs - in essence
> the information model used in the RPC layer is the same information  
> model
> that is used in the system itself. This is a (overlooked?) property of
> LDAP which even if it sometimes leads to confusion serves to simplify
> the LDAP protocol.
> In spite of the simplicity of LDAP it has become common practice in
> the campus and other enterprise settings to build the enterprise LDAP
> directory from a separate data store, sometimes constructed from  
> one of
> the many "identity management" products on the market.
> The technology used in this backend data store is typically a  
> relational
> database possibly in combination with an ORM (Object Relational  
> Mapping)
> mechanism used to provide an object oriented view to the data. The  
> information model however is quite far removed from the relational  
> model
> and surprisingly far from the object-oriented model too.
> The impedance mismatch between LDAP and these provisioning data stores
> in our experience translate into high cost of changes in the  
> information
> model, eg when a user data store needs to grow support for groups.
> On the other hand there are often (at least perceived) good reasons  
> for
> having a separate provisioning data store. Some of those reasons are
> probably related to some specific well-known limitations of LDAP:
>   * Lack of referential integrity.
>   * Lack "complex" data types.
>   * Lack of meta data for associations1.
> These limitations are probably perceived as especially important since
> they represent deviations from the expected behavior of object- 
> oriented
> data-stores.
> In the OM2 project we initially tried to address these limitations
> by trying to view a native RDF data store (aka "triple store") as a
> generalization of a directory. By selecting the "right" ontologies for
> the graphs stored in the RDF store it is easy to see how the LDAP tree
> model could be represented in RDF/OWL.
> The real challenge however, is to define an operational model on
> RDF stores which share (at least some of) the properties of the LDAP
> protocol. This is where we used RFC3254 as a way to understand the
> differences between the requirements and the implementation (LDAP).
> After working on several variations on the common CRUD operational  
> model
> (Create Remove UPdate) we came up with the notion of the graph- 
> oriented
> MIRO operation (Match Replace Insert Otherwize) which resembles a
> generalized 'sed' operation operating on RDF graphs. This operation  
> seems
> to have enough atomicity across  related modifications to the graph to
> share some important properties of LDAP operations. The MIRO operation
> can easily support idempotency (op*op == op) which is important in  
> order
> to achieve loose consistency in a distributed model.
> 3. Final thoughts and questions
>   * Will the world ever be ready for a successor to LDAP? Do we  
> need one?
>   * Can a "SOA framework" grow out of the "IETF architecture"? Do  
> we care?
>   * Formal languages is a point of contentions in the IETF but is
>     still a commonly used tool. Why is this such a problem for the  
>   * Is this a problem of the IETF process or a factual problem or not
>     a problem at all?
>   * Can we concieve of a way to adress application endpoints that is
>     transport and protocol independent? Would that be at all useful?
> The OM2 identified and used a few key IETF technologies in several  
> parts of
> the stack, notably:
>   * Transports for XML-based messages - XMPP, HTTP
>   * Security for XML-based messages - XML-DSig
>   * Location of service endpoints - DDDS
> Is this the end? The OM2 is in many ways a fairly simple application
> framework. Are these the only LEGO building blocks which could be  
> of use
> by an application. Does this mean the applications area of the IETF is
> done now?