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]
