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.