[OpenID] openid and acl's
Story Henry
henry.story at bblfish.net
Tue Aug 7 09:46:40 UTC 2007
On 4 Aug 2007, at 19:30, Peter Williams wrote:
>
>
> 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>
Just to be critical of my own proposal first.
Whilst using the Authorization service as a group identifier makes
sense, it can be criticized for not scaling in the right way. If
every group tried to have an authorization server then one would be
back to square one, namely having to remember one password per group.
Well at least one would only need to remember on openid, this openid
pointing to each of the authorisation servers.
Perhaps the idea of having a number of authorization servers can be
made to make sense. If the OpenId had a foaf representation then it
could express which authorisation servers we linked to which groups.
My foaf file could be written like this:
@prefix oid: <http://openid.org/tmp/ont#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<me> a foaf:Person;
foaf:firstName "Henry";
foaf:family_name "Story";
foaf:mbox <mailto:henry.story at bblfish.net>;
foaf:openid [ = <http://openid.sun.com/bblfish>;
oid:service [ = <https://openid.sun.com/openid/
service>;
is oid:memberIdService of <http://
sun.com/data#sunw> ],
[ = <https://openid.sun.com/openid/
engineer/Service;
is oid:memberIdService of <http://
sun.com/data#engineer> ] .
This is saying in short that my openid has two services, one of them
shows that I am a member of Sun Microsystems, the other that I am
member of the sun engineering team. One could imagine that both of
those use the same authentication password, so as not to be so
troublesome.
As the above is a little complex, (I am using the inverse relation of
oid:memberIdService for example), here is the same thing illustrated
graphically:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openid-foaf-sun.png
Type: image/png
Size: 120096 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070807/cc1e88ee/attachment-0002.png>
-------------- next part --------------
I have added the two foaf:member relations (in blue) that are implied
after authentication with the services. I have also filled out the
engineer/service in marble grey, because it feels a bit heavy handed.
It is clear that the authorization server does make one part of a
group - the group of people authorized by the server, which can be
specified in foaf to be a subset of people working at a company, or
owning a mastercard, ... . But clearly not every group need to be
linked to an authorization service. Other groups, the clients one
logs into for example, will know one as being part of their group
through enumeration.
Since being member of a group can be expressed very simply in foaf
file, one could also envisage it being
done there. One would just have to add the triples
<me> is foaf:member of <http://sun.com/data#sunw>, <http://sun.com/
data#engineer> .
Pros:
- more light weight that the creation of a verification service
- this would make it public which groups one was a member of, and
would allow a client to discover the information via a SPARQL query
as described in my previous article "foaf and openid"[1].
Cons:
- The client would have to trust the foaf files statement. Of
course if the group itself listed all
its members at its URL, then that would be less of an issue. (see
network of trust)
- it is public. Perhaps some people don't want others to know which
groups they are part of.
The other service that could give this information out is the profile
server. Here at least the end user can decide which client sees what
information. On the other hand we still have the problem of trust
because people can upload any extensions on that server. But trust is
a matter of description, so if say the Sun foaf file, said somehow
that that server was correct in anything it said, then we'd be back
in the game.
Again the network of trust article is really important to read.
http://dig.csail.mit.edu/2007/06/ieee-ic-decentralized-identity-
weitzner.html
Henry
[1] http://blogs.sun.com/bblfish/entry/foaf_openid
> 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.
Is "realty systems" a company? Sorry I am new to this space.
>
> 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.
I am going to have to learn SAML next, it seems...
> 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).
RSS is really good for specifying changes to things. It is really
quite limited. More on what atom really is:
http://blogs.sun.com/bblfish/entry/what_atom_is_all_abou
> 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?).
I fount the follwing: http://usefulinc.com/foaf/signingFoafFiles
Henry
> 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.
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
More information about the general
mailing list