[OpenID] openid and acl's
Peter Williams
pwilliams at rapattoni.com
Sat Aug 4 17:30:48 UTC 2007
In "A Foaf File for Sun" [1] I argue that the Authorization service
can be thought of as a group identifier. The Authorization service is
a group membership verifier.
This can be used to give people access to different parts of the web
using RDF. An example I give is how this could be used to make access
to the W3C just a question sending someone Sun's foaf file.
Henry
[1] http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun <http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun>
In realty systems, a fair amount of web-work (from about 10 years ago) went into a pre-RDF-era resource framework, methods for serializing metadata-described resources as payloads during transfer across hypermedia-styled communications systems, and formulating an appropriate "RESTful" security model for specifically-open distributed systems environments.
In summary, the architecture ended up separating the login transaction (and its endpoint(s)), from the authorized jobbing transactions (and their sets of endpoints/ports) . This architecture is evidently well aligned with the SAML world that separates policy decision points (PDPs) from policy enforcement points (PEPs), and even Attribute Authorities. Its obviously trivial to draw parallels between these SAML-era constructs and the component entities evolving in the OpenID 2.0 world.
Again, way long ago, the realty RETS standard for data interchange had the login transaction not only control the initiation of sessions (based on digest auth of a user/UA), but digest auth +session handling also allowed for (a) connectionless secure communications, and (b) job management on the worker transactions - bringing all the usual benefits of those properties to mainframe-grade jobbing engines, struggling as usual to juggle (computing) resources, timeliness constraints, etc.
Addressing the authorization space, finally, the login transaction returns web-addressed endpoints as "capabilities" - infact a simple set of URLs that the PDP (in modern parlance) has granted to a given identified user/UA to use as "authorized entitlements". A PEP implemented as a web filter (in a manner rather like how JanRain implemented their public OpenID Auth stack for Mono) enforces the connectionless authorization signals. An extension model allows each security/admisntiration domain to define its own ports/endpoints/URL and PDP behavior, beyond the standardized ports for the search/input/modify/management transactions, etc.
In more recent work, extending that pre-RESTful but stateless-like model for WebSSO was trivial. The "RETS" architecture already had all the right architectural form, and WebSSO just slotted right in. In the SAML variant anyways, the existing application ports doing realty search, updates, etc ...know nothing of the SAML layer entities inserted into the communication stack handling the endpoints associated with those ports.
Now, I'm contemplating XACML, too. The FOAF angle is also intriguing. As realty is now re-contemplating its navel wondering about the appropriateness of its "non-standard" pre-RDF resource model, how webSSO ought to fit in the future (not just today) its does seem time to also consider the authorization dimension - particularly since it evidently intersects with wider resource model design issues.
If we go back to that realty login transaction (enhanced, optionally with WebSSO), it returned capabilities/entitlements as a simple list of URLs upon completion of I&A + PDP. Rather than a list, those URLs could just as easily be presented as a trivial RSS feed (of URLs). to an intelligent UA, or OWL stream (allowing for conveyance of the authorization semantics). IN the latter case, the authorization semantics would presumably need to be protected while they go roundtrip from server-side PDP to server-side PEP (using signatures?). But I would seem to get connectionless authorization, meta-data driven authorization models, and a harmonization of handling authorization resources with how all other categories of resources are addressed in the distributed data model.
Peter.
More information about the general
mailing list