Imported Google Group message.
Date:Tuesday, 2 September 2014 09:17:59 UTC+1.
Thanks for the interest
You're partially right in how Tyk assigns access rights, access rights (permissions) are essentially provided at the key level, so when a key comes into Tyk via a request, Tyk will route the request to the appropriate API depending on the request path, then once it has identified the API, will check if the key (if it exists) has an access_rights entry for that particular API version.
With regards to your question though, with the current version of Tyk (1.1), there is no third-party identity provider support, however in the current master branch development version, there is the capability of adding new identity providers and session providers. In other words, the code is extensible enough now to allow varying providers to be provided so long as they can provide the data that Tyk needs to track the appropriate key.
With regards to role and group management, it was considered to put this in, in order to mass-assign access-rights to keys (and it should be trivial to do), however we opted instead to leave group and roll assignment to the integrator as we didn't want to depend too much on external data sources to provide these rules. There is an argument for using a configuration file to do this (for stand-alone installs) and then extrapolate that to MongoDB (the same way that API Definitions are set up).
I'll put it on the roadmap so we don't lose track of the request.
Finally, with regards to modifying the outbound request, at the moment there is no post-processor for the outbound request, though it is very easy to build middleware for Tyk (simply implement the TykMiddlewareProvider interface), and since the request is passed through each layer of the midleware it would just be a matter of creating it and adding to the request chain. Currently this would need to be hard-coded into the chain in loadApps(), though we are looking into ways to make this more dynamic (as in have pre-built modules that can then be add into the chain as configuration parameters - shouldn't be hard). However it is more than possible if you fancy building from source
I would agree that an ESB would serve this purpose better as the various mime type handlers could inject data more effectively than just appending to a request paramater list (e.g. XML bodies or JSON bodies, transforming the object i well beyond the scope of something like Tyk).
Either way, two interesting things that need to be considered for the roadmap:
The ability to runtime-load middleware into the chain
Some kind of roll and group management via configuration file, this could override atomic values store in the key session data itself.
Hope that answers your question