Kerberos using AuthKit, repoze.who or something else
postlogic
I'm in the process of porting our internal website to Pylons, and so
far in planning and researching we've come across only one problem. We
are required to use kerberos for authentication to the administration
interface.
I haven't seen any posts regarding this, really. Been trying to search
for hints about using .htpasswd for this also. Has anyone had any luck
doing this? I'm hoping for some solution using AuthKit or repoze.who,
if they have support for requiring a specific group through kerberos
using a .htpasswd file. Any of you guys know of atleast anywhere I
could look to get more information? I've found the CAS-plugin for
repoze.who, but it doesn't seem to be neither updated nor mature
enough yet.
Thanks in advance!
Aurynn Shaw
Hiya;
While I don't have direct experience working with a Kerberos
authentication backing, writing a repoze.who authentication plugin is
pretty trivial.
The key components are the Challenger, Identifier and Metadata Provider.
The flow is, the Identifier tests for the user credentials (can look in
the HTTP environment, as well as cookies), and if the user is not logged
in, passes to the Challenger. The Challenger requests credentials (a 401
Not Authorized), as you'd expect.
Finally, if the user is logged in, the Metadata Provider runs, which
pulls the user object out of storage, if you like. This can be as simple
or complex as necessary.
My solution (as recommended on the irc.freenode.net #repoze channel) is
to use a simple redirecting challenger to an unprotected Pylons route
(handling the login), and the stock auth_tkt Identifier to handle cookie
lookups.
Authentication is handled via PostgreSQL, in our case - this is done so
we can use the PGSQL roles and role trees in our Pylons application.
Also, since the Challenger is expected to be a WSGI-compatible
application, you can do a fairly complex authentication scheme - or,
since you're already interested in using .htpasswd, a very simple
Identifier test for HTTP_AUTHORIZATION, and a simple Challenger which
returns 401 Not Authorized directly would work very well - especially as
http://modauthkerb.sourceforge.net/ indicates that you'll be able to
directly authenticate against Kerberos from Apache.
You can have a look at the simple repoze.who stuff we put together @
https://public.commandprompt.com/projects/verticallychallenged/repository
It's pretty simplistic, and needs some bugfixes, but gets across the
basic idea.
Hope that helps,
Regards,
--
Aurynn Shaw
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 103
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
We are all in the gutter, but some of us are looking at the stars.
-- Oscar Wilde
postlogic
>
> It's pretty simplistic, and needs some bugfixes, but gets across the
> basic idea.
>
> Hope that helps,
>
> Regards,
> --
> Aurynn Shaw
>
> The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 103
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> We are all in the gutter, but some of us are looking at the stars.
> -- Oscar Wilde
>
> as...@commandprompt.com
just a clarification.. I meant htaccess, not htpasswd file, sorry.
The htaccess file is something along the lines of this:
AuthType Kerberos
AuthName "Administration"
require netgroup site_admins
Pretty simple. Will this require something other than what you
suggested?
Gustavo Narea
Just a small clarification:
On Jul 16, 9:34 pm, Aurynn Shaw <as...@commandprompt.com> wrote:
> The flow is, the Identifier tests for the user credentials (can look in
> the HTTP environment, as well as cookies), and if the user is not logged
> in, passes to the Challenger. The Challenger requests credentials (a 401
> Not Authorized), as you'd expect.
current request, nothing happens; the WSGI application will work as
usual. The challenger only comes into play when so is requested by the
WSGI application (the identifier has no influence); by default it
happens when the application itself returns 401.
Or in a graphical way, this is what happens before your application
receives the request:
http://gustavonarea.net/uploads/Figure2.png
And this is what happens after your application returns a response:
http://gustavonarea.net/uploads/Figure3.png
- Gustavo. :)