[foaf-protocols] implementation specific discussion on webid; azure service bus
home_pw at msn.com
Wed Mar 16 20:17:29 CET 2011
Ive been looking much more carefully at Microsoft azure service bus concept
- and its security model. It's interesting to webid, as its all rest.
First a summary: on-premise server instances (in pools) register with a
cloud bus, and get endpoints. To authorize the registration, the instances
present a security token, obtained by the usual IDP/SP methods, gets an
endpoint name, and a bidirectional message passing channel is setup. A
client of the bus presents an http request, which is eventually relayed to
the endpoint. Claims in the accompanying security token authorize access to
the endpoint, which relays the request down the channel, at which point
further claims authorize access to resources in webapp land.
In summary, its http over message passing, rather than http over TCP/IP
connections (sequences). To access the bus, one can use https. To receive
message from the queue, an server instance can establish an https tunnel. At
the https layer, one CANNOT have end-end https between client and server. A
client cert cannot be presented to the instance by the http client.
Web-auth headers can be passed end-end, as can soap headers executing
end-end security protocols at layer 7. Openid auth protocol should work
fine, for example, being a layer 7 crypto-session manager.
So, now lets look at this from a webid angle, accepting that client cert and
https don't work well as per the FOAF+SSL worldview. What parts are
1. When configuring an endpoint/service behavior allowing for https
(on those first and last mile relay hops), one can bind a self-signed cert
to the URI of the registered endpoint. This is very webid-like. Rather than
put the san-uri in the cert, its put in a trusted config file that binds the
uri to the same cert. So, we have certs and webid bindings already, in the
service bus concept . The cert bound to the URI can be minted/changed after
assignment of the URI, allowing the URI to be installed in the cert in the
SAN-URI field (and then registered).
2. The URIs that expose service instances to the world are registered
in a URI directory (tied to the bus), and can be discovered using atom. Atom
pubbing also updates the directory, too. It's all very rest/atom. This is
the same URI remember that the bus is tying to the service's SSL server cert
(that authenticate the on-premise server instance to its cloud bus
client-side endpoint in the relaying concept)
3. If that service instance acts an classical https client, it may do
so. If the service cert is authorized to act ssl client (because of the
cert's key usage oids) && it has an SAN_URI, it's just an FOAF+SSL client.
It's a glorified CGI setup, where the CGI processes makes outgoing https
So, lets invert the perspective. What is a server to this bus process, now
view as a personal client (remoted).
What does it have going for it?
It has client-certs, with SAN-URIs.
The URI is discoverable on the web, using atom
Being atom, content types of various types can accompany the URI.
Presumably, this could include a foaf card.
Thus, the azure service bus could offer a way to deliver a million foaf+ssl
capabilities to a million folks, using the "remoting concept". The resources
they interact with would leverage the server-side of the bus as the client
side of the web.
Obviously, everything in reality is spyable. But, its better than the web
(where folks pretend it's all end-end https, but it is rarely due to the way
https CONNECT proxies and https SSL MITM agents really work).
Ok. I think I have an experiment thesis, a testable condition, and an
interesting implementation concept. Since I have to learn to program the
service bus anyways (to comprehend the role of this latest year's token
blobs), I might as well play with it in the FOAF+SSL/webid sense. I can
understand better how folks in the token world impose delegation semantics
on a server (now acting as client) - which is consistent with an W3C webid
IX issue anyways.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols