5

I'v developed an internal singe-page web-app (unix, apache & postgresql) protected by a simple login page. Currently, the users have their own login role with a password.

This is starting to get cumbersome for a couple reasons:

  1. Users have multiple passwords (for my web-app and Active Directory, the company-network is windows).

  2. Storing user information in two different places (would like to centralize).

I've been looking into Kerberos to the point, I've set-up a KDC and am able connect to the database through GSSAPI authentication (command-line only).

From what I understand I should be able to use my own KDC that will integrate with Active Directory.

My problem I'm working through at the moment is web-app authentication via kerberos:

If a user is on the web - how can I obtain/verify kerberos credentials? Can I store the credentials in a cookie? Do I have to resort using OAuth,Webauth, or something similar?

To clarify, What I want to do is:

If a user doesn't have valid credentials, give them the login page to obtain credentials (via kinit, but how through the browser?) and return valid credentials. (how can I store credentials in browser, can I create a cookie from the Kerberos credentials?).

I've googled, and read a fair-few pdf's and web-resources, but unfortunately none of them were able to dumb it down enough for me to get a solid grasp of how to accomplish kerberos web authentication.

If you didn't notice, I'm confused on how to piece everything together and would appreciate a conceptual over-view of how everything fits together.

1

The usual way you would go about this, is just whenever processing authentication requests in your web application, you would authenticate against Kerberos to check for valid login/password.

I do not think you will find another way to check for current user's authentication details in e.g. Windows session, as that wouldn't be secure by design. If you would store the user/password combination, you would have to store it in accessible form, and that would also make it open for hijacking.

1
  1. If the user does not have a valid id in their cookie, they are redirected to a login page.
  2. They submit credentials in a form / ajax post to the server which checks they are valid via any means (Kerberos, database, etc.)
  3. If they are valid, set their username in their session (which should have a unique id) and send them back the session id in a cookie.

As far as the contents of the cookie, you NEVER want to store the credentials in it or any other sensitive information. You only need to store a unique and random identifier. When the user makes another request to your page you use this identifier to access their session data. It can look something like this

auth-id: abc123

If they are authenticated, their session data should contain the username they authenticated under. You also don't need to store the kerberos credentials server-side either, you only need them to check if they are valid, then store the username in the session.

Again it's important to understand that HOW the authentication is done on the server is irrelevant to how you maintain their session / authenticated state.

0

Simplify. Have you considered using AD's LDAP interface and performing an ldap_bind against the user with the given password? This is a very easy way to validate user credentials against an AD server without storing the password or adding extra layers.

Apache even has an auth plugin that does this bit for you: http://httpd.apache.org/docs/current/mod/mod_authnz_ldap.html or https://httpd.apache.org/docs/2.0/en/mod/mod_auth_ldap.html

Kerberos is great for those times when you don't want to prompt the user for their password (you request a token from the daemon running in their environment instead). I've not seen this working with web apps before; I imagine it would require the app to break out of the browser's sandbox.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.