A string which contains a number of principals can be passed to constructor of DelegationPermission. The class parses this string, and extracts principals. But hashCode() method in DelegationPermission uses Permission.getName() to calculate a hash:

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/467094c6081b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/DelegationPermission.java#l182

...
    public int hashCode() {
        return getName().hashCode();
    }
...

Permission.getName() method returns the original string which was passed to constructor. As a result, semantically equal instances of DelegationPermission may return different hash codes. A test in the webrev below reproduces the problem.

When JDK-8065942 was integrated, a problem may occur during permission check. If code has an appropriate DelegationPermission in policy file, AccessController may not take it into account because KrbDelegationPermissionCollection.implies() now uses ConcurrentHashMap.containsKey():

http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/467094c6081b

...
+    @Override
     public boolean implies(Permission permission) {
         if (! (permission instanceof DelegationPermission))
-                return false;
+            return false;
 
-        synchronized (this) {
-            for (Permission x : perms) {
-                if (x.implies(permission))
-                    return true;
-            }
-        }
-        return false;
-
+        // if map contains key, then it automatically implies it
+        return perms.containsKey(permission);
     }
... 

As a result, ACE may be thrown even if code has a correct permission in policy file.

The following patch seems to fix the issue:

http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.00/