[foaf-protocols] Thoughts on Securing Linked Data with OAuth and FOAF+SSL
Story Henry
henry.story at bblfish.net
Sat Jan 23 23:30:46 CET 2010
On 22 Jan 2010, at 18:06, Peter Williams wrote:
> I'd be quite happy with a RESTUL API wrapping a SPARQL client, and just
> implementing the R in a CRUD API - leveraging the .NET Data services
> framework, if appropriate.
>
> We know that an "extension" to FOAF+SSL handling of the client-cert
> assertion and association FOAF document calls for the relying party to issue
> a sparql query, whose target server (in the RP's domain) interacts with the
> IDP's sparql server (in the IDPs domain...).
I suppose you mean something at step 6 in the original diagram posted here
http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to
In the example there Juliet's server was crawling her foaf file - ie GETing each of her friends foaf, perhaps not all at once but on a regular basis - and then merging that, or some subset of that, into a graph G. Juliet's server can then query G to see if Romeo knows any of her friends.
> This exists to help the RP _decide_ - whether or not it "trusts" the inbound pubkey from the cert.
If it is step 6 that you are thinking of, then its role is to decide whether the RP (Juliet's hyperdata server) trusts the foaf:Agent identified by the WebID (ie, Romeo) to access the resource requested. It is important to see that trust is relative to the question being asked, ie to the authorisation part.
Two things then:
a. one trusts people, not keys because of some skills they have
b. trust is relative to the resource that is being accessed
One trusts one's a babysitter to look after one's children .
One trusts a hairdresser to cut one's hair;
a dentists to drill one's teeth;
a friend not to divulge a secret;
a colleague to give constructive criticism ....
In resource oriented terms we can say that the request to access (GET, PUT, DELETE) a resource, or create a new one (POST) will be granted depending on the server's assessment of the requestor's ability to act responsibly. This is usually based on some properties the resource owner believed to be true of the requestor.
One could therefore use description logic, to describe a class of agents allowed access to a resource. This could be done like this:
:JulietFriends a owl:Class;
owl:equivalentClass [ a owl:Restriction;
owl:onProperty [ owl:inverseProperty foaf:knows ];
owl:hasValue :juliet ] .
foaf:foaf a owl:Class;
owl:propertyChainAxiom ( foaf:knows foaf:knows );
:JulietFOAF a owl:Class;
owl:equivalentClass [ a owl:Restriction;
owl:onProperty [ owl:inverseProperty foaf:foaf ];
owl:hasValue :juliet ] .
:TrackablePeople a owl:Class;
owl:unionOf ( :JulietFriends :JulietFOAF ) .
So the :TrackablePeople are those who we can find some way of contacting through people we know. One can see how if all one cares about is to avoid spammers, or diffusing material too widely, then this can be a good enough reason to give some people access to low risk resources.
That also shows btw, how SPARQL is not necessary to work out an authorisation group.
> This
> "social network" membership test is distinct from foaf+ssl itself, whose
> earlier interceptors have already done
> SLScrypto/cert-expiry/FOAFdocument<webid> level verification.
yes, that is what the previous stages 3, 4, and 5 were about.
> In my simplistic implementation today of the inceptors for a FOAF+SSL
> server, its earlier interceptor confirms that the asserting parties foaf
> document indeed (1) publishes the pubkey from client cert asserted via ssl
> client auth, and (2) the FOAF document tags it with webid learned from the
> client cert, also.
You get authentication.
> But I don't confirm that the very same pubkey is "trusted" by the server.
I would rather we think more semantically, about the Agent being trusted, as I detailed above.
> That is, I don't do the sparql part above. This is the job of the next interceptor injected into the FOAF-SSL server instance.
ok
> What are we doing in that "sparql process" re pukeys? other than using it
> test to certain membership conditions testing for a "peer" cert store? Isn't
> the peer cert store just a special wot/cert ontology relation, called "peer
> trust"?
Are you speaking now of the SPARQL process in step (6)? Let me assume you are....
In the example of giving foaf access to R we are using trusted linked data to work out information on what people to give access to our data.
>
> IN the WPF world today, what happens? A server takes its own identity,
> obtains from the local TCB a (windows) security token (now named as a SPN,
> with certain kerberos delegation capabilities in the token) and uses the
> Win32 local cert store API to test some peer's cert for membership in that
> cert store, known as the "peer" cert store.
I understand very little of the above. Too many acronyms. WPF, TCB, SPN ?
But it looks like a lot of what you are describing is in terms of certs. I think it is better to speak in terms of the Agents, which is what is concerning us at that point. After all we have passed the authentication stage (finished in (5), so we no longer need the certs anymore. We have confirmed the identity. What interests us now is whether that requestor is a member of the set of agents that is allowed access to the given resource.
In the case above:
ASK { requestorWebId a :TrackablePeople . }
(( And I think one can do even that without SPARQL....))
> That is, the store provider performs some kind of a set membership test, in the underlying relationship set.
That seems to be indeed what the ASK query is doing above.
> How the API implements that test is hidden from the WPF/IIS security interceptors. Typically, though, the Kerberos tickets are used with the AD server to let the API provider have access to several directory group - as ldap/AD resolvers work up the user's and the user's schema's entries from the director... and then calculate the require membership rule.
> There is no reason why we cannot write a cert store provider (for
> "peer"-class trust stores") in both java and windows). They can implements
> certain sparql queries and protocols runs - replacing all the ldaps
> resolvers.
That ldap replacement bit sounds right.
> As that process is having the RPs SPARQL server cooperate with the IDP's
> SPARQL server (much like an RP X500-DSA might chain SIGNED queries to the
> IDP's x500 DSA in X.500 land), it might also be leveraged to be the
> "artifact" resolver. So, the layer needs to (a) implement distributed cert
> stores, and (b) recover FOAF documents given webid from WHEREVER the
> sparql-based agents collectively decide.
But I don't see why it needs to be replaced by a SPARQL query. As I showed above one can very reasonably create a store by fetching foaf files RESTfully. That can then be queried with SPARQL....
Of course that job could be externalised and given to some other authority that would ask if an agent is part of a group. So perhaps it would be possible to ask if a WebId is part of the group Staff to some SPARQL server somwhere...
ASK { requestorWebId a mit:Staff . }
but presumably the mit:Staff relation is a RESTfully resolvable URL. It could list all the Staff members (and point to a SPARQL endpoint for people who don't wish to cache that perhaps very large representation -- though only in a few companies would that be the case)
> But, we must distinguish the two functions of a common inter-SPARQLserver
> handoff: (1) get the triples in the FOAF document (to test the basic
> FOAF+SSL security theorem about who controls the foaf file, given the SSL
> private key usage), from
yes, that is the authentication piece
> (2): is that pubkey is the server's "peer" trust
> store (where a SPARQL server answers that question autho
> ritively for the RP's identity).
So here my point in the above was that we need to think in terms of what trusted sources of information we should use to get the attributes necessary to decide if the agent is member of the group of resources that can have access to the requested resource.
This is I think what is known as Attribute Based Access Control. But here we are doing it in a declarative way with distributed data.
> Obviously, a simplistic implementation of all the above is to test if the
> pubkey exists in the FOAF file of the server.
You mean Romeo's public key published at his WebID?
> But, this does allow for trust
> engineering - where the inter-sparql server interaction implements lots of
> *different* "trust resolvers" for lots of different trust relationships that
> one might specify.
I think it would help to think a lot more declaratively. The talk of resolvers seems mysterious to me, and even more so talk of trust resolvers. What we really have is:
1. information on the web that is more or less trusted
2. Merges of the above information, and the resulting trust one has in the merged data
3. Agents that are trusted to do certain actions
4. knowledge of what kind of properties agents must have to be trusted to do certain actions
> If we do this, we have what AD does, in support all the
> different trust relations it supports (forest trust, inter-forest trust,
> ....)
Any links to these types of trust?
Henry
>
> -----Original Message-----
> From: Kingsley Idehen [mailto:kidehen at openlinksw.com]
> Sent: Friday, January 22, 2010 5:05 AM
> To: Peter Williams
> Cc: foaf-protocols at lists.foaf-project.org
> Subject: Re: [foaf-protocols] Thoughts on Securing Linked Data with OAuth
> and FOAF+SSL
>
> [SNIP]
>>
>> Today, one can do
>> http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCF.aspx.
> it
>> shows you (one way) how to store client certs from Ssl handshakes or SOAP
>> headers in the servers "peer trust" store, managed *per* service identity.
>>
>> If one builds a cert store using a foaf document, rather than the windows
>> registry or the SPN's directory entry, you can use a foaf document as the
>> store. The API doesn't care about the representation of the store concept,
>> by design. From what I recall, the java store provider has the same model
>>
> (http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/CertStore.html)
>>
>> I keep hoping someone will write sparql queries that allow a sparql
>> repository to act as a cert store.... using the foaf tags as
> appropriate...
>>
>
> I don't know what you mean by:
> "someone will write sparql queries that allow a sparql repository to act
> as a cert store.... using the foaf tags as appropriate.."
>
> Are you talking about using SPARQL for CRUD re. HTTP aware data space
> that stores and exposes Certs?
>
> Kingsley
>> ----
>>
>>
>>> From 1999
>>
>> Client Certificates
>> Applies to IIS 4.0 and 5.0
>> Feature name change in IIS 5.0
>>
>> Description
>> Client certificates can be used to securely authenticate users and to
> give
>> them access to resources automatically using client certificate mapping.
>>
>>
>> Requirements
>> Client: Each client browser must have a copy of the client certificate
> and
>> its private key. Not all browsers are certificate-compatible.
>> Server: A server certificate. Enabling and configuring client certificate
>> mapping. A copy of every client certificate used in Basic mapping. The
> root
>> certificate of every CA issuing client certificates being used.
>>
>>
>> Typical Uses
>> Secure authentication and access to sensitive information on an
> individual
>> basis, such as an corporate intranet on which company secrets are held.
>> Secure authentication of users of Internet sites, such as member-only
> sites.
>> See Basic mapping. DS mapping could also be used for these scenarios on a
>> Windows 2000 domain.
>> Semi-secure authentication and access to semi-secure data, such as a large
>> corporate intranet where many client certificates would be needed, making
>> mapping management difficult. See Advanced mapping.
>>
>>
>> How To Set Up
>> 1. Each client must obtain a client certificate.
>> 2. The server must have a copy of these client certificates.
>> 3. A server certificate must be installed on the appropriate Web site.
>> 4. To have your server require client certificates, set Require Secure
>> Channel when accessing this resource (Require secure channel (SSL) in IIS
>> 5.0) and Require Client Certificates. This will both require the use of a
>> client certificate and encrypt the data being transferred.
>> 5. To have your server allow client certificates to be used, but not
> require
>> them, set Accept Client Certificates. It is not necessary to set Require
>> Client Certificates.
>> 6. Instruct clients to use the HTTPS URL format.
>> To set up client certificate mapping:
>> 1. Obtain copies of the client certificates if using Basic mapping (this
> is
>> not necessary with Advanced or Directory Service mapping).
>> 2. Enable Client Certificate Mapping on the Secure Communications dialog
>> box.
>> 3. Click Edit.
>> 4. Choose the appropriate method.
>>
>> http://technet.microsoft.com/en-us/library/bb727081.aspx
>>
>> IIS 4.0 and 5.0 Authentication Methods Chart
>> By Jim Morey, Web Technology Writer
>>
>>
>> Internet Information Services Documentation Team
>> Microsoft Corporation
>>
>> July 19, 1999
>>
>>
>> Notes
>> There are three possibilities when using client certificates:
>> 1. Do not accept Client Certificates (Ignore client certificates in IIS
> 5.0)
>> means that if a client certificate is sent by the browser, it will be
>> ignored and the request will be authenticated in another way.
>> 2. Accept Client Certificates means that if a client certificate is sent
> by
>> the browser, the request will use the client certificate to authenticate.
> If
>> a client certificate is not sent, the request will be authenticated in
>> another way.
>> 3. Require Client Certificates means that the request will not be
> accepted,
>> unless a client certificate is sent by the browser and that any data sent
>> will be SSL encrypted.
>> There are three types of client certificate mapping:
>> 1. Basic (One-to-one in IIS 5.0)-one certificate mapped to one user
> account;
>> requires a copy of the certificate. Absolutely secure.
>> 2. Advanced (Many-to-one in IIS 5.0)-many certificates mapped to a single
>> account or many accounts; does not require a copy of the certificate.
>> Reasonably secure.
>> 3. Directory Services (DS) (IIS 5.0 only)- Windows 2000 Active Directory
>> features to authenticate users with client certificates.
>> When active: This authentication method will become active even if
> Anonymous
>> authentication is enabled, if either Require Client Certificates or Allow
>> Client Certificates is used.
>>
>>
>>
>>
>> -----Original Message-----
>> From: foaf-protocols-bounces at lists.foaf-project.org
>> [mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Story
>> Henry
>> Sent: Wednesday, January 20, 2010 5:27 PM
>> To: foaf-protocols at lists.foaf-project.org
>> Subject: [foaf-protocols] Thoughts on Securing Linked Data with OAuth and
>> FOAF+SSL
>>
>> Just thought I'd point to a post by John Erickson entitled "Thoughts on
>> Securing Linked Data with OAuth and FOAF+SSL".
>>
>>
> http://bitwacker.wordpress.com/2010/01/20/thoughts-on-securing-linked-data-w
>> ith-oauth-and-foafssl/#
>>
>> Policy awareness and foaf+ssl sounds like a very good idea...
>>
>> Henry
>>
>> PS. Still at cconf in London. Will be in Germany next week at
>> http://www.dagstuhl.de/10041
>> Hopefully I'll have more time after that.
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>
>>
>
>
> --
>
>
> Regards,
>
> Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
> President & CEO
> OpenLink Software Web: http://www.openlinksw.com
>
>
>
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
More information about the foaf-protocols
mailing list