Roland Carlsson wrote:
Hi Nikola!
Thank you for your answer.
Am I reading you correctly? Can't I use Active Directory today to Authenticate and Authorize people in my Tomcat-server without write a "server-side GSSAPI"?
Isn't it possible through LDAP to do this? I have no need for SingleSignOn etc. If we didn't already have had a AD directory I should have used a database-realm.
The answer is not so simple. It depends on what you actually want to do. And, yes, you can use LDAP. I believe there is a LDAP realm sample in Tomcat's docs.
Authentication is done via an authentication mechanism. The web knows several mechanisms - protocols between web server and web client:
- Basic: user/pass is sent in HTTP headers, Base64 encoded - Digest: digest algorithm (MD5?) is used, with pass as "shared secret" - Certificate: SSL is used and client-side certificate identifies user - Negotiate: a.k.a. SPNEGO, Kerberos tickets are used to authenticate - Custom: some systems offered Krb tickets in cookies
Now, "Basic" is simple and can be relayed, in other words, the web server can stand in between a client and "authentication service", like SQL database, LDAP directory, locally stored user/pass, etc.
"Digest" is, AFAIK, not relayable, since the server MUST have a copy of the shared secret (password) in order to check the digest of the returned token. Token is created by the server, sent to the client, who makes a digest, using password as salt and returns it to the server. For that reason Digest authentication requires server to have it's own plaintext storage of user credentials.
"Certificate" is fine, if you have them and can make an effort to maintain the certificate infrastructure (which is no simple task).
"Negotiate" has come into the picture with the advance of MS ADS, since it uses Kerberos as a primary authentication mechanism. In this setup all servers offering some service (SMTP, IMAP4, HTTP) must be registered with the Kerberos KDC (Key Distribution Center), where a Kerberos service key will be issued to that service. In case of HTTP, the key principal is for instance "HTTP/[EMAIL PROTECTED]".
If a user logs onto ADS, that user will get a TGT token from KDC and will be issued a ticket for the HTTP service on *that* server. Server will check the token and client will check server's return token, so, in a tripple handshake, both server and client will be sure whom they are talking about.
What this amounts to is that with Kerberos setup, you have a secure authentication mechanism (Kerberos encrypts auth traffic) and the actual authentication is performed in one place - the KDC. This is known as SingleSignOn - you log onto the network, not particular service.
With LDAP you can get close to this. Yes, user credentials are in one place, the ADS. Users will have to type their user/pass, unlike in Kerberos setup. Yes, it is the same user/pass as the one used to log onto ADS. So far, so good. But, no, "Basic" authentication mech (the only one left, since "Digest" and others are non-applicable) does not offer any encryption. And users have to type user/pass for every realm.
Of course, you can run BASIC(via LDAP) over SSL, but that has a CPU power price to it.
Nix.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
