7

The scenario:

  • An enterprise, behind-the-firewall Python web application.
  • Kerberos should be used to authenticate the users.
  • I have working code that sends the correct responses from the server (the Negotiate header etc.) and get the Windows user name of the user accessing the application, using the kerberos-sspi package

I have little experience with Kerberos, but some experience with web applications.

In other Python web apps I have created that use a built-in user database, the authentication flow is typically as follows:

  • For each request, check if the request has a (signed) cookie containing the user id (or some variation - for instance using flask-login where the user id is stored in flask.session)
  • If the cookie exists, respond normally.
  • If the no such cookie exists, redirect to /login/ displaying a username/password form. POST to /login/ verifies correct username/password, sets the secure cookie and redirects to the URL specified in the ?next= query param.

My question is:

  • In the Kerberos-authenticated web app, is the authentication flow similar?

  • I.e. should I do the following:

    • For each request, check if the request has a (signed) cookie containing the user id
    • If the cookie exists, respond normally.
    • If the no such cookie exists, redirect to /login/. /login/ does the necessary stuff to figure out who the user is (i.e. sending the Negotiate header, use kerberos_sspi to find the user name etc.), then set the secure cookie and redirect to the URL specified in the ?next= query param.

  • Or should it be handled some other way?

codeape
  • 97,830
  • 24
  • 159
  • 188

1 Answers1

1

Yes, your suggested flow seems viable.

You could perform the Kerberos Negotiation as first thing landing on /login/ and redirect the user back to the session, if Kerberos said yes. This could even be an XMLHttpRequest on the background and redirect to /login/ if a session ceases to be valid. If the session is checked in the background, the cookies can have a significantly shorter lifetime than Kerberos tokens and you have less of valid sessions to worry about at any given time.

If a session does not exist, offer Kerberos and potential other login methods for the user.

If a user has a valid session through Kerberos, but no user profile, provision the user into the application. Here, you can poll the user for more information on the spot, decide based on groups and roles, or create the user as a stub with a set of default permissions, known missing values and thus defer the process.

This was all very general. You should probably review what you are trying to map your goals against triple-A or AAA as in Authentication, Authorization and Accounting. It seems clear that Kerberos is doing authentication and the remaining roles need to be decided.

About cookies: It indeed does make sense to transform any Authentication into a cookie on your application. That way you could later add some other methods of SSO on the side without changing the whole application.

ferrix
  • 763
  • 3
  • 14