directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Hedrick (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DIRAPI-350) gssapi documentation
Date Thu, 11 Jul 2019 15:43:00 GMT

    [ https://issues.apache.org/jira/browse/DIRAPI-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883088#comment-16883088
] 

Charles Hedrick edited comment on DIRAPI-350 at 7/11/19 3:42 PM:
-----------------------------------------------------------------

Note that there's a reference in documentation to bindSaslGssApi(). It does not appear to
exist. I'm not sure quite what it would do. There are enough options for GSSAPI that creating
a SaslGssApiRequest and using bind might make sense.

 

There are some limitations to the Sun implementation of Kerberos that you may or may not want
to document: 

There are potential thread-safety issues with krb5ConfFIlePath. This is set in a system property.
If you use setKrb5ConfFilePath, or realmName, kdcHost, and kdcPort, this will affect the
entire application. Even if you don't, the system variable is cleared. This could also affect
the entire application. Basically, if your program is threaded, you need to use a consistent
setting for the krb5ConfFIlePath, not just in Kirby but in any code the depends upon Kerberos.
Even without multiple threads you could have an issue if other code sets a value and expects
it to remain unchanged.

The same issue could occur with the system property  javax.security.auth.useSubjectCredsOnly.
This code sets it false. If code other than Kirby is using Kerberos, and relies on a different
setting, there could be interference.

As noted in my sample code, this implementation can only read credential caches that are in
files. Many operating systems today use KEYRING or KCM. If your application needs to use existsing
user credential caches without prompting for a password, you may need to set  default_cc_name
in /etc/krb5.conf to a file in /tmp.

 


was (Author: clhedrick):
Note that there's a reference in documentation to bindSaslGssApi(). It does not appear to
exist. I'm not sure quite what it would do. There are enough options for GSSAPI that creating
a SaslGssApiRequest and using bind might make sense.

 

There are some limitations to the Sun implementation of Kerberos that you may or may not want
to document: 

There are potential thread-safety issues with krb5ConfFIlePath. This is set in a system property.
If you use setKrb5ConfFilePath, or realmName, kdcHost, and kdcPort, this will affect the
entire application. Even if you don't, the system variable is cleared. This could also affect
the entire application. Basically, if your program is threaded, you need to use a consistent
setting for the krb5ConfFIlePath, not just in Kirby but in any code the depends upon Kerberos.

The same issue could occur with the system property  javax.security.auth.useSubjectCredsOnly.
This code sets it false. If code other than Kirby is using Kerberos, and relies on a different
setting, there could be interference.

As noted in my sample code, this implementation can only read credential caches that are in
files. Many operating systems today use KEYRING or KCM. If your application needs to use existsing
user credential caches without prompting for a password, you may need to set  default_cc_name
in /etc/krb5.conf to a file in /tmp.

 

> gssapi documentation
> --------------------
>
>                 Key: DIRAPI-350
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-350
>             Project: Directory Client API
>          Issue Type: Documentation
>    Affects Versions: 2.0.0.AM4
>            Reporter: Charles Hedrick
>            Priority: Major
>         Attachments: gssapi.rtf
>
>
> In the section on authentication, there is no usable documentation for GSSAPI. Since
GSSAPI is mostly used for Kerberos, you need sample code. Here is some that works.
> First, non-trivial Kerberos authentication requires configuration. Creating a Kerberos
configuration is not well documented elsewhere, so we include here sample code. It is possible
to put configuration information in a JAAS login configuration file as well, but doing it
programmatically provides more flexibiity for appications that need to use more than one principal.
> {code:java}
>     import javax.security.auth.login.Configuration;
>     class KerberosConfiguration extends Configuration {
>         private String cc;
>         public KerberosConfiguration(String cc) {
>             this.cc = cc;
>         }
>         @Override
>         public AppConfigurationEntry[] getAppConfigurationEntry(String name) {
>             Map<String, String> options = new HashMap<String, String>();
>             options.put("useKeyTab", "true");
>             try {
>                 options.put("principal", "host/" + InetAddress.getLocalHost().getCanonicalHostName()
+ "@MYKERBOSDOMAIN");
>             } catch (Exception e){
>                 System.out.println("Can't find our hostname " + e);
>             }
>             options.put("refreshKrb5Config", "true");
>             options.put("keyTab", "/etc/krb5.keytab");
>             options.put("debug", "true");
>            return new AppConfigurationEntry[]{
>                 new AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
>                                           AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
>                                           options),};
>         }
>  }
>  public KerberosConfiguration makeKerberosConfiguration(String cc) {
>        return new KerberosConfiguration(cc);
>  }
> {code}
>  
> makeKerberosConfiguration(null) will return the configuration object needed for GSSAPI.
The options in this example authenticate the host, based on /etc/krb5.keytab. Other options
are documented in the Java documentation for the class Krb5LoginModule. Note that if you
are going to use user credentials, they should be stored in a file, not KEYRING or KCM.
>  
> The following code uses a configuration generated with the code above to do a GSSAPI
SASL bind. The assumption is that ldapNetworkConnection has already been opened using connect
> {code:java}
>         Configuration sconfig = makeKerberosConfiguration(null);
>         SaslGssApiRequest saslGssApiRequestt = new SaslGssApiRequest();
>         saslGssApiRequest.setLoginModuleConfiguration( sconfig);
>         saslGssApiRequest.setLoginContextName( "org.apache.directory.ldap.client.api.SaslGssApiRequest"
);
>         saslGssApiRequest.setMutualAuthentication( false );
>  
>         BindResponse br;
>  
>         try {
>                 br = ldapNetworkConnection.bind( saslGssApiRequest );
>                 ldapNetworkConnection.startTls();
>          } catch ( LdapException e ) {
>                 e.printStackTrace();
>         }
> {code}
> At this point you can do search or other operations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org


Mime
View raw message