How to use SPNEGO auth without keytab

[kmark]

I am trying to get SPNEGO authorization working for my Wildfly instance but I'm having some trouble. This is a part of a porting process, going from Tomcat to Wildfly and I would like to have the first incarnation of the port behave as identically to the Tomcat instance as possible. This means to use SPNEGO and to NOT use a keytab to provide the server's creds. I was hoping to find some guide or article about doing this, but I am failing to do so. I have followed several guides to get it to a good point, but I am now at a loss when it comes to providing the pre-auth user/pass directly instead of creating a keytab file.

Everything I can find about SPNEGO and Wildfly uses keytabs, but I know there is a way to provide the user/pass using either an internal callback handler or the login module's shared state, but I don't know how to initialize these things.

Does anyone have any insight into keytab-less authorization using SPNEGO in Wildfly?

Thanks in advance for your time.

[mchoma]

Interesting question. I have never seen wildfly keytab-less configuration neither.

As I understand keytab is used to authenticate server to KDC. e.g. HTTP/[e-mail].

How would you expect server will provide these information interactively? You know client is providing user kerberos ticket [e-mail]. Do you mean client should somehow provide also HTTP/[e-mail] kerberos ticket? Or just password for HTTP/[e-mail] ?

But I think that would be secure risk  passing service ticket or service password over unsecured network.

Could you provide Tomcat keytab-less configuration link to article/tutorial to understand better what would you like to achieve.

[kmark]

What I would like to achieve is to simply store the user/pass in a config file or something similar on the server itself and provide them directly to the pre-authentication process. What I have currently in Tomcat is an HTTP filter (Configuring Authentication Filter for Tomcat) which is registered in a web.xml in the conf folder of the Tomcat instance. This is the filter registration within the web.xml:

<filter>

        <filter-name>SpnegoHttpFilter</filter-name>

        <filter-class>net.sourceforge.spnego.SpnegoHttpFilter</filter-class>

        <init-param>

            <param-name>spnego.allow.basic</param-name>

            <param-value>true</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.allow.localhost</param-name>

            <param-value>true</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.allow.unsecure.basic</param-name>

            <param-value>true</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.login.client.module</param-name>

            <param-value>spnego-client</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.krb5.conf</param-name>

            <param-value>krb5.conf</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.login.conf</param-name>

            <param-value>login.conf</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.preauth.username</param-name>

            <param-value>[user]</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.preauth.password</param-name>

            <param-value>[pass]</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.login.server.module</param-name>

            <param-value>spnego-server</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.prompt.ntlm</param-name>

            <param-value>true</param-value>

        </init-param>

        <init-param>

            <param-name>spnego.logger.level</param-name>

            <param-value>1</param-value>

        </init-param>

    </filter>

So here the preauth creds are being directly provided to the mechanism to perform the authentication for the server. From my understanding, once the server authorizes with the KDC, it will be given a Ticket Granting Ticket and so it would not have to be done interactively. It is just done once at startup and everyone else simply calls the server's services and it then authenticates/authorizes them itself using its TGT.

As far as the guides I've been using. I have been piecing together bits from various places. Here are some I've been using: Negotiation User Guide (out of date I think?), How to implement Kerberos authentication with a Simple REST Web App, How to Setup SSO with Kerberos - Red Hat Customer Portal, Does WildFly support SPNego Authetication?

So I'm kinda of all over the place trying to do what I wanted. Not sure if that answered all of your questions though. Please let me know if there is more you need to look at.

Thanks!

[mchoma]

I think I understand now. No, you can not specify ticket password in plaintext. This limitation is inherited from used JAAS Krb5LoginModule [1], which is used under hood and that does not allow this.

[1] Krb5LoginModule (Java Authentication and Authorization Service )

[kmark]

That's quite unfortunate, but then again, I understand its much more secure and really the way to go if you want to code this. I'm curious though, the SPNEGO HTTP Filter injects the creds through a CallbackHandler within the Krb5 Login Module, do you know how to get a Callback Handler injected into the Login Module? I can go that route instead. The only other thing I am finding is that you have to create another Login Module to update a shared state map and let it use that? Is that right, or is there an easier way?