RFC: The future Identity Providers
Jorge Vargas
of them refer to the providers.
This is the only part that is not fully customizable of TG and
therefore need some work. I'll like to hear comments on the
possibilities and if someone is willing to work on it too.
Right now there are two possible solutions.
1- Implement identity providers based on RuleDispacher and peak
security you can find this at ticket #313
2- Implement identity providers as a set of subclasses.
#1 is basically how json works right now, for those of you that don't
know it RuleDispatcher is basically calling different methods based on
the type of more then one object.
the rules will probably be added as a package in each project where
you could add rules, and we'll have some kind of repository of rules
as "recipies".
And of course the most basic rules will be provided with TG.
A couple of months ago I was working on #2 a bit on this although I
never made the changes public. Basically what I had was moving most of
the code from soprovider and saprovider to the same provider class,
and then subclass from there. if someone needed a LDAP provider it
will subclass provider if someone just needed to change the password
source he/she will subclass soprovider,etc. then we'll have an entry
on the config files that will point to the provider class to be used.
This was before sa 0.2 so in order to get this up to date probably my
saprovider.py should have to be rewritten.
This will probably be implemented as having the default classes inside
TG, and then people creating tg-addons that will either plugin
providers (like widgets do) or people will provide howto's on the wiki
with examples from which people can build up.
---------------
The most common cases of aditional providers I have seen are:
- changing the password method. (other source, other encryption)
- using a third party auth. (LDAP, SSO)
---------------
Please comment on the pro's and con's of each method
Kevin Dangoor
> Right now there are two possible solutions.
>
> 1- Implement identity providers based on RuleDispacher and peak
> security you can find this at ticket #313
> 2- Implement identity providers as a set of subclasses.
Actually, there are a couple more.
3. Use Alberto's TurboPeakSecurity (somehow mushed in with our
identity APIs for backwards compatibility) (which is similar in idea
to #313)
4. Use a WSGI auth provider
I don't want to get too much into implementation details on this list
(those belong on the trunk list), but this is a fine place to discuss
the needs.
The biggest need I see is that we need to disambiguate the
authentication and authorization. They are two separate tasks that
would likely need different plugins.
The ideal would probably be some hybrid approach... starting with a
WSGI provider, but possibly making an authorization plugin that uses
RuleDispatch.
As always, I'm looking to leverage as much good stuff that's out
there as we can. I know that James Gardner has something up his
sleeve, but he mentioned that it's not ready for a big audience yet.
Kevin