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

Kingsley Idehen kidehen at openlinksw.com
Thu Mar 3 22:14:36 CET 2011


On 3/3/11 3:34 PM, peter williams wrote:
>
> 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...).
>
Yes, or simply via virtual graph traversal simply find the public key 
that matches the handshake public key. This is where lots of fun and 
games can happen via courtesy of reasoning and co-reference. As all 
WebID ACLs tests seemed to have stalled, I've put a lot of these demos 
on the back-burner.

Basically, "You" have control of where that public key resides in the 
graph, you can even control addition of pings to other spaces via OAuth. 
Even opt to hide public key in a place only accessible via OAuth :-) The 
great thing is that a SPARQL query endows the whole public key lookup 
with immense sophistication.
>
> Perhaps the entire fabrikamshipping demo (how to do websso-based SAAS 
> in the cloud) could be made webid aware. Why not?
>

Why not? I'd even have that done now as a WebID showcase if I could 
prioritize it or be commercially induced :-)

> 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?
>
It shouldn't .

> 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.
>

Yep!

Kingsley
>
> *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> 
> [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 
> <mailto: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  <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/98ddcc02/attachment-0001.htm 


More information about the foaf-protocols mailing list