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

peter williams home_pw at msn.com
Thu Mar 3 21:34:34 CET 2011


Take a look at the related to code in http://www.fabrikamshipping.com/

 

It all best practice type code. Some if its boot tools are more interesting
than the showcase code though. 

 

1.       There is a selfSTS project, that mints certs. Its all a window that
sits there being a server, acting as an IDP. It's fundamentally a wrapper
around std command line tools in windows-land that make (self-signed) certs,
.p12 files etc - using tools in the std windows programmer SDK tool chain. 

2.       How to secure ODATA using sso flows and interceptors in the server.

 

Now that IDP is a bridge  - that delegates to an upstream bridge in the
Azure cloud (ACS) - that turns out to be a further bridge to the usual IDP
suspects, including google, facebook, yahoo etc. (But not openid in
wordpress; peter sobbing.).

 

Its already use to authorize the ODATA, where odata has the enforcement
point but the decision point is punted to that first IDP (that then talks
upstream.)

 

Seems no reason why it cannot ping a sparql server, since its in the middle
of the chain (and it's the last signoff entity.).

 

Perhaps the entire fabrikamshipping demo (how to do websso-based SAAS in the
cloud) could be made webid aware. Why not? After all, they have centralized
the enforcement point, implemented it in a window IDP, which can be changed
to ping your sparql server for a SAN URI in the cert!

 

Of course, its not https and client certs. Its client certs supporting
signed websso messages. But does webid care? Surely what matters is that
foaf and the deferencing process is what controls validity, and then foaf
groups, foaf following get to impact the authorization logic.

 

 

 

 

 

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/20110303/bcb6e7f1/attachment-0001.htm 


More information about the foaf-protocols mailing list