On 04/06/2011 01:14 PM, Scott Henson wrote:
On Tue, 5 Apr 2011 21:28:50 -0500, James Cammarata <jimi@sngx.net> wrote:
In my environment we have to use smartcards for authentication. The
effect on the server side is that an SSL client certificate is
presented. Our (HTTPS only) servers must require this as part of the
SSL/TLS handshake, so if an HTTP connection happens and a web app is
summoned to reply with a page, the user is authenticated already, it's
just a question of what they're authorized to do in Cobbler.

A successful authentication system based on our requirements should be
dead easy to make - a dozen lines of Python or so - but it's essentially
a third thing which isn't quite basic auth nor form-based login, and it
may not legitimately be Cobbler's problem.
I think this is where we should be headed. However, we don't make use of
WSGI or any of the python frameworks in meaningful ways. Right now we
kind of use Django, but not completely enough to take advantage of where
it gets stuff right.

Part of the problem is that cobbler-web depends on cobbler's view of
authentication and authorization. Cobbler's view of that is a bit bare
bones. To do this right we would have to drive authentication deep into
cobbler or somehow pull it out of cobbler completely and only have it on
the cobbler-web level. I'm not entirely sure what the proper direction
is.
I guess if you wanted to get technical about things, you could write a
proper backend for Django to handle the auth - that seems like
overkill to me though.

For the problem posted above, it almost seems like it should be
something the browser handles (sort of like forwarded krb5
credentials), and I do see why keeping some kind of basic or digest
auth would be required in that situation.
Well, we do have httpd in front of connections for both xmlrpc and the
WUI. So we could easily punt on this completely to httpd/django. Not
entirely sure how to tell cobblerd that it is httpd connecting to it and
not a random user on localhost. I'm wondering if it wouldn't be possible
to run cobblerd inside of httpd as a wsgi process. Though doing authz
with httpd on xmlrpc is not really possible as far as I know. It also
brings up other issues of concurrency that have stopped my goal of no
longer using the SimpleXMLRPCServer. Not an easy problem to solve.

Hrm, I'm not entirely sure how to solve this problem. Anyone else have a
thought on it?

I think this would be a lot easier if we had a proper DB on the backend for cobbler.

Then the WebUI and Command line only tweak the DB, long running tasks get picked up by cobblerd querying the DB for work.

I'm sure there are other ways too, but a DB would help when you have thousands of records too. ;-)


      
_______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel