2

When working with the Oracle JDK it is possible to take a 'org.ietf.jgss.GSSCredential' and use the class 'com.sun.security.jgss.GSSUtil.class' to create a Subject from this.

What I am looking for is how to achieve the equivalent using the IBM JDK.

On the Oracle JDK the Subject that is obtained is then used in a Subject.doAs call for an ongoing outbound connection but I can not achieve this on IBM as I can not convert the GSSCredential to a usable Subject.

I have seen the following IBM ticket but I can not see how the SPI class they mention provides this: - http://www-01.ibm.com/support/docview.wss?uid=swg1IZ45390

Darran L
  • 922
  • 1
  • 8
  • 14

3 Answers3

0

The source code of the OpenJDK version of GSSUtil is available online. Looking at the code (and the comments) you can see it relies on package private APIs of the Sun's implementations of GSSName and GSSCredential, specifically: GSSNameImpl, GSSNameSpi, Krb5NameElement and GSSCredentialImpl.
The IBM Java SDK ibmjgssprovider.jar contains similar IBM implementations which can be used to achieve the same functionality. Take a look at the com.ibm.security.jgss and com.ibm.security.krb5 packages.

Dror Bereznitsky
  • 20,048
  • 3
  • 48
  • 57
  • Thank but I have tried that approach, if I could write my own implementation of GSSUtil I would consider that but digging into even the internal APIs that I could discover the IBMs implementation of GSSCredential is substantially different with no way to even get to the required classes. – Darran L Mar 27 '14 at 15:36
0

They way you work is incorrect! Never use private classes and the GSSUtil is a private one. What you should do is

Subject sub = new Subject();
sub.getPrivateCredentials().add(gssCredential);
...
Subject.doAs(sub, action);
Michael-O
  • 18,123
  • 6
  • 55
  • 121
  • Unfortunately this approach does not work as there is code that relies on the private credentials of the Subject containing a KerberosTicket and not a GSSCredential such as JDBC drivers from Oracle. – Darran L Apr 01 '14 at 10:10
  • @DarranL, if the Oracle driver requires a private API class, then it is ill-designed. You should file a ticket with Oracle. This is what I have been doing for several JDBC bugs via My Oracle Support. – Michael-O Apr 01 '14 at 11:16
  • But if you take the alternative approach and call a LoginContext configured with the Krb5LoginModule to populate the Subject before using it in a doAs call which obtains a database connection the login module does not add a GSSCredential to the private credentials so if the driver expected it then it would be missing for that scenario. – Darran L Apr 02 '14 at 10:32
  • This makes no sense because the Driver should hand-off everything to the JGSS context. The internal implementations are fine using private API as long as they are consistent but the Driver is an exernal JAR which should know external APIs only. – Michael-O Apr 02 '14 at 11:03
  • What should happen and what actually happens seem to be different things in this area ;-) – Darran L Apr 02 '14 at 16:37
  • @DarranL, you *must* file a bug with Oracle. This is the only way to have it fixed. – Michael-O Apr 02 '14 at 18:51
0
  1. From com.ibm.security.jgss.GSSCredentialImpl object to get com.ibm.security.jgss.spi.GSSCredentialSpi object.
  2. Find com.ibm.security.krb5.Credentials object in GSSCredentialSpi object.
  3. Call com.ibm.security.jgss.mech.krb5.Krb5Util.credsToTicket(Credentials) to create KerberosTicket
  4. The final step is to use KerberosTicket object plus KerberosPrincipal to create a subject object.
Maneesha Indrachapa
  • 882
  • 5
  • 18
YC Chen
  • 1
  • 1