Ok, so I can use LDAP to Authenticate and Authorize my users via AD. There
are no problem with them having to write there credentials again, there are
other solutions for that.
About security we have to use SSL anyway so I'll guess that it will solve
the problem.
I'm trying with the following but get no information from the logs if there
actually are any activity going on... Or if there are anything wrong. But I
can't login. :-/
Realm className=org.apache.catalina.realm.JNDIRealm
connectionURL=ldap://[server ip]
userBase=CN=Users,dc=yage,dc=com
userSearch=(userPrincipalName={0})
userRoleName=member
roleBase=CN=Users,dc=yage,dc=com
roleName=cn
roleSearch=(member={0})
connectionName=CN=[username],CN=Users,DC=yage,DC=com
connectionPassword=[password]
roleSubtree=true
userSubtree=true /
(Adapted to our situation here (ipnumber, password, domain etc )
Thank you in advance
Roland Carlsson
Den 04-10-14 13.24, skrev Nikola Milutinovic
[EMAIL PROTECTED]:
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]
Sent using the Microsoft Entourage 2004 for Mac Test Drive.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
