Thanks. Fair enough indeed. And thanks for sticking with me through the process. I know it's a pain when n00bs like me get involved trying to use bleeding edge code :-) I look forward to the consumer version.
In fact, I have feeling that Kingsley may have found much of what I want at http://dig.csail.mit.edu/2009/mod_authz_webid/README -- ** this might be what you need re. Apache ** . In fact I don't have access to the Apache config on the machine I was using, but I will have a go on a machine I do when I have a minute. If I (or someone else) is successful, a report back with the absolute minimum for doing the whole WebID thing that way would be a nice resource. And of course I would love to see a Wordpress plugin (the Drupal plugin seemed to have to many dependencies for me to even think about writing my first wordpress plugin!) Best Hugh On 9 Aug 2013, at 19:17, Henry Story <[email protected]> wrote: > > On 9 Aug 2013, at 19:34, Hugh Glaser <[email protected]> wrote: > >> Thanks Henry. >> Well I had looked there, but it all looked quite complicated - I have never >> cloned a git thingy before and I don't even know if Java is available on the >> host :-) >> But emboldened by your encouragement I went for the "The short version". >> I was very encouraged, as it seemed to do quite a lot, but seemed to hang >> after getting >> play-2-TLS-e6c58f64585b182f937358fa984474b86984d77d.tar.bz2 >> >> But, even when I tried to do it by hand (the Longer Version), I eventually >> got the java was killed for excessive resource usage. >> By which tim sit had downloaded 427MB of stuff. >> I don't think these are the sort of hosting costs I want to have. >> So I have a sense this is not the solution I was looking for :-) > > Well this is not optimised yet. It's for developers. At the moment you need a > powerful modern machine. I am assuming people here on the Linked Data List > are interested in working with bleeding edge code, and getting an idea of > where things are heading to. > > If you want the couch potatoe version, then you need to wait for > the consumer version. :-) > > >> >> Very best >> Hugh >> >> By the way, the link in "An initial implementation of Linked Data Basic >> Profile" does a 404. >> >> On 9 Aug 2013, at 18:09, Henry Story <[email protected]> >> wrote: >> >>> >>> On 9 Aug 2013, at 18:55, Hugh Glaser <[email protected]> wrote: >>> >>>> Thanks. >>>> I've looked at quite a bit of this stuff, but still don't see where the >>>> ACL document gets stored and used. >>>> >>>> I am beginning to get the sense that I may have to write some code, other >>>> than the ACL rdf to do this. >>>> Surely Apache or something else will do this for me? >>>> Can't I "just" put the ACL in a file (as in htpasswd) and point something >>>> at it? >>>> I certainly don't want to be writing code to make one photo (or simply a >>>> static web site) available. >>>> Or is that the "delegated service" you are talking about? >>>> >>>> I've got my fingers crossed here. >>> >>> You can follow the instructions on installing >>> https://github.com/stample/rww-play >>> (It's under the Apache Licence and patches and contributions are welcome ) >>> >>> Then you'll be able to do the following: >>> >>> An initial implementation of the Linked Data Platform spec is implemented >>> here. The same way as theApache httpd server it servers resource from the >>> file system and maps them to the web. By default we map the test_www >>> directory's content to http://localhost:8443/2013/. >>> >>> The test_www directory starts with a few files to get you going >>> >>> $ cd >>> test_www >>> >>> $ >>> ls -al >>> total 48 >>> drwxr-xr-x 4 hjs admin 340 9 Jul 19:04 . >>> drwxr-xr-x 15 hjs admin 1224 9 Jul 19:04 .. >>> -rw-r--r-- 1 hjs staff 229 1 Jul 08:10 .acl.ttl >>> -rw-r--r-- 1 hjs admin 109 9 Jul 19:04 .ttl >>> lrwxr-xr-x 1 hjs admin 8 27 Jun 20:29 card -> card.ttl >>> -rw-r--r-- 1 hjs admin 167 7 Jul 22:42 card.acl.ttl >>> -rw-r--r-- 1 hjs admin 896 27 Jun 21:41 card.ttl >>> -rw-r--r-- 1 hjs admin 102 27 Jun 22:32 index.ttl >>> drwxr-xr-x 2 hjs admin 102 27 Jun 22:56 raw >>> drwxr-xr-x 3 hjs admin 204 28 Jun 12:51 >>> test >>> All files with the same initial name up to the . are considered to work >>> together, (and in the current implementation are taken care of by the same >>> agent). >>> >>> Symbolic links are useful in that they: >>> >>> • allow one to write and follow linked data that works on the file >>> system without needing to name files by their extensions. For example a >>> statement such as [] wac:agent <card#me> can work on the file system just >>> as well as on the web. >>> • they guide the web agent to which the default representation should be >>> • currently they also help the web agent decide which are the resources >>> it should serve. >>> There are three types of resources in this directory: >>> >>> • The symbolic links such as card distinguish the default resources >>> that can be found by an httpGET on http://localhost:8443/2013/card. Above >>> the card -> card.ttl shows that card has a defaultturtle representation. >>> • Each resource also comes with a Web Access Control List, in this >>> example card.acl.ttl, which set access control restrictions on resources on >>> the file system. >>> • Directories store extra data (in addition to their contents) in the >>> .ttl file. (TODO: not quite working) >>> • Directories also have their access control list which are published >>> in a file named .acl.ttl. >>> These conventions are provisional implementation decisions, and >>> improvements are to be expected here . (TODO: >>> >>> • updates to the file system are not reflected yet in the server >>> • allow symbolic links to point to different default formats ) >>> Let us look at some of these files in more detail >>> >>> The acl for card just includes the acl for the directory/collection . >>> (TODO: wac:include has not yet been defined in the Web Access Control >>> Ontology) >>> >>> $ >>> cat card.acl.ttl >>> @prefix wac: < >>> http://www.w3.org/ns/auth/acl# >>>> . >>> @prefix foaf: < >>> http://xmlns.com/foaf/0.1/ >>>> . >>> >>> <> wac:include <.acl> . >>> >>> The acl for the directory allows access to all resources in the >>> subdirectories of test_www when accessed from the web as >>> https://localhost:8443/2013/ only to the user authenticated >>> as<https://localhost:8443/2013/card#me>. (TODO: wac:regex is not defined in >>> it's namespace - requires standardisation.) >>> >>> $ >>> cat .acl.ttl >>> @prefix acl: < >>> http://www.w3.org/ns/auth/acl# >>>> . >>> @prefix foaf: < >>> http://xmlns.com/foaf/0.1/ >>>> . >>> >>> >>> [] acl:accessToClass [ acl:regex "https://localhost:8443/2013/.*"; ] >>> ; >>> acl:mode acl:Read, acl:Write; >>> acl:agent <card#me> . >>> >>> Since card's acl includes only the above directory acl, <card#me> can read >>> that file. The following curlcommand does not specify the public and >>> private keys to use for authentication and so fails: >>> >>> $ curl -i -k https://localhost:8443/2013/card >>> >>> curl: >>> (56) SSL read >>> : error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate, >>> errno 0 >>> >>> As curl does not allow WANT TLS connections, but only NEED, a failure to >>> authenticate closes the connection. Most browsers have the more friendly >>> behavior allowing the server to return an HTTP error code and an >>> explanatory body. >>> >>> Requesting the same resource with a curl that knows which client >>> certificate to use, the request goes through. >>> >>> $ curl -i -k --cert ../eg/test-localhost.pem:test >>> https://localhost:8443/2013/card >>> >>> HTTP/1.1 200 OK >>> Link: < >>> MailScanner has detected a possible fraud attempt from "localhost:8443" >>> claiming to be https://localhost:8443/2013/card.acl>; rel= >>> acl >>> Content-Type: text/turtle >>> Content-Length: 1005 >>> >>> >>> < >>> #me> <http://www.w3.org/ns/auth/cert#key> _:node17vcshtjbx1 ; >>> >>> < >>> http://xmlns.com/foaf/0.1/name> "Your >>> Name"^^<http://www.w3.org/2001/XMLSchema#string >>>> ; >>> < >>> http://xmlns.com/foaf/0.1/knows> <http://bblfish.net/people/henry/card#me >>>> . >>> >>> _:node17vcshtjbx1 a < >>> http://www.w3.org/ns/auth/cert#RSAPublicKey >>>> ; >>> < >>> http://www.w3.org/ns/auth/cert#exponent> >>> "65537"^^<http://www.w3.org/2001/XMLSchema#integer >>>> ; >>> < >>> http://www.w3.org/ns/auth/cert#modulus> >>> "C13AB88098CF47FCE6B3463FC7E8762036154FE616B956544D50EE63133CC8748D692A00DAFF5331D2564BB1DD5AEF94636ED09EFFA9E776CA6B4A92022BB060BF18FC709936EF43D345289A7FD91C81801A921376D7BCC1C63BD3335FB385A01EC0B71877FCBD1E4525393CCD5F2922D68840945943A675CCAE245222E3EB99B87B180807002063CB78174C1605EA1ECFECF57264F7F60CD8C270175A1D8DD58DFC7D3C56DB273B0494B034EC185B09977CBB530E7E407206107A73CD4B49E17610559F2A81EA8E3F613C3D3C161C06FE5CB114A8522D20DED77CAAA8C761090022F9CD4AF2C8F21DF7CF05287E379225AEA6A3A6610D02C4A44AA7CEED2CC3"^^<http://www.w3.org/2001/XMLSchema#hexBinary >>>> . >>> >>> Notice the Link header above. Every resource points to its ACL file in such >>> a header. >>> >>> The client certificate in ../eg/test-localhost.pem contains exactly the >>> private key given in the above cert as you can see by comparing the modulus >>> and exponents in both representations. This is what allows the >>> authentication to go through, using the (WebID over TLS >>> protocol)[http://webid.info/spec/]. >>> >>> $ >>> openssl x509 -in ../eg/test-localhost.pem -inform pem -text >>> Certificate: >>> Data: >>> Version: 3 >>> (0x2) >>> >>> Serial Number: 13633800264985240815 >>> (0xbd34fd1b251264ef) >>> >>> Signature Algorithm: sha1WithRSAEncryption >>> Issuer: >>> O=\xE2\x88\x85, CN= >>> WebID >>> Validity >>> Not Before: May 3 19:36:33 2013 GMT >>> Not After : May 3 19:46:33 2014 GMT >>> Subject: >>> O=ReadWriteWeb, CN=test >>> @localhost >>> Subject Public Key Info: >>> Public Key Algorithm: rsaEncryption >>> Public-Key: >>> (2048 bit) >>> >>> Modulus: >>> 00:c1:3a:b8:80:98:cf:47:fc:e6:b3:46:3f:c7:e8: >>> 76:20:36:15:4f:e6:16:b9:56:54:4d:50:ee:63:13: >>> 3c:c8:74:8d:69:2a:00:da:ff:53:31:d2:56:4b:b1: >>> dd:5a:ef:94:63:6e:d0:9e:ff:a9:e7:76:ca:6b:4a: >>> 92:02:2b:b0:60:bf:18:fc:70:99:36:ef:43:d3:45: >>> 28:9a:7f:d9:1c:81:80:1a:92:13:76:d7:bc:c1:c6: >>> 3b:d3:33:5f:b3:85:a0:1e:c0:b7:18:77:fc:bd:1e: >>> 45:25:39:3c:cd:5f:29:22:d6:88:40:94:59:43:a6: >>> 75:cc:ae:24:52:22:e3:eb:99:b8:7b:18:08:07:00: >>> 20:63:cb:78:17:4c:16:05:ea:1e:cf:ec:f5:72:64: >>> f7:f6:0c:d8:c2:70:17:5a:1d:8d:d5:8d:fc:7d:3c: >>> 56:db:27:3b:04:94:b0:34:ec:18:5b:09:97:7c:bb: >>> 53:0e:7e:40:72:06:10:7a:73:cd:4b:49:e1:76:10: >>> 55:9f:2a:81:ea:8e:3f:61:3c:3d:3c:16:1c:06:fe: >>> 5c:b1:14:a8:52:2d:20:de:d7:7c:aa:a8:c7:61:09: >>> 00:22:f9:cd:4a:f2:c8:f2:1d:f7:cf:05:28:7e:37: >>> 92:25:ae:a6:a3:a6:61:0d:02:c4:a4:4a:a7:ce:ed: >>> 2c:c3 >>> Exponent: 65537 >>> (0x10001) >>> >>> X509v3 extensions: >>> X509v3 Basic Constraints: >>> CA:FALSE >>> X509v3 Key Usage: critical >>> Digital Signature, Non Repudiation, Key Encipherment, Key >>> Agreement >>> Netscape Cert Type: >>> SSL Client, S/MIME >>> X509v3 Subject Alternative Name: critical >>> URI:https://localhost:8443/2013/card#me >>> X509v3 Subject Key Identifier: >>> 3C:1B:CF:F2:E5:59:9A:E8:76:BE:83:1D:64:FB:07:4E:08:C6:FC:14 >>> Signature Algorithm: sha1WithRSAEncryption >>> 07:97:78:f5:11:58:00:50:17:91:14:e8:e3:0d:34:22:74:07: >>> ae:61:39:87:23:7a:6c:5c:14:af:13:a6:c8:54:ac:55:d4:41: >>> 25:45:eb:52:90:ff:56:b0:f9:71:be:ec:c8:2c:a1:19:1c:86: >>> 42:04:3c:55:7c:96:5c:60:70:0a:d7:ed:5b:53:11:56:7e:14: >>> 32:92:b9:22:a7:c6:ce:ff:77:17:4a:ac:da:02:ac:24:0e:0e: >>> 35:18:bd:e3:73:00:3b:8a:aa:ec:86:76:66:dd:4b:1b:da:0c: >>> c8:a1:d3:27:26:df:bf:6f:55:11:50:3b:8e:04:12:5a:b9:d4: >>> 7d:7e >>> >>> We would of course like to make the card world readable so that the >>> certificate can be used to login to other servers too. To do this the user >>> <card#me> can append to the <card.acl.ttl> file an authorization making >>> card world readable, using an obvious subset of SPARQL Update >>> >>> $ >>> cat ../eg/card.acl.update >>> PREFIX foaf: < >>> http://xmlns.com/foaf/0.1/ >>>> >>> INSERT DATA >>> { >>> [] acl:accessTo <https://localhost:8443/2013/card >>>> ; >>> acl:mode acl:Read; >>> acl:agentClass foaf:Agent . >>> >>> } >>> $ curl -X PATCH -k -i --data-binary @../eg/card.acl.update -H >>> "Content-Type: application/sparql-update; utf-8" --cert >>> ../eg/test-localhost.pem:test MailScanner has detected a possible fraud >>> attempt from "localhost:8443" claiming to be >>> https://localhost:8443/2013/card.acl >>> It is now possible to read the card without authentication >>> >>> $ curl -i -k https://localhost:8443/2013/card >>> >>> HTTP/1.1 200 OK >>> Link: < >>> MailScanner has detected a possible fraud attempt from "localhost:8443" >>> claiming to be https://localhost:8443/2013/card.acl>; rel= >>> acl >>> Content-Type: text/turtle >>> >>> [...] >>> Next we can publish a couch surfing opportunity using HTTP's POST method as >>> explained by the LDP spec >>> >>> $ curl -X POST -k -i -H "Content-Type: text/turtle; utf-8" --cert >>> ../eg/test-localhost.pem:test -H "Slug: couch" -d @../eg/couch.ttl >>> https://localhost:8443/2013/ >>> >>> HTTP/1.1 201 Created >>> Location: >>> https://localhost:8443/2013/couch >>> >>> Content-Length: 0 >>> >>> The Location: header in the above response tells us that the name of the >>> created resource ishttps://localhost:8443/2013/couch. >>> >>> We can now look at the contents of the https://localhost:8443/2013/ >>> collection, where we should see - and do - the new couch resource listed as >>> having been created by ldp. >>> >>> $ curl -k -i -X GET --cert ../eg/test-localhost.pem:test >>> https://localhost:8443/2013/ >>> >>> HTTP/1.1 200 OK >>> Link: < >>> MailScanner has detected a possible fraud attempt from "localhost:8443" >>> claiming to be https://localhost:8443/2013/.acl>; rel= >>> acl >>> Content-Type: text/turtle >>> Content-Length: 119 >>> >>> >>> <> < >>> http://www.w3.org/ns/ldp#created> <raw/> , <card> , <test >>> /> , <couch> ; >>> a < >>> http://www.w3.org/ns/ldp#Container >>>> . >>> >>> We can find out about the ACL for this resource using HEAD (TODO: OPTIONS >>> would be better, but is not implemented yet ) >>> >>> $ curl -X HEAD -k -i --cert ../eg/test-localhost.pem:test >>> https://localhost:8443/2013/couch >>> >>> HTTP/1.1 200 OK >>> Link: < >>> MailScanner has detected a possible fraud attempt from "localhost:8443" >>> claiming to be https://localhost:8443/2013/couch.acl>; rel= >>> acl >>> Content-Type: text/turtle >>> Content-Length: 0 >>> >>> ( TODO: The Content-Length should not be 0 for HEAD. Bug in Play2.0 >>> probably ) >>> >>> So we add the couch acl which gives access to that information in addition >>> to the default owner of the collection, to two groups of people >>> >>> $ curl -X PATCH -k -i -H "Content-Type: application/sparql-update; utf-8" >>> --cert ../eg/test-localhost.pem:test --data-binary @../eg/couch.acl.patch >>> MailScanner has detected a possible fraud attempt from "localhost:8443" >>> claiming to be https://localhost:8443/2013/couch.acl >>> >>> HTTP/1.1 200 OK >>> Content-Type: text/plain; >>> charset= >>> utf-8 >>> Content-Length: 9 >>> >>> Succeeded >>> >>> This makes it available to the test user and the members of the WebID and >>> OuiShare groups. If you have a WebID then try adding yours and test it. You >>> can also request different formats by changing theAccept: header such as >>> with the following request for RDF/XML >>> >>> $ curl -k -i -X GET -H "Accept: application/rdf+xml" --cert >>> ../eg/test-localhost.pem:test https://localhost:8443/2013/couch >>> or if you prefer rdf/xml over turtle as described by the Content >>> Negotiation section of the HTTP1.1 spec: >>> >>> $ curl -k -i -X GET -H "Accept:application/rdf+xml;q=0.9,text/turtle;q=0.7" >>> --cert ../eg/test-localhost.pem:test https://localhost:8443/2013/couch >>> It is then possible to also use SPARQL queries on particular resources. >>> (TODO: find a better example) >>> >>> $ >>> cat ../eg/couch.sparql >>> PREFIX gr: < >>> http://purl.org/goodrelations/v1# >>>> >>> SELECT ?D >>> WHERE >>> { >>> >>> >>> [] a <http://bblfish.net/2013/05/10/couch#Surf >>>> ; >>> gr:description ?D . >>> >>> } >>> >>> >>> >>> $ curl -X POST -k -i -H "Content-Type: application/sparql-query; >>> charset=UTF-8" --cert ../eg/test-localhost.pem:test --data-binary >>> @../eg/couch.sparql https://localhost:8443/2013/couch >>> >>> HTTP/1.1 200 OK >>> Content-Type: application/sparql-results+xml >>> Content-Length: 337 >>> >>> <?xml >>> version='1.0' encoding='UTF-8' >>> ?> >>> <sparql >>> xmlns='http://www.w3.org/2005/sparql-results#' >>>> >>> <head> >>> <variable >>> name='D' >>> /> >>> </head> >>> <results> >>> <result> >>> <binding >>> name='D' >>>> >>> <literal >>> datatype='http://www.w3.org/2001/XMLSchema#string' >>>> Comfortable couch in Artist Stables</literal> >>> </binding> >>> </result> >>> </results> >>> </sparql> >>> >>> >>> Finally if you no longer want the couch surfing opportunity to be published >>> you can DELETE it. ( It would be better to express that it was sold: >>> DELETEing resources on the Web is usually bad practice: it breaks the links >>> that other people set up to your services ) >>> >>> curl -k -i -X DELETE -H "Accept: text/turtle" --cert >>> ../eg/test-localhost.pem:test https://localhost:8443/2013/couch >>> >>> HTTP/1.1 200 OK >>> Content-Length: 0 >>> >>> And so the resource no longer is listed in the LDPC >>> >>> $ curl -k -i -X GET --cert ../eg/test-localhost.pem:test >>> https://localhost:8443/2013/ >>> >>> HTTP/1.1 200 OK >>> Link: < >>> MailScanner has detected a possible fraud attempt from "localhost:8443" >>> claiming to be https://localhost:8443/2013/.acl>; rel= >>> acl >>> Content-Type: text/turtle >>> Content-Length: 109 >>> >>> >>> <> a < >>> http://www.w3.org/ns/ldp#Container >>>> ; >>> < >>> http://www.w3.org/ns/ldp#created> <card> , <raw/> , <test >>> /> . >>> >>> To create a new container one just creates an LDP Resource that contains >>> the triple<> a ldp:Container. >>> >>> $ >>> cat ../eg/newContainer.ttl >>> @prefix ldp: < >>> http://www.w3.org/ns/ldp# >>>> . >>> @prefix foaf: < >>> http://xmlns.com/foaf/0.1/ >>>> . >>> >>> <> a ldp:Container; >>> foaf:topic >>> "A container for some type X of resources" >>> ; >>> foaf:maker <../card#me> . >>> >>> >>> $ curl -X POST -k -i -H "Content-Type: text/turtle; utf-8" --cert >>> ../eg/test-localhost.pem:test -H "Slug: XDir" -d @../eg/newContainer.ttl >>> https://localhost:8443/2013/ >>> >>> HTTP/1.1 201 Created >>> Location: >>> https://localhost:8443/2013/XDir/ >>> >>> Content-Length: 0 >>> >>> Note that directories can only be deleted if all ldp:created resources were >>> previously deleted. >>> >>> Creating a WebID Certificate >>> >>> After starting your server you can point your browser to >>> http://localhost:9000/srv/certgen or to the service over https and create >>> yourself a certificate. For testing purposes and in order to be able to >>> work without the need for network connectivity use >>> `http://localhost:8443/2013/cert#me'. The WebID Certificate will be signed >>> by the agent with Distinguished Name "CN=WebID,O=∅" and added by your >>> browser to its keychain. >>> >>> ( Todo: later we will add functionality to add create a local webid that >>> also published the RDF ) To make the WebID valid you will need to publish >>> the relavant rdf at that document location as explained in the WebID spec >>> >> > > Social Web Architect > http://bblfish.net/ >
