Bug 48685 - Spnego Support in Tomcat
Spnego Support in Tomcat
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
6.0.24
PC Windows XP
: P2 enhancement (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2010-02-05 01:37 UTC by ashish.jain
Modified: 2011-04-01 08:49 UTC (History)
2 users (show)



Attachments
Patch for spnego support in tomcat (4.16 KB, patch)
2010-02-05 01:39 UTC, ashish.jain
Details | Diff
Updated patch for Spnego support in tomcat (3.70 KB, patch)
2010-02-15 12:01 UTC, ashish.jain
Details | Diff
Updated version of the patch against Tomcat 6.0.26 (6.54 KB, patch)
2010-03-22 09:35 UTC, ashish.jain
Details | Diff
Jaas configuration file (258 bytes, application/octet-stream)
2010-03-22 09:40 UTC, ashish.jain
Details
Krb5 configuration file (361 bytes, application/octet-stream)
2010-03-22 09:41 UTC, ashish.jain
Details
Libraries for login module, realm implementation (633.90 KB, application/zip)
2010-03-22 09:44 UTC, ashish.jain
Details
Sample test application (6.01 KB, application/octet-stream)
2010-03-22 09:45 UTC, ashish.jain
Details
Java opts (243 bytes, application/octet-stream)
2010-03-22 09:48 UTC, ashish.jain
Details
Complete SPNEGO Authenticator and Active Directory Realm (8.00 KB, application/x-gzip)
2011-03-23 05:21 UTC, Michael Osipov
Details
krb5.conf (891 bytes, application/octet-stream)
2011-03-30 04:12 UTC, Michael Osipov
Details
jaas.conf (420 bytes, application/octet-stream)
2011-03-30 04:14 UTC, Michael Osipov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ashish.jain 2010-02-05 01:37:10 UTC
Uploading  a patch. Kindly verify. To use this patch the users have to set up a system property as true
org.apache.tomcat.config.NEGOTIATE = true
Comment 1 ashish.jain 2010-02-05 01:39:30 UTC
Created attachment 24930 [details]
Patch for spnego support in tomcat
Comment 2 Mark Thomas 2010-02-11 00:07:10 UTC
The patch is needs reformatting:
 - spaces rather than tabs
 - remove the unused imports
 - remove System.out
 - conform to the existing coding style, particularly placement of {
 - remove addition of random blank lines

There also needs to be some explanation/documentation on how this is meant to work. I assume it only works with an appropriately configured JAAS realm.

Some explanation of how this maps to http://msdn.microsoft.com/en-us/library/ms995330.aspx and step 5 of "SPNEGO Token Handshake via HTTP Headers" in particular would also help.

I'm leaning towards the creation of a new authenticator class that extends the BASIC authenticator and is selected by using SPENGO rather than BASIC in the web.xml. That would allow per webapp configuration. I also think that, assuming a fairly specific JAAS configuration is required, that the authenticator should check that such a configuration is in place and fail to start if it isn't.
Comment 3 ashish.jain 2010-02-15 11:59:00 UTC
My sincere apologies that patch did not make the standard of tomcat community. I have reformatted the patch and uploading a new one. 

To use this the only requirement is to add a JAAS realm and set the property org.apache.tomcat.config.NEGOTIATE = true.

Choosing SPNEGO in web.xml may require a change in Spec and so as of now the current dependency is to use BASIC in the authentication mechanism.

In case Spnego fails the authentication will fall back on the other mechanism say properties-file, ldap, database, certificates etc.

I have added a related document in geronimo
http://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html
Comment 4 ashish.jain 2010-02-15 12:01:18 UTC
Created attachment 24987 [details]
Updated patch for Spnego support in tomcat

Kindly review and apply.
Comment 5 Mark Thomas 2010-03-08 19:45:38 UTC
The patch will not be applied in it's current form.

There are a number of issues. In no particular:
- format (bracket placement, random white-space changes)
- use of a system property that makes SPNEGO configuration global
- lack of documentation

This last point is particularly important given that this depends on a specifically configured JAAS realm.

I am still leaning towards creating a new authenticator for this. The spec allows containers to add additional methods beyond BASIC, FORM, etc.

Given the effort required to test this, I'm not going to start setting up a domain and the like until there is some documentation, particularly on the JAAS configuration required. The other issues with the patch I am less concerned with given that it is likely to be extensively re-worked before it is included. I'm also marking this as an enhancement.
Comment 6 ashish.jain 2010-03-22 09:35:02 UTC
Created attachment 25157 [details]
Updated version of the patch against Tomcat 6.0.26
Comment 7 ashish.jain 2010-03-22 09:40:40 UTC
Created attachment 25158 [details]
Jaas configuration file
Comment 8 ashish.jain 2010-03-22 09:41:36 UTC
Created attachment 25159 [details]
Krb5 configuration file
Comment 9 ashish.jain 2010-03-22 09:44:46 UTC
Created attachment 25160 [details]
Libraries for login module, realm implementation
Comment 10 ashish.jain 2010-03-22 09:45:49 UTC
Created attachment 25161 [details]
Sample test application
Comment 11 ashish.jain 2010-03-22 09:48:03 UTC
Created attachment 25162 [details]
Java opts
Comment 12 ashish.jain 2010-03-22 10:02:23 UTC
Hi Mark,

I have modified the patch as you have suggested in your latest update. The new modified patch includes the following:

1) No dependency on Basic, the applications can use SPNEGO as the auth-method now in web.xml.
2) No Global property setting required.
3) Removed tabs and extra spaces, if the formatting of the patch still does not match tomcat standards I will request you to point me to some doc which explains coding conventions to be used in tomcat.

I was to create a new wiki page for the steps in tomcat but was not sure where to add the new page. Some guidance on this is expected.

For now I will chalk down the steps here and than same can be added to Tomcat wiki.

1) Set up the active directory controller as explained in this link
http://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html#UsingSpengoingeronimo-SettinguptheActiveDirectoryDomainController
2) Set up the client machine as explained in this link
http://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html#UsingSpengoingeronimo-Settinguptheclientmachine
3) Add the jaas.conf, krb5.ini and krb5.keytab files to the server machine.
4) Add the jars in the zip to tomcat classpath.
5) Set the JAVA_OPTS before starting the server.
6) Start the server and deploy the application.
7) Please make sure your web.xml has correct roles defined and the user which is being used to authenticate should be memberOf that particular role in Active Directory Server.
8) On success you should be able to access the resource w/o any prompts for username and password.


Thanks
Ashish
Comment 13 Mark Thomas 2010-04-06 14:15:58 UTC
Adding all those JARs to a standard Tomcat installation isn't going to be acceptable. How feasible is a lighter weight implementation? A new authenticator and new realm is about the limit of what I would find acceptable.

Also, you haven't yet answered my question regarding the SPNEGO protocol. Specifically:
Some explanation of how this maps to
http://msdn.microsoft.com/en-us/library/ms995330.aspx and step 5 of "SPNEGO
Token Handshake via HTTP Headers" in particular would also help.
Comment 14 ashish.jain 2010-04-22 03:38:51 UTC
Regarding your question "Step 5 of Spnego", in most of the cases the size of the Spnego token will be less that < 4 KB however in case it goes over and above 4KB, maxHttpHeaderSize can be increased, so implementing Step5 is not a necessity.

On the JAAS realm I had an understanding from your previous update that you wanted a sample to test and that is the reason I have provided all the jars so that you can test it in your setup.

However If I understand correctly you want me to provide a tomcat specific implementation of "org.apache.geronimo.tomcat.realm.TomcatJAASRealm". SpnegoAuthenticator is already up and available in the patch. 

So if I provide a tomcat specific implementation of TomcatJAASRealm will you include the patch in Tomcat?
Comment 15 Michael Osipov 2010-11-02 06:17:55 UTC
Mark,

in my opinion all of these additional dependencies are superfluous. I wrote a SpnegoAuthenticator for our webapps in less than 300 lines of code. All you need is Java 6 with native SPNEGO support.

Our Active Directory forrest contains serveral thousand accounts which perfectly work with this solution.

I would donate the code and adapt if this will be necessary. More over, I wrote a supplemental Active Directoy Realm which retrieves the roles and authenticates itself with Kerberos either as the Tomcat server or even better as the client connecting to the Tomcat server (credential delegation through Kerberos).

Michael
Comment 16 Mark Thomas 2010-11-02 12:12:59 UTC
(In reply to comment #15)
> in my opinion all of these additional dependencies are superfluous. I wrote a
> SpnegoAuthenticator for our webapps in less than 300 lines of code. All you
> need is Java 6 with native SPNEGO support.

Good to hear.

> I would donate the code and adapt if this will be necessary.
That would be great.

> More over, I wrote
> a supplemental Active Directoy Realm which retrieves the roles and
> authenticates itself with Kerberos either as the Tomcat server or even better
> as the client connecting to the Tomcat server (credential delegation through
> Kerberos).

That sounds interesting too.
Comment 17 Michael Osipov 2010-11-21 15:58:39 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > in my opinion all of these additional dependencies are superfluous. I wrote a
> > SpnegoAuthenticator for our webapps in less than 300 lines of code. All you
> > need is Java 6 with native SPNEGO support.
> 
> Good to hear.
> 
> > I would donate the code and adapt if this will be necessary.
> That would be great.
> 
> > More over, I wrote
> > a supplemental Active Directoy Realm which retrieves the roles and
> > authenticates itself with Kerberos either as the Tomcat server or even better
> > as the client connecting to the Tomcat server (credential delegation through
> > Kerberos).
> 
> That sounds interesting too.

This is weird, I wasn't notified about your comment..Do you want me to attach the maven project? What license do you prefer, ASL?

All files contain JavaDocs. Solely the environment preps are missing in the docs but can be added.
Comment 18 Mark Thomas 2011-03-16 08:51:21 UTC
(In reply to comment #17)
> This is weird, I wasn't notified about your comment..Do you want me to attach
> the maven project? What license do you prefer, ASL?

Sorry for the slow reply. Yes please. ALv2 is by far the easiest to work with.
Comment 19 Michael Osipov 2011-03-23 05:21:42 UTC
Created attachment 26792 [details]
Complete SPNEGO Authenticator and Active Directory Realm

this is our minimal implementation of SpnegoAuthenticator (less than 200 lines) and Active Directory Realm. It requires only a Java 6 to run due to SPNEGO support. All authentication is done thru Kerberos for the Active Directory too.

Adapt classes to your Tomcat namespace.
I hereby grant a full ASLv2 license to the Apache Foundation to integrate the source into Tomcat.

If you need any changes, please tell.
Comment 20 Mark Thomas 2011-03-23 05:34:51 UTC
I haven't look at this yet but I just wanted to say thank you and let you know this is on the radar. Personally, I'm snowed under with other stuff at the minute but I will get to this as soon as I can - unless one of the other committers beats me to it.

Thanks again.
Comment 21 Mark Thomas 2011-03-25 13:59:58 UTC
I'm looking at this now and currently trying to figure out the additional configuration required (JAAS, keytab, etc). Any notes you can provide that would save me from figuring stuff out from scratch would help.
Comment 22 Michael Osipov 2011-03-25 15:07:45 UTC
(In reply to comment #21)
> I'm looking at this now and currently trying to figure out the additional
> configuration required (JAAS, keytab, etc). Any notes you can provide that
> would save me from figuring stuff out from scratch would help.

Mark, did you check the Authenticator and Realm JavaDocs?
More over, you'll need to some some system properties. I'll post the exact ones on monday because I don't have accesss to the files from work atm.

You'll need to provide at least:

-Djava.security.auth.login.config and
-Djava.security.krb5.conf
Comment 23 Mark Thomas 2011-03-25 15:18:08 UTC
Doh. I missed the javadoc completely. My bad. I'll take a look over the weekend and get back to you.
Comment 24 Mark Thomas 2011-03-26 13:24:23 UTC
Having reviewed the Javadoc, there still appears to be a lot of information missing/assumed. The Geronimo notes from comment #12 appear to cover many of the missing steps. I plan to use those as the basis of my testing for now.
Comment 25 Michael Osipov 2011-03-26 13:48:00 UTC
(In reply to comment #24)
> Having reviewed the Javadoc, there still appears to be a lot of information
> missing/assumed. The Geronimo notes from comment #12 appear to cover many of
> the missing steps. I plan to use those as the basis of my testing for now.

Most, yes. That's why I wrote that I will post more information on monday. I do not have access to those files now.
Comment 26 Michael Osipov 2011-03-28 04:40:34 UTC
Mark,

here's what you need to make it run:

I expect you/someone to have an already working AD environment where the server with tomcat running is registered in the domain, have an SPN set and an keytab created for that service account.

This is what you need to configure your setenv.sh:
KERBEROS_CONFIG="-Djava.security.auth.login.config=$CATALINA_HOME/conf/jaas.conf -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.krb5.conf=/etc/krb5.conf"

The jaas.conf contains the login module pointing to the keytab or a already preloaded ticket cache.
The krb5.conf is Unix usual with you realm and other realms used with tomcat.

Pass KERBEROS_CONFIG to your JAVA_OPTS and make it run.
Comment 27 Mark Thomas 2011-03-28 08:01:05 UTC
I'd managed to work out the system properties. I currently suspect issues with my jaas.conf and/or krb5.conf or possibly the keytab file. Samples of those would help although I am currently considering aiming for a Spring Security style solution since that appears to only requires the keytab file (although I haven't looked at that in detail yet).
Comment 28 Michael Osipov 2011-03-30 04:12:28 UTC
Created attachment 26814 [details]
krb5.conf

This is a sample Kerberos 5 conf file with multi realm config. This one works in our environment with cross-realm validation and sign on. As well as obtaining cross-realm service tickets from delegated credential.
Comment 29 Michael Osipov 2011-03-30 04:14:09 UTC
Created attachment 26815 [details]
jaas.conf

this jaas.conf contains two login modules. The 'accept' module validates client tickets against the keytab of the host. The 'initiate' module enables the server to authenticate an active directory DC with Kerberos.
Comment 30 Michael Osipov 2011-03-30 04:15:38 UTC
Mark,

I have attached some sample config files to make it run. This solution
uses a keytab to validate tickets.

I am aware of the Spring way, we use that Sec Extension also but I don't
like that because of the following drawbacks:

1. You have ugly inline code which has to be maintained.
2. You have to provide a module for every JVM implementation (Oracle, IBM,
etc) which the user would have again to configure
3. You cannot use your custom Krb5 modules which could happen. You have
to alter and recompile tomcat then => ugly
4. You lose the entire configuration flexiblity of the modules unless you
pass all config params of the modules through the authenticator => even
more code.

I'd rather stick with the login modules because they are proven to work
well and are documented thoroughly by Oracle.

I have tried to keep the implementation as simple as possible. Going the 
above way would require way more code.

Mike
Comment 31 Mark Thomas 2011-03-30 07:01:50 UTC
(In reply to comment #30)
> I have attached some sample config files to make it run. This solution
> uses a keytab to validate tickets.

Thanks. It was the jaas.conf that I hadn't been able to figure out.

> I am aware of the Spring way, we use that Sec Extension also but I don't
> like that because of the following drawbacks:
> 
> 1. You have ugly inline code which has to be maintained.
> 2. You have to provide a module for every JVM implementation (Oracle, IBM,
> etc) which the user would have again to configure
> 3. You cannot use your custom Krb5 modules which could happen. You have
> to alter and recompile tomcat then => ugly
> 4. You lose the entire configuration flexiblity of the modules unless you
> pass all config params of the modules through the authenticator => even
> more code.
> 
> I'd rather stick with the login modules because they are proven to work
> well and are documented thoroughly by Oracle.
> 
> I have tried to keep the implementation as simple as possible. Going the 
> above way would require way more code.

My primary aim was getting something to work. As a result of that experience, I wanted to keep the configuration as simple as possible - i.e. use sensible defaults and provide a mechanism for the user to override them. However, I hadn't considered custom login modules or noticed the one currently used is an Oracle internal one. I'm leaning towards restoring using the jaas.conf file as it is the elegant solution to all of those problems and, as you point out, it means less code.

My one concern is that it requires users to do slightly more to get SPNEGO to work. I think that can be overcome by good documentation. On that note, what Oracle documentation were you referring to? If there is a good explanation of this stuff I'd like to include a reference to it in the Tomcat docs.
Comment 32 Michael Osipov 2011-03-30 14:08:52 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > I am aware of the Spring way, we use that Sec Extension also but I don't
> > like that because of the following drawbacks:
> > 
> > 1. You have ugly inline code which has to be maintained.
> > 2. You have to provide a module for every JVM implementation (Oracle, IBM,
> > etc) which the user would have again to configure
> > 3. You cannot use your custom Krb5 modules which could happen. You have
> > to alter and recompile tomcat then => ugly
> > 4. You lose the entire configuration flexibility of the modules unless you
> > pass all config params of the modules through the authenticator => even
> > more code.
> > 
> > I'd rather stick with the login modules because they are proven to work
> > well and are documented thoroughly by Oracle.
> > 
> > I have tried to keep the implementation as simple as possible. Going the 
> > above way would require way more code.
> 
> My primary aim was getting something to work. As a result of that experience, I
> wanted to keep the configuration as simple as possible - i.e. use sensible
> defaults and provide a mechanism for the user to override them. However, I
> hadn't considered custom login modules or noticed the one currently used is an
> Oracle internal one. I'm leaning towards restoring using the jaas.conf file as
> it is the elegant solution to all of those problems and, as you point out, it
> means less code.

Mark, you can cut down the config of the authenticator by providing a default login module name: tomcat-accept. That's it. Your are ready to go.

I checked your commit in svn and the code/config options are bloated in my opinion due to eh points mentioned above.

There at least two krb5 modules known to me:
http://www.ibm.com/developerworks/java/jdk/security/50/secguides/jgssDocs/api/com/ibm/security/auth/module/Krb5LoginModule.html
http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html

I am happily using this code on Oracle JVM and HP JVM.

Moreover, I'd consider the delegated credential extraction for crucial, this is one of best features of kerberos. We use them all the time. I wouldn't strip that.

The realm can be reduced by the login module with tomcat-initiate too. Most options are optional anyway.

I can provide a sample context.xml which I use in our environment.
 
> My one concern is that it requires users to do slightly more to get SPNEGO to
> work. I think that can be overcome by good documentation. On that note, what
> Oracle documentation were you referring to? If there is a good explanation of
> this stuff I'd like to include a reference to it in the Tomcat docs.

There is no need to have a concern, those who require SPNEGO auth need to know about Kerberos and how it works anyway (to some degree).

The documentation needs to be split in 2 parts.
1. Network preparation.
2. Tomcat config.

according 1.: This is more off-topic because this is not a tomcat issue but a general server admin one. For the sake of completeness, this can be outlined.
We have documented that part. I can upload that too.
according 2.: All you need is pass both properties krb5 and login conf to the JVM and configure the login module. You're done. Both are already provided as sample by me.

The oracle documentation refers the the properties, server and client code and the login module configuration. Everything is well-documented here: http://download.oracle.com/javase/1.5.0/docs/guide/security/jgss/tutorials/index.html

Just drop a few lines if you need further assistance.
Comment 33 Michael Osipov 2011-03-30 14:11:08 UTC
Sorry for the spelling, I was to hasty with the 'commit' button.
Comment 34 Michael Osipov 2011-03-30 14:19:55 UTC
These docs are fine:

http://wiki.alfresco.com/wiki/Configuring_the_CIFS_and_web_servers_for_Kerberos/AD_integration
http://www-01.ibm.com/support/docview.wss?uid=swg21448203

Another issue I'd like to add.

We created a computer account for the server with the UPN host/fqdn and mapped all SPN to that, so your login module contains as spn the host/fqdn and all other SPN are automatically validated because they all map to one account. With this you are able to provide several configs HTTP/, NFS/, and so forth for that machine.

A simple use case would be that beside the HTTP/ part the webapp hosts a samba share server. The windows explorer will then create a service ticket cifs/fqdn for that server which can be verified with the host/ UPN.
Comment 35 Michael Osipov 2011-03-30 14:29:33 UTC
Sorry for spamming again.

We run mixed environments with Windows Server 2003 and 2008, both serve as KDC.
Server code works on Windows XP and HP-UX flawlessly running JVMs from Oracle and HP.

Clients which work perfectly are: IE6+, Firefox (complete coverage), JDK URL Connection (transparently) and the Async HTTP Client (https://github.com/sonatype/async-http-client) which I have patched also. I guess CURL works too but did not test.
Comment 36 Mark Thomas 2011-03-31 20:42:47 UTC
The final part of the Tomcat SPNEGO implementation has just been committed. It is broadly based on Michael's patch.

The key features are:
- a new SPNEGO login-config for use in web.xml that supports Windows native authentication via kerberos
- integration with all Tomcat Realms
- additional integration with the JNDI Realm that enabled the user's delegated credentials to be used to connected to AD
- the user's delegated credentials are exposed via a request attribute so applications can use then to impersonate the user when accessing external services

The main differences compared to the original patch are:
- Use existing Base64 encoder/decoder rather than proposed one
- Integrate with the JNDI realm rather than a new one
- Use existing GenericPrincipal rather than proposed ones
- Documentation

This requires Java 6 so it won't get proposed for back-port to 6.0.x.

Bugs in this implementation and additional configuration / feature requests should be raised as new Bugzilla issues against Tomcat 7.
Comment 37 Michael Osipov 2011-04-01 04:59:26 UTC
Mark, I tried to build the current trunk to validate the code and mark some improvements but I fails with:

build-docs:
     [xslt] Transforming into E:\Projekte\tomcat-trunk\output\build\webapps\docs

     [xslt] Processing E:\Projekte\tomcat-trunk\webapps\docs\changelog.xml to E:
\Projekte\tomcat-trunk\output\build\webapps\docs\changelog.html
     [xslt] Loading stylesheet E:\Projekte\tomcat-trunk\webapps\docs\tomcat-docs
.xsl
     [xslt] E:\Projekte\tomcat-trunk\webapps\docs\tomcat-docs.xsl:470: Fatal Err
or! Illegal HTML character: decimal 150
     [xslt] Failed to process null
Comment 38 Mark Thomas 2011-04-01 05:07:36 UTC
Looks like you have a build environment problem. It builds fine for me and the multiple CI systems (buildbot and gump) that build this codebase. The users list is the best place to get help with that.
Comment 39 Michael Osipov 2011-04-01 05:46:38 UTC
(In reply to comment #38)
> Looks like you have a build environment problem. It builds fine for me and the
> multiple CI systems (buildbot and gump) that build this codebase. The users
> list is the best place to get help with that.

I am sure it's not. The problem lies int he tomcat-docs.xsl. I have saxon9 on my ant/lib classpath and is notifies about broken data. Read this for reference: http://web.archiveorange.com/archive/v/rNJIEC48MBLYfxAORgpH
Michael Kay even said that the user has to fix his xml.
Comment 40 Michael Osipov 2011-04-01 07:10:15 UTC
Mark,

there are some glitches which have to be addressed in my opinion:

Constants.java:
- DEFAULT_SPN_CLASS is never used, forgot to delete?
- DEFAULT_KRB5_CONF value: .ini is Windows style, on Unix is krb5.conf only. I would stick to that convention. I.e., split in two props.
- DEFAULT_LOGIN_MODULE_NAME value: this is Oracle-specific, I would rather use a vendor-agnostic name like 'tomcat-accept'. (Same rule as in tomcat.keytab)

SpnegoAuthenticator.java:

- 'storeDelegatedCredentials' rename to 'storeDelegatedCredential' since GSSContext uses singular and the realm does the same, applies to may JavaDocs too
- It might be worth checking of '/etc/krb5.conf' or 'C:\Windows\krb5.ini' because those are default locations on those OSs and this is what the JVM does if you did not overwrite the property. See http://download.oracle.com/javase/1.4.2/docs/guide/security/jgss/tutorials/KerberosReq.html => Locating the krb5.conf Configuration File

RealmBase.java:
- 'stripAtForGss' rename to 'stripRealm'. I think this one reads better.
- There is no option to sign in with Kerberos into a directory server. Only delegated credential works. This might be problematic if some user account is not trusted for cred deleg. I don't like to fall back to plain password. Did I miss that spot in the code?
- Property 'javax.security.sasl.server.authentication' should be configurable. It applies at least to GSSAPI.
- Property 'javax.security.sasl.qop' should be configurable. It applies at least to GSSAPI *and* DIGEST-MD5.
See here for more ref: http://download.oracle.com/javase/jndi/tutorial/ldap/security/sasl.html

I did not yet try the code, I just made a review. I will check docs separately.
Comment 41 Mark Thomas 2011-04-01 07:30:16 UTC
(In reply to comment #40)
> - DEFAULT_SPN_CLASS is never used, forgot to delete?
Fixed

> - DEFAULT_KRB5_CONF value: .ini is Windows style, on Unix is krb5.conf only. I
> would stick to that convention. I.e., split in two props.
Happy with the current default. Can be set via system property.

> - DEFAULT_LOGIN_MODULE_NAME value: this is Oracle-specific, I would rather use
> a vendor-agnostic name like 'tomcat-accept'. (Same rule as in tomcat.keytab)
Happy with the current default. Users can change if desired.

> - 'storeDelegatedCredentials' rename to 'storeDelegatedCredential'
fixed

> - 'stripAtForGss' rename to 'stripRealm'
Changed to stripRealmForGss

> - There is no option to sign in with Kerberos into a directory server. Only
> delegated credential works. This might be problematic if some user account is
> not trusted for cred deleg. I don't like to fall back to plain password. Did I
> miss that spot in the code?
Nope. Please open an enhancement request.

> - Property 'javax.security.sasl.server.authentication' should be configurable.
> It applies at least to GSSAPI.
> - Property 'javax.security.sasl.qop' should be configurable. It applies at
> least to GSSAPI *and* DIGEST-MD5.
Another enhancement request please.
Comment 42 Michael Osipov 2011-04-01 08:41:22 UTC
Mark,

I just compiled and deployed 7.0.12-dev to our test server. It works but fails at some point.
The default server.xml is configured with:
<!-- Use the LockOutRealm to prevent attempts to guess user passwords
           via a brute-force attack -->
      <Realm className="org.apache.catalina.realm.LockOutRealm">
        <!-- This Realm uses the UserDatabase configured in the global JNDI
             resources under the key "UserDatabase".  Any edits
             that are performed against this UserDatabase are immediately
             available for use by the Realm.  -->
        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
</Realm>

The Authentication fails at: UserDatabaseRealm line 215 because the use cannot be found in the database.

I think there is a huge misconception from your point of view. Kerberos is not something which simply passes credentials to a realm. Kerberos IS THE REALM. You cannot and should not pass that username to any other realm but to an authorizing realm. In this case the user cannot be authenticated and gets locked out. The way it is coded right now won't work.
Kerberos sole purpose is to indentify the user properly and this works flawlessly in my Eclipse debug session and in Fiddler.

Mike
Comment 43 Michael Osipov 2011-04-01 08:47:46 UTC
(In reply to comment #41)
> (In reply to comment #40)
> > - DEFAULT_SPN_CLASS is never used, forgot to delete?
> Fixed
> 
> > - DEFAULT_KRB5_CONF value: .ini is Windows style, on Unix is krb5.conf only. I
> > would stick to that convention. I.e., split in two props.
> Happy with the current default. Can be set via system property.

I personally disagree because Tomcat most popular platform is some Unix flavor.
 
> > - DEFAULT_LOGIN_MODULE_NAME value: this is Oracle-specific, I would rather use
> > a vendor-agnostic name like 'tomcat-accept'. (Same rule as in tomcat.keytab)
> Happy with the current default. Users can change if desired.

I disagree again because abstraction is not missing and not everyone uses an Oracle JVM.
 
> > - There is no option to sign in with Kerberos into a directory server. Only
> > delegated credential works. This might be problematic if some user account is
> > not trusted for cred deleg. I don't like to fall back to plain password. Did I
> > miss that spot in the code?
> Nope. Please open an enhancement request.

Will do!
 
> > - Property 'javax.security.sasl.server.authentication' should be configurable.
> > It applies at least to GSSAPI.
> > - Property 'javax.security.sasl.qop' should be configurable. It applies at
> > least to GSSAPI *and* DIGEST-MD5.
> Another enhancement request please.

Will do!
Comment 44 Michael Osipov 2011-04-01 08:49:08 UTC
(In reply to comment #43)
> I disagree again because abstraction is not missing and not everyone uses an
> Oracle JVM.

Should read: I disagree again because abstraction is missing and not everyone uses an...