[foaf-protocols] msft azure endpoint certs, including self-signed support

Kingsley Idehen kidehen at openlinksw.com
Tue Mar 1 23:53:00 CET 2011


On 3/1/11 5:48 PM, peter williams wrote:
>
> Yes. The ODATA service in their data mart is excellent -- being 
> essentially the same think with linq as we in realty do with something 
> calls rets. But, obviously their query model is a wee bit more 
> powerful, and has full metadata, full caching, full everthing. Also, 
> it has a provisioning model (and pricing, selection...)
>
> Being ODATA over https, it can take a client cert....
>
> Ive no doubt the odata server-side interceptor exists, and can be made 
> to ping your sparql server.
>

We've had OData cartridges (drives, providers, transformers) since 
inception :-) Only gripe is OData is weak on the metadata side (leaky 
abstraction due to lock-in tendencies of MSFT). They're gradually 
sorting this out.

> Don't believe it would even need MSFT engineers. Feels like an 
> authorization attribute on the dispatcher  class..., invoking the 
> claims authorization class that insists in the sparql call.
>

Yes, this issue is only a hurdle due to its platform agnosticism. 
Trouble is, that is still instinctive heresy at MSFT :-(


Kingsley
>
> *From:*foaf-protocols-bounces at lists.foaf-project.org 
> [mailto:foaf-protocols-bounces at lists.foaf-project.org] *On Behalf Of 
> *Kingsley Idehen
> *Sent:* Tuesday, March 01, 2011 2:31 PM
> *To:* foaf-protocols at lists.foaf-project.org
> *Subject:* Re: [foaf-protocols] msft azure endpoint certs, including 
> self-signed support
>
> On 3/1/11 3:35 PM, Peter Williams wrote:
>
> excellent "how to" article
>
> http://azurefeeds.com/post/906/Installing_Certificates_in_Windows_Azure_VMs.aspx
>
> one could have a million tenants with self-signed https endpoints,  if 
> one wants. One just uploads the .p12 file...
>
> well done microsoft.
>
> this article hints at but doesnt go into details that the azure 
> tenants has multiple cert stores (think tagged lists of cert:identity 
> in the foaf card) - some of which impact how client certs are addressed.
>
> This is actually my mission - to get the azure endpoint to request and 
> consume a (self-signed) client cert via client authn. One can probably 
> guess why...
>
>   
>   
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org  <mailto:foaf-protocols at lists.foaf-project.org>
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>
> Microsoft groks the Data as a Service (DaaS) model as demonstrated via 
> Azure! Only issue is now,  is getting them to grok the power of WebID 
> which is a zero cost it -- bar platform lock-in obsession -- when it 
> comes to enhancing their DaaS offerings esp. the Data Market.
>
> WebIDs render API keys obsolete too!
>
>
> -- 
>   
> Regards,
>   
> Kingsley Idehen
> President&  CEO
> OpenLink Software
> Web:http://www.openlinksw.com
> Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter/Identi.ca: kidehen
>   
>   
>   
>   


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110301/f471fec9/attachment-0001.htm 


More information about the foaf-protocols mailing list