Got it

Hadoop Authentication Kerberos--UserGroupInformation.doAs

Latest reply: Nov 21, 2021 15:34:10 377 2 2 0 0

Hello, everyone!

When accessing Hadoop ecosystem services with Kerberos authentication, keytab file authentication must be carried.


String userCode="user1";
String keytabPath = "./user1.keytab";
System.setProperty("", kdc); 
System.setProperty("", realm);
final Configuration conf = new Configuration();
UserGroupInformation ugi = UserGroupInformation.loginUserFromKeytabAndReturnUGI(userCode, keytabPath);
final HConnection connection;
ugi.doAs(new PrivilegedAction<Object>() {
public Object run() {
try {
connection = HConnectionManager.createConnection(conf);
} catch (IOException e) {
// TODO Auto-generated catch block
return null;

userCode indicates the user name, and keytabPath indicates the path of the keytab file. Generally, the system uses the verification file generated by the kdc to log in to the system. The system does not need to know the password.

The ugi here is the ticket of kerberos through the UserGroupInformation.loginUserFromKeytabAndReturnUGI(userCode, keytabPath); method.

After the operation succeeds, the returned ticket information can be used to access the Hadoop system without expiration.

The point is to explain why the doAs method of this ticket is used for access. First, let's look at the code of UserGroupInformation:

  public <T> T doAs(PrivilegedAction<T> action) {
    logPrivilegedAction(subject, action);
    return Subject.doAs(subject, action);

logPrivilegedAction is used to record log information. The key is Subject.doAs. In fact, this is JDK code.

public static <T> T doAs(final Subject subject,
                        final<T> action) {
        java.lang.SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
        if (action == null)
            throw new NullPointerException
        // set up the new Subject-based AccessControlContext
        // for doPrivileged
        final AccessControlContext currentAcc = AccessController.getContext();
        // call doPrivileged and push this new context on the stack
                                        createContext(subject, currentAcc));

The final code is native. According to the comments, a new context is opened. This context is initialized by subject and then invokes our connection method.

The definition is privatefinal Subject.

Why can the Hadoop cluster of Kerberos be accessed normally after the authentication method is invoked without the doAs method? Let's see the loginUserFromKeytabAndReturnUGI method.

static UserGroupInformation loginUserFromKeytabAndReturnUGI(String user,
                                  String path
                                  ) throws IOException {
    if (!isSecurityEnabled())
      return UserGroupInformation.getCurrentUser();
    String oldKeytabFile = null;
    String oldKeytabPrincipal = null;
    long start = 0;
    try {
      oldKeytabFile = keytabFile;
      oldKeytabPrincipal = keytabPrincipal;
      keytabFile = path;
      keytabPrincipal = user;
      Subject subject = new Subject();
      LoginContext login = newLoginContext(
          HadoopConfiguration.KEYTAB_KERBEROS_CONFIG_NAME, subject,
          new HadoopConfiguration());
      start =;
      metrics.loginSuccess.add( - start);
      UserGroupInformation newLoginUser = new UserGroupInformation(subject);
      return newLoginUser;
private static LoginContext   newLoginContext(String appName, Subject subject, loginConf)       throws LoginException {     
    // Temporarily switch the thread's ContextClassLoader to match this     
// class's classloader, so that we can properly load HadoopLoginModule    
 // from the JAAS libraries.     
Thread t = Thread.currentThread();     
ClassLoader oldCCL = t.getContextClassLoader(); t.setContextClassLoader(HadoopLoginModule.class.getClassLoader());     
try {       
    return new LoginContext(appName, subject, null, loginConf);     
} finally {       

The LoginContext login method switches the current thread to the subject after login, that is, the context of the current thread. If the login information is available, the doAs method is not required, and the Kerberos can be accessed normally.

However, this approach has limitations:

1. You must log in to the KDC server once to switch a user. Frequent login causes pressure on the KDC server. Kerberos tickets have a storage period. During the storage period, you do not need to log in.

2. This mode depends on the JDK. According to the practice, if you log in to the IBM JDK repeatedly, you cannot switch to a new user. You must use the doAs mode.

That's all, thanks!

  • x
  • convention:

Admin Created Nov 16, 2021 09:00:02

Thanks for your sharing!
View more
  • x
  • convention:

Created Nov 21, 2021 15:34:10

Interesting knowledge, thanks!
View more
  • x
  • convention:


You need to log in to comment to the post Login | Register

Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " User Agreement."

My Followers

Login and enjoy all the member benefits


Are you sure to block this user?
Users on your blacklist cannot comment on your post,cannot mention you, cannot send you private messages.
Please bind your phone number to obtain invitation bonus.
Information Protection Guide
Thanks for using Huawei Enterprise Support Community! We will help you learn how we collect, use, store and share your personal information and the rights you have in accordance with Privacy Policy and User Agreement.