Re: {Disarmed} RWW-Play was: Simple WebID, WebID+TLS Protocol, and ACL Dogfood Demo

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 :-)

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 <henry.story@bblfish.net>
 wrote:

> 
> On 9 Aug 2013, at 18:55, Hugh Glaser <hg@ecs.soton.ac.uk> 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
>

Received on Friday, 9 August 2013 17:36:02 UTC