Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:01:42 +0000.
Sender:[email protected].
Date:Tuesday, 19 August 2014 22:40:11 UTC+1.
Hi,
The tyk project is very exciting to us because we are currently using a heavy, bloated APIM system that has been very difficult to customize/patch/integrate and seems to be failing to scale under load. It has been nearly impossible to collaborate on bug fixes and new features due to lack of transparency and “openness” in the project development process.
We have a need to support multiple identity providers for our platform; currently, this includes LDAP, AD, and custom JDBC-based stores. Typically, there is one IdP per tenant (or “organization” in tyk parlance), but sometimes there are more. I was curious if adding adapters for these user stores was in the tyk roadmap, or even of general interest?
Secondly, we have the need to support all 4 flows in the OAuth2 spec including password and client credentials flow. If I am not mistaken, the tyk OAuth server currently only supports authorization and implicit flows. Would there be any interest in adding additional flows to the included OAuth server?
Thanks,
Joe
Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 20 August 2014 09:55:09 UTC+1.
Hi Joe,
We really want the Tyk project to be as transparent as possible, we’ve got a public roadmap of proposed features and adopted features on a Trello here: Trello
The idea being that as features are suggested in this forum or from our beta users, we add them to this list and then choose which versions to adopt in future releases. Obviously if someone submits a pull request with certain features enabled then we will merge them 
With regards to adding additional identity providers to the platform, I think this is certainly possible, though could require some re-factoring of the base, currently everything is plugged into Redis, but there’s a case for factoring this out somewhat into Go interfaces so multiple identity providers can be added. I would say that a model supporting multiple IdP’s would first need to be put in place (even if there is currently only one), which would then enable more IdP adaptors to be added by interested parties, this would definetely open up development somewhat.
I’ve added a vague “Multiple IdP’s” ticket to our board and will investigate implementation as it sounds like a framework to enable this would really improve the expandability of the platform.
Regarding the other OAuth flows, the current implementation of Tyk uses the Osin library to provide OAuth services, and adding support for more flows is certainly possible so long as it is supported by the dependency, I will add this to the proposals section of our roadmap so we don’t lose track of it. There’s certainly an opportunity for someone to add this with the current code base as it is - If you want to keep an eye on things, my suggestion would be to raise a “feature” ticket on the github project so that someone (or me) can pick it up.
Thanks,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 20 August 2014 18:26:25 UTC+1.
Hi Joe,
Your post got me thinking, so there’s now a branch in the repo which offers a refactored Session and Auth management backend (refactored/idp), which can (will) be extended to make storage backends configurable too. This means:
Session state (for quotas, rate limiting etc.) and Authorization (is this key valid etc.) are separate
More storage backends can be supported (e.g. Tokyo Tyrant, Memcached, or any other DB that can be accessed)]
Since Auth is separate, and uses it’s own storage provider, it should be possible to integrate any identity provider, so long as the driver can return a true or false over whether the key is valid, and so long as the key that the auth manager uses and the session manager uses are the same
I am just thinking aloud here, and this branch is only barely tested (it passes tests, but it has meant changing how the API behaves), this branch allows different API configurations to have individual providers for Auth, Session and soon Storage.
I’m mainly thinking aloud here - apologies for the ramble… but your post did prompt me to make the codebase more flexible, so hopefully other developers will take up your cause (or you could submit a pull request, if you’re up to it).
My question now is: For, lets say, an LDAP identity provider, how does an API pull auth data out of a request? Or would it use Basic Auth, but the backend would need to swap out to using LDAP protocols instead of a Redis key? If that’s the case - we’re on our way there… watch this space.
Cheers,
Martin
Imported Google Group message.
Sender:[email protected].
Date:Wednesday, 20 August 2014 19:55:11 UTC+1.
Hi Martin,
Thanks very much for your messages! I am new to the tyk architecture but I think the separation of the session state and authorization is precisely what we needed to accomplish idp support - exactly what you point out in #3 below.
As for your question: yes, that is exactly how I was imaging it would work for APIs configured to use basic auth. For our case, we would like to have APIs configured to use OAuth, which would work very similar I think, but it would be the /token endpoint swapping the LDAP interface for the redis store. Does that seem right?
I really would love to help with this effort in whatever way possible. My main blocker right now is that I have new to Go - I currently do most of my work in Python. That is something I want to change though, as we are starting to take interest in more and more Go projects these days.
I will definitely be following the project closely and starting to dig into the source. In the meantime, please let me know if there is any way I can help.
Best,
Joe