https://issues.apache.org/bugzilla/show_bug.cgi?id=48685

--- Comment #32 from Michael Osipov <1983-01...@gmx.net> 2011-03-30 14:08:52 
EDT ---
(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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to