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

peter williams home_pw at msn.com
Wed Mar 2 02:12:29 CET 2011


Compared to the last time I looked at all this (12 months ago), its all a
lot more cert friendly.

 

If a million folks are tenants, remember that each can now do the uploading
of the webapps by authenticating to the hosting portal via client authn,
with client cert (that one registers upfront,  in the admins "profile").

 

When I look at the setup, it seems that on the dev server for azure, one is
connecting over https to an SSL MITM (the emulator itself), that in turn
makes a non SSL connection to the IIS 7 server on the host. This is why one
cannot see the client cert (or configure it) - it aint there.

 

Ill guess in the real azure cloud, its the same : with the fabric's load
balancer acting as the ssl endpoint on behalf of the tenant's cluster.
(That's what Id do.). So, it may not be possible today to have an
azure-hosted webapp invoke and receive https client authn. For that, one may
have to upload a Window VM, with a good old native webapp in IIS - which
talks directly to the  browser directly. (But, the firewall is going to
proxy that VM's SSL endpoint too, surely, thus also denying client authn!)

 

Anyways, something to find out.

 

From: Kingsley Idehen [mailto:kidehen at openlinksw.com] 
Sent: Tuesday, March 01, 2011 2:53 PM
To: peter williams
Cc: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] msft azure endpoint certs, including
self-signed support

 

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
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/6e6a836d/attachment.htm 


More information about the foaf-protocols mailing list