[Openid-specs-ab] Relying Party libraries

Mike Schwartz mike at gluu.org
Fri Sep 15 16:47:18 UTC 2017


I agree 100% with your findings. I don't know if you saw my slides from 
CIS, but I posted them online:

A proxy approach doesn't really work that well because there are both 
front channel and back-channel calls. Gluu has developed middleware 
called "oxd" which is more like a mediator:
   1. For front channel calls, it returns the url to the client (but 
keeps the state in the cache)
   2. For back channel calls, it just does the work, and returns results

This has enabled us to keep the core code in Java, but to write lots of 
libraries that are used by the clients: java, python, php, ruby, c#, go, 
node, and perl.

The first version of oxd ran on localhost (sort of like shibd). But 
we're introducing a network version that uses an OAuth token obtained 
using the client credential grant.

Also, I should mention that this code is licensed (not open source, like 
most of Gluu's stuff). oxd also provides API's for both UMA client and 
resource servers.

Anyway, net-net, I think you're exactly right--the client software 
situation is a mess. Developers just want to get stuff working, and they 
don't use many of the security features to mitigate the known risks.  
And if developers grab code off Github, it becomes hard for the 
enterprise to keep it up-to-date. oxd is delivered as packages, so it 
updates with apt/yum updates.

We have not yet certified oxd... we've been too busy. At some point we 
want to do it. But right now, our customers don't seem to care (another 
indication of the problem...).

BTW, oxd homepage is: http://oxd.gluu.org

- Mike

Michael Schwartz
Founder / CEO
mike at gluu.org

More information about the Openid-specs-ab mailing list