RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1026709 - Java GSS does not seem to work well with native libgssapi_krb5.so.2
Summary: Java GSS does not seem to work well with native libgssapi_krb5.so.2
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: java-1.7.0-openjdk
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Elliott Baron
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-05 09:42 UTC by Jan Pazdziora (Red Hat)
Modified: 2017-01-13 18:48 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-12 23:12:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
The patch to the JBoss EAP 6.1.1 to test SPNEGO. (5.85 KB, patch)
2013-11-05 09:42 UTC, Jan Pazdziora (Red Hat) 		no flags Details | Diff
View All

Description Jan Pazdziora (Red Hat) 2013-11-05 09:42:27 UTC 
Created attachment 819604 [details]
The patch to the JBoss EAP 6.1.1 to test SPNEGO.

Description of problem:

I try to set up SPNEGO with

    <system-properties>
        <property name="sun.security.jgss.native" value="true"/>
        <property name="sun.security.jgss.lib" value="/usr/lib64/libgssapi_krb5.so.2"/>
        <property name="javax.security.auth.useSubjectCredsOnly" value="false"/>
    </system-properties>

However, the Java implementation still seems to be used -- even if I put

   export KRB5_KTNAME=/etc/http.keytab

to bin/standalone.conf and change the Kerberos' configuration to point to nonexistent keytab file

  <module-option name="keyTab" value="/etc/xhttp.keytab"/>

the builtin still attempts to be used:

04:29:05,632 INFO  [stdout] (http-/0.0.0.0:8080-1) Key for the principal HTTP/the.server.company.com not available in /etc/xhttp.keytab

Version-Release number of selected component (if applicable):

java-1.7.0-openjdk-headless-1.7.0.45-2.4.3.4.el7.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have IPA/IdM server, I used RHEL 6.
2. Have RHEL 7, java-1.7.0-openjdk, jboss-eap-6.1.1.zip unpacked.
3. IPA-enroll the RHEL 7 machine: yum install -y ipa-client, ipa-client-install, on the IPA server use ipa service-add HTTP/<the-rhel7-machine> to create service and then on the RHEL 7 machine get the keytab using ipa-getkeytab -s <the-ipa-server> -k /etc/http.keytab -p HTTP/$( hostname )
4. Patch the JBoss installation with patch in attachment.
5. Start: bin/standalone.sh &
6. On the same machine or different machine also IPA-enrolled to the same IPA server, kinit with some principal and then run

curl  --negotiate -u : -Li http://<the-rhel7-machine>:8080/kerberos/

Actual results:

401.

Expected results:

200.

Additional info:

On the JBoss server, the log will show

04:29:05,623 INFO  [stdout] (http-/0.0.0.0:8080-1) Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is /etc/xhttp.keytab refreshKrb5Config is true principal is HTTP/the.server.company.com tryFirstPass is false useFirstPass is false storePass is false clearPass is false
04:29:05,624 INFO  [stdout] (http-/0.0.0.0:8080-1) Refreshing Kerberos configuration
04:29:05,632 INFO  [stdout] (http-/0.0.0.0:8080-1) Key for the principal HTTP/the.server.company.com not available in /etc/xhttp.keytab
04:29:05,633 INFO  [stdout] (http-/0.0.0.0:8080-1) 		[Krb5LoginModule] authentication failed 
04:29:05,633 INFO  [stdout] (http-/0.0.0.0:8080-1) Unable to obtain password from user
04:29:05,634 INFO  [stdout] (http-/0.0.0.0:8080-1)
Comment 1 Jan Pazdziora (Red Hat) 2013-11-05 09:44:29 UTC 
I'm opening this bugzilla against java-1.7.0-openjdk because Peter Škopek suggested that the issue is in the native Java JGSS code, that it does not hand over the handling to libgssapi_krb5.so.2.
Comment 4 Jan Pazdziora (Red Hat) 2013-11-06 05:40:36 UTC 
I should note that I see the same behaviour on RHEL 6.4 with java-1.7.0-openjdk-1.7.0.9-2.3.4.1.el6_3.x86_64.
Comment 6 Elliott Baron 2013-12-13 00:02:14 UTC 
I have reproduced the issue, thanks for the guide.

Looking at Krb5LoginModule, if the KeyTab property is supplied, the login module uses that value no matter what. I think that is fine, since you have to explicitly provide an incorrect value. With that property removed from standalone.xml, the issue still remains because http.keytab is not the default keytab file.

Forgive my ignorance, but other than the KRB5_KTNAME environment variable, is there some mechanism Java should be using to obtain the keytab location?
Comment 7 Jan Pazdziora (Red Hat) 2013-12-13 01:14:42 UTC 
(In reply to Elliott Baron from comment #6)
> I have reproduced the issue, thanks for the guide.
> 
> Looking at Krb5LoginModule, if the KeyTab property is supplied, the login
> module uses that value no matter what. I think that is fine, since you have
> to explicitly provide an incorrect value. With that property removed from
> standalone.xml, the issue still remains because http.keytab is not the
> default keytab file.
> 
> Forgive my ignorance, but other than the KRB5_KTNAME environment variable,
> is there some mechanism Java should be using to obtain the keytab location?

My understanding is that Java should not really care about the keytab location. It should hand over the handling to libgssapi_krb5.so.2 and let it use whatever mechanism that library uses, completely bypassing Java's native operations.

Please note that what we are actually trying to achieve is the setup similar to

  https://fedorahosted.org/gss-proxy/wiki/Apache

where the application doesn't have any access to the keytab and just communicates with the GSS-Proxy.

For the purpose of the Java/EAP investigation and this bugzilla I did not want to to complicate the setup with GSS-Proxy but maybe I confused you. It's not about keytab, it's about who does the operation which I tried to demonstrate with the keytab values (Java uses keyTab, native library uses KRB5_KTNAME, so it's a nice distinguisher).
Comment 8 Elliott Baron 2013-12-19 21:00:04 UTC 
(In reply to Jan Pazdziora from comment #7)
> (In reply to Elliott Baron from comment #6)
> > I have reproduced the issue, thanks for the guide.
> > 
> > Looking at Krb5LoginModule, if the KeyTab property is supplied, the login
> > module uses that value no matter what. I think that is fine, since you have
> > to explicitly provide an incorrect value. With that property removed from
> > standalone.xml, the issue still remains because http.keytab is not the
> > default keytab file.
> > 
> > Forgive my ignorance, but other than the KRB5_KTNAME environment variable,
> > is there some mechanism Java should be using to obtain the keytab location?
> 
> My understanding is that Java should not really care about the keytab
> location. It should hand over the handling to libgssapi_krb5.so.2 and let it
> use whatever mechanism that library uses, completely bypassing Java's native
> operations.

Krb5LoginModule does not use GSSAPI for authentication, and unfortunately it seems there is not a LoginModule provided by the JDK that uses GSSAPI for authentication. From my understanding, Java's GSSAPI is typically used for secure communications after authenticating with Krb5LoginModule. In addition, Java's GSSAPI implementation is written in Java and does not dispatch to the native library by default.

I have discovered a system property 'sun.security.jgss.native' that causes Java to use the native GSSAPI library [1]. Using this property in combination with KRB5_KTNAME, I have been able write the following code snippet that authenticates using GSSAPI in Java:

> GSSManager manager = GSSManager.getInstance();
> Oid spnegoOid = new Oid("1.3.6.1.5.5.2");
> 				
> GSSName name = manager.createName("HTTP.com", GSSName.NT_HOSTBASED_SERVICE);
> GSSCredential cred = manager.createCredential(name, GSSCredential.DEFAULT_LIFETIME, spnegoOid, GSSCredential.ACCEPT_ONLY);

This should give you a start at writing a LoginModule that authenticates using the native GSSAPI. Since Krb5LoginModule is working as intended, I'm closing this as NOTABUG. I hope the above property and example proves useful to you.

[1] http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html
Comment 9 Elliott Baron 2013-12-19 21:05:05 UTC 
(In reply to Elliott Baron from comment #8)
> (In reply to Jan Pazdziora from comment #7)
> > (In reply to Elliott Baron from comment #6)
> > > I have reproduced the issue, thanks for the guide.
> > > 
> > > Looking at Krb5LoginModule, if the KeyTab property is supplied, the login
> > > module uses that value no matter what. I think that is fine, since you have
> > > to explicitly provide an incorrect value. With that property removed from
> > > standalone.xml, the issue still remains because http.keytab is not the
> > > default keytab file.
> > > 
> > > Forgive my ignorance, but other than the KRB5_KTNAME environment variable,
> > > is there some mechanism Java should be using to obtain the keytab location?
> > 
> > My understanding is that Java should not really care about the keytab
> > location. It should hand over the handling to libgssapi_krb5.so.2 and let it
> > use whatever mechanism that library uses, completely bypassing Java's native
> > operations.
> 
> Krb5LoginModule does not use GSSAPI for authentication, and unfortunately it
> seems there is not a LoginModule provided by the JDK that uses GSSAPI for
> authentication. From my understanding, Java's GSSAPI is typically used for
> secure communications after authenticating with Krb5LoginModule. In
> addition, Java's GSSAPI implementation is written in Java and does not
> dispatch to the native library by default.
> 
> I have discovered a system property 'sun.security.jgss.native' that causes
> Java to use the native GSSAPI library [1]. Using this property in
> combination with KRB5_KTNAME, I have been able write the following code
> snippet that authenticates using GSSAPI in Java:
> 
> > GSSManager manager = GSSManager.getInstance();
> > Oid spnegoOid = new Oid("1.3.6.1.5.5.2");
> > 				
> > GSSName name = manager.createName("HTTP.com", GSSName.NT_HOSTBASED_SERVICE);
> > GSSCredential cred = manager.createCredential(name, GSSCredential.DEFAULT_LIFETIME, spnegoOid, GSSCredential.ACCEPT_ONLY);
> 
> This should give you a start at writing a LoginModule that authenticates
> using the native GSSAPI. Since Krb5LoginModule is working as intended, I'm
> closing this as NOTABUG. I hope the above property and example proves useful
> to you.
> 
> [1]
> http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-
> features.html

Edit: Looking back at initial report I see you've discovered this property already. The issue then is that Krb5LoginModule does not use the GSSAPI, so you need to write a LoginModule that does.
Comment 10 Jan Pazdziora (Red Hat) 2014-01-02 10:29:18 UTC 
(In reply to Elliott Baron from comment #8)
> 
> This should give you a start at writing a LoginModule that authenticates
> using the native GSSAPI. Since Krb5LoginModule is working as intended, I'm
> closing this as NOTABUG. I hope the above property and example proves useful
> to you.

Thank you for the investigation, much appreciated.
Comment 11 Jan Pazdziora (Red Hat) 2014-09-22 16:30:22 UTC 
The effort is now being bracked at https://issues.jboss.org/browse/ELY-85.
Comment 12 Jan Pazdziora (Red Hat) 2014-09-22 16:30:35 UTC 
The effort is now being tracked at https://issues.jboss.org/browse/ELY-85.
Comment 13 Omair Majid 2015-03-09 20:43:46 UTC 
Do you have a test case to reproduce this issue without having to set up IPA and JBoss? Specifically, is there a smallish standalone piece of code that I can run to reproduce and debug this bug?
Comment 14 Jan Pazdziora (Red Hat) 2015-03-10 07:55:42 UTC 
(In reply to Omair Majid from comment #13)
> Do you have a test case to reproduce this issue without having to set up IPA
> and JBoss? Specifically, is there a smallish standalone piece of code that I
> can run to reproduce and debug this bug?

You should be able to use the steps from comment 0 even without IPA. The distinguisher is the keytab path, so depending on what keytab is mentioned in the error message, you will see if the internal mechanism which responds to

   <module-option name="keyTab" value="/etc/xhttp.keytab"/>

or the native libraries that use

   export KRB5_KTNAME=/etc/http.keytab

will be used.

I have no idea to what extend the system-properties and module-option are JBoss features and how they should be showcased in pure Java.
Comment 15 Omair Majid 2015-03-10 22:16:46 UTC 
(In reply to Jan Pazdziora from comment #14)
> You should be able to use the steps from comment 0 even without IPA.

Can you tell me what such a setup would look like?

Here's what I did:
1. Have RHEL 7, java-1.7.0-openjdk, jboss-eap-6.1.1.zip unpacked.
2. Patch the JBoss installation with patch in attachment.
3. Start: bin/standalone.sh &
4. curl  --negotiate -u : -Li http://localhost:8080/kerberos/

Is that right?

> system-properties

That's part of the standard Java runtime.

> module-option

This isn't.

> I have no idea [...] how they should be showcased in pure Java.

Neither do I. I will need some help :)
Comment 16 Jan Pazdziora (Red Hat) 2015-03-11 07:34:07 UTC 
(In reply to Omair Majid from comment #15)
> (In reply to Jan Pazdziora from comment #14)
> > You should be able to use the steps from comment 0 even without IPA.
> 
> Can you tell me what such a setup would look like?
> 
> Here's what I did:
> 1. Have RHEL 7, java-1.7.0-openjdk, jboss-eap-6.1.1.zip unpacked.
> 2. Patch the JBoss installation with patch in attachment.
> 3. Start: bin/standalone.sh &
> 4. curl  --negotiate -u : -Li http://localhost:8080/kerberos/
> 
> Is that right?

That is my understanding. And the question is -- what errors will you get when you run that curl command?

Also, I can setup an IPA server on some beaker machine if you want to try the setup with IPA.
Comment 17 Jan Pazdziora (Red Hat) 2015-03-11 09:31:10 UTC 
Reopening this bugzilla since there seems to be an agreement that the buggy behaviour (not matching documentation) is there and should be investigated.
Comment 18 Omair Majid 2015-03-11 15:44:40 UTC 
(In reply to Jan Pazdziora from comment #16)
> That is my understanding. And the question is -- what errors will you get
> when you run that curl command?

$ curl  --negotiate -u : -Li http://localhost:8080/kerberos/
HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1080
Date: Wed, 11 Mar 2015 15:42:29 GMT

Interestingly enough, I don't get any log messages on the JBoss side. I was looking for something like "INFO  [stdout] (http-/0.0.0.0:8080-1) Refreshing Kerberos configuration" but I got nothing.

> Also, I can setup an IPA server on some beaker machine if you want to try
> the setup with IPA.

That would be great!
Comment 19 Jan Pazdziora (Red Hat) 2015-03-12 09:01:49 UTC 
(In reply to Omair Majid from comment #18)
> (In reply to Jan Pazdziora from comment #16)
> > That is my understanding. And the question is -- what errors will you get
> > when you run that curl command?
> 
> $ curl  --negotiate -u : -Li http://localhost:8080/kerberos/
> HTTP/1.1 404 Not Found
> Server: Apache-Coyote/1.1
> Content-Type: text/html;charset=utf-8
> Content-Length: 1080
> Date: Wed, 11 Mar 2015 15:42:29 GMT
> 
> Interestingly enough, I don't get any log messages on the JBoss side. I was
> looking for something like "INFO  [stdout] (http-/0.0.0.0:8080-1) Refreshing
> Kerberos configuration" but I got nothing.

You probably need to

   touch standalone/deployments/kerberos.war.dodeploy

to trigger the deployment of the .war.
Comment 21 Omair Majid 2015-03-12 15:18:51 UTC 
(In reply to Jan Pazdziora from comment #19)
> You probably need to
> 
>    touch standalone/deployments/kerberos.war.dodeploy
> 
> to trigger the deployment of the .war.

Now I get an exception:

11:17:03,156 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."kerberos.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."kerberos.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "kerberos.war"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018096: Error instantiating container component: org.jboss.security.negotiation.NegotiationAuthenticator
        at org.jboss.as.web.deployment.WarDeploymentProcessor.getInstance(WarDeploymentProcessor.java:415)
        at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:223)
        at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:126)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
        ... 5 more
Caused by: java.lang.ClassNotFoundException: org.jboss.security.negotiation.NegotiationAuthenticator from [Module "deployment.kerberos.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.2.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.2.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.2.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.2.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.2.Final-redhat-1]
        at org.jboss.as.web.deployment.WarDeploymentProcessor.getInstance(WarDeploymentProcessor.java:407)
        ... 8 more

Any ideas about where to get this missing class from?
Comment 22 Jan Pazdziora (Red Hat) 2015-03-12 17:52:54 UTC 
What JBoss version is this? Can you retry with 6.1.1 or 6.4?
Comment 23 Omair Majid 2015-03-13 14:09:49 UTC 
(In reply to Jan Pazdziora from comment #22)
> What JBoss version is this? Can you retry with 6.1.1

This is 6.1.1

> or 6.4?

The patch in comment 0 does not apply on 6.4. Any ideas?
Comment 25 Omair Majid 2015-03-23 18:55:30 UTC 
(In reply to Jan Pazdziora from comment #0)
> I try to set up SPNEGO

Is this the implementation of SPNEGO shipped with OpenJDK or something else?
Comment 26 Omair Majid 2015-03-23 21:53:21 UTC 
Also, would it be possible to use a non-SPNEGO GSSAPI mechanism? I am curious if the native gss library is ignored only for SPNEGO:
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/file/70e3553d9d6e/src/share/classes/sun/security/jgss/GSSManagerImpl.java#l63
Comment 27 Jan Pazdziora (Red Hat) 2015-03-24 06:59:47 UTC 
(In reply to Omair Majid from comment #25)
> (In reply to Jan Pazdziora from comment #0)
> > I try to set up SPNEGO
> 
> Is this the implementation of SPNEGO shipped with OpenJDK or something else?

My understanding is that the configuration per attachment in comment 0 uses the internal implementation. If it's OpenJDK or JBoss I don't know.
Comment 28 Jan Pazdziora (Red Hat) 2015-03-24 07:03:25 UTC 
(In reply to Omair Majid from comment #26)
> Also, would it be possible to use a non-SPNEGO GSSAPI mechanism? I am
> curious if the native gss library is ignored only for SPNEGO:
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/file/70e3553d9d6e/src/share/
> classes/sun/security/jgss/GSSManagerImpl.java#l63

Sorry, I have no idea. It is certainly possible that something explicitly turns the use of native libraries off, then the question is how to override it back or how to disable that turning off. Another question is what "native" does the useNative flag refer to.

I guess this is all part of this bugzilla -- to determine what is a bug, what is undocumented behaviour (for example SPNEGO being eager to disable use of native GSS libraries), and what is the intended behaviour going forward.
Comment 29 Omair Majid 2015-03-24 18:34:21 UTC 
(In reply to Jan Pazdziora from comment #28)
> Another question is what "native" does the useNative flag refer to.

It comes from the value of the configuration property indicated here: '<property name="sun.security.jgss.native" value="true"/>'. In other words, it determine whether OpenJDK should delegate to the native GSS implementation or not.

> I guess this is all part of this bugzilla -- to determine what is a bug,
> what is undocumented behaviour (for example SPNEGO being eager to disable
> use of native GSS libraries), and what is the intended behaviour going
> forward.

I spent some more time looking around. Here's my findings. They agree with what Elliott said in comment 8.

The test case sets up authentication using SPNEGO on top of Kerberos. That's the '<login-module code="Kerberos" flag="required">' and '<login-module code="SPNEGO" flag="required">' from the configuration file. This sets up the JBoss implementation of SPNEGO login module (org.jboss.security.negotiation.spnego.SPNEGOLoginModule), which delegates to the JBoss wrapper of Kerberos login module (org.jboss.security.negotiation.KerberosLoginModule) which in turn delegates to the JDK login module (com.sun.security.auth.module.Krb5LoginModule).

The Krb5LoginModule does not use GSS API for authentication. So it *ignores* whatever is specified with "sun.security.jgss.native".

I am not sure if this is as much undocumented behaviour as much as it is just a consequence of the implementation of security mechanisms in OpenJDK. As suggested by Elliott, a custom LoginModule can use the GSS API and work the way you want it to.
Comment 30 Omair Majid 2015-03-24 18:46:30 UTC 
On a somewhat interesting note, OpenJDK includes code for SASL authentication that delegates to GSS. It might serve as an example of how a login module might delegate to GSS.

http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/file/70e3553d9d6e/src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java#l90
Comment 31 Jan Pazdziora (Red Hat) 2015-03-25 07:57:17 UTC 
(In reply to Omair Majid from comment #29)
> 
> The test case sets up authentication using SPNEGO on top of Kerberos. That's
> the '<login-module code="Kerberos" flag="required">' and '<login-module
> code="SPNEGO" flag="required">' from the configuration file. This sets up
> the JBoss implementation of SPNEGO login module
> (org.jboss.security.negotiation.spnego.SPNEGOLoginModule), which delegates
> to the JBoss wrapper of Kerberos login module
> (org.jboss.security.negotiation.KerberosLoginModule) which in turn delegates
> to the JDK login module (com.sun.security.auth.module.Krb5LoginModule).
> 
> The Krb5LoginModule does not use GSS API for authentication. So it *ignores*
> whatever is specified with "sun.security.jgss.native".
> 
> I am not sure if this is as much undocumented behaviour as much as it is
> just a consequence of the implementation of security mechanisms in OpenJDK.

Well, I believe this is the core of this discussion -- is the fact that Krb5LoginModule does not use GSS API -- is that a documented feature, or a bug? If it's an undocumented behaviour, then either it needs to be documented, or changed.

> As suggested by Elliott, a custom LoginModule can use the GSS API and work
> the way you want it to.

Is the OpenJDK team able to create such a module and maintain it as standard feature of OpenJDK?
Comment 32 Omair Majid 2015-03-25 15:38:55 UTC 
(In reply to Jan Pazdziora from comment #31)
> Well, I believe this is the core of this discussion -- is the fact that
> Krb5LoginModule does not use GSS API -- is that a documented feature, or a
> bug? If it's an undocumented behaviour, then either it needs to be
> documented, or changed.

I think it's documented, just not very well. From http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/index.html

"JAAS can be used for [...]"

"Java GSS-API is used for [...]"

"Thus JAAS and Java GSS-API are related and often used together. However, it is possible for applications to use JAAS without Java GSS-API, and it is also possible to use Java GSS-API without JAAS. Furthermore, JAAS itself can be used simply for authentication or for both authentication and authorization."

The Krb5LoginModule is a LoginModule and therefore part of JAAS:
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASRefGuide.html#LoginModule

Therefore, it does not use GSS.

> Is the OpenJDK team able to create such a module

Very likely, but it will probably take a while. As you can tell, I am not very familiar with the security APIs.

> and maintain it as standard
> feature of OpenJDK?

Getting this accepted into OpenJDK may be even harder and take a while. If you need this fast, it may be better to implement it as part of JBoss first.
Comment 37 Elliott Baron 2017-01-12 23:12:49 UTC 
Closing due to upstream stating that Krb5LoginModule is not intended to work with GSS-API.

> When -Dsun.security.jgss.native=true is set, the Java provider is not 
> used, and whatever native GSS-API library installed in your system is 
> used. In this case, you should not call JAAS (Krb5LoginModule) to launch 
> JGSS. Instead, please call the JGSS-API directly.

http://mail.openjdk.java.net/pipermail/security-dev/2016-July/014482.html
Comment 38 Jan Pazdziora (Red Hat) 2017-01-13 09:34:17 UTC 
Any pointers for configuration examples that would setup JGSS-API with (say) jboss-eap-6.1.1.zip?
Comment 39 Elliott Baron 2017-01-13 18:48:39 UTC 
(In reply to Jan Pazdziora from comment #38)
> Any pointers for configuration examples that would setup JGSS-API with (say)
> jboss-eap-6.1.1.zip?

I believe this guide has some useful sample code for authenticating using the JGSS-API:
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/lab/part5.html

This should delegate to the native library if sun.security.jgss.native is set.
I hope this helps.
Note You need to log in before you can comment on or make changes to this bug.