[Openid-specs-ab] Relying Party libraries
Mike Schwartz
mike at gluu.org
Fri Sep 15 16:47:18 UTC 2017
George,
I agree 100% with your findings. I don't know if you saw my slides from
CIS, but I posted them online:
http://gluu.co/client-is-not-always-right
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
Gluu
Founder / CEO
mike at gluu.org
https://www.linkedin.com/in/nynymike/
More information about the Openid-specs-ab
mailing list