Web application Kerberos authentication: Is the proper way to combine with cookies?

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.

• 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.
  asked Feb 12, 2019 at 15:40 100k 24 24 gold badges 171 171 silver badges 195 195 bronze badges Commented Feb 14, 2019 at 7:22 Interesting answer: stackoverflow.com/a/43499643/3571 Commented Feb 14, 2019 at 7:27

  Even though, your particular implementation is Python, your question is actually not limited to a single language. I am not sure if that is a relevant tag at the end of the day.

  Commented Feb 22, 2019 at 9:34 Agree, I removed the tag. Commented Feb 23, 2019 at 12:52

  1 Answer 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.