Imported Google Group message.
Date:Wednesday, 20 August 2014 18:26:25 UTC+1.
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.