[GLASSFISH-18536] GF callback handler blocking a JASPIC provider when Principal is unknown Created: 21/Mar/12  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: future release

Type: Bug Priority: Blocker
Reporter: bjb Assignee: JeffTancill
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Windows 2008 64bits

Tags: JASPIC, blocking, groups, principal, unknown, users


When sending an unknown Principal (principal not valid as per a local JAAS config) but valid on a global perspective (all checks was done in the JASPIC provider), the GF CallerPrincipal handler will throw a blocking exception in the process :

com.sun.enterprise.security.auth.realm.NoSuchUserException: Cet utilisateur [USER@INTRA-DEV01.DOMAIN-DEV01.LOCAL] n'existe pas. at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:329) at com.sun.enterprise.security.auth.login.LoginContextDriver.jmacLogin(LoginContextDriver.java:566) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallerPrincipal(BaseContainerCallbackHandler.java:257) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallback(BaseContainerCallbackHandler.java:197) at com.sun.enterprise.security.jmac.callback.ServerContainerCallbackHandler.handleSupportedCallbacks(ServerContainerCallbackHandler.java:76) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.handle(BaseContainerCallbackHandler.java:187) at com.sun.enterprise.security.jmac.callback.ContainerCallbackHandler.handle(ContainerCallbackHandler.java:83) at net.java.spnego.PACSpnegoServerAuthModule.updateCallerPrincipal(PACSpnegoServerAuthModule.java:550) at net.java.spnego.PACSpnegoServerAuthModule.validateRequest(PACSpnegoServerAuthModule.java:354) at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1171) at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1445) at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1323) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623) at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)

The problem is that groups that were provided before with a call to the GF handler (Group handler) is not used but insteand GF access the default realm (file) to fetch the user's groups.

This is blocking usage of non-JAAS bridge profile JASPIC providers.

To lower the state of this issue, either fix the issue or provide a way to bypass this issue.

Comment by bjb [ 24/Mar/12 ]

Hi Kumar,

Please lower the priority level as it is actually not blocking but only misleading.

It will not block non-JAAS bridge but simply push a wrong track to people debugging.

The core issue has been logged as :

When runing in JASPIC mode, such an issue should not be raised.


Comment by kumarjayanti [ 25/Mar/12 ]

This issue does sound like it needs a fix. The caller principal callback is trying to do an identity assertion in this case forcing people to also configure a realm that can be used to fetch the groups of the user. This was done to meet requirements of some other usecases but now i realize this is not appropriate. Instead the Group Principal Callback should be explicitly used in this case.

I will fix this for 3.1.2 Patch releases and glassfish trunk.

Thanks for raising this issue.

Comment by arjan tijms [ 13/Apr/13 ]

Is this still the same issue as reported? I've done a lot of JASPIC testing with GlassFish but never encountered this issue. There is something fishy going on though.

The caller principal callback is trying to do an identity assertion in this case

I think you mean the caller principal callback handler right? Since the caller principal callback is a very simple DTO style class that only stores the Subject and the Principal or Name.

The handler (in BaseContainerCallbackHandler.processCallerPrincipal) does a call to the LoginContextDriver, but it itself does not do any identity assertion:

if (isCertRealm) {
    if (principal  instanceof X500Principal) {
        LoginContextDriver.jmacLogin(fs, (X500Principal)principal);
} else {
    if (!principal.equals(SecurityContext.getDefaultCallerPrincipal())) {
        LoginContextDriver.jmacLogin(fs, principal.getName(), realmName);

The LoginContextDriver.jmacLogin however does attempt to do this:

 public static Subject jmacLogin(Subject subject, String identityAssertion, String realm) throws LoginException {

        if (subject == null) {
            subject = new Subject();
        final Subject fs = subject;
        String userName = identityAssertion;

        try {
            if (realm == null || "".equals(realm)) {
                realm = Realm.getDefaultRealm();
            Realm realmInst = Realm.getInstance(realm);
            final Enumeration groups = realmInst.getGroupNames(userName);
            if (groups != null && groups.hasMoreElements()) {
                AppservAccessController.doPrivileged(new PrivilegedAction() {

                    public java.lang.Object run() {
                        while (groups.hasMoreElements()) {
                            String grp = (String) groups.nextElement();
                            fs.getPrincipals().add(new Group(grp));
                        return fs;
        } catch (Exception ex) {
            if (_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE, "Exception when trying to populate groups for CallerPrincipal " + identityAssertion, ex);
        return subject;

When using JASPIC, the passed in realm will be "" and when that happens this method obtains the default realm ("file") and tries to get the group names from that (realmInst.getGroupNames(userName);).

If this throws an exception (in my testing a NPE is typically thrown) it is ignored by the catch, so the problem as described for this issue doesn't seem to occur anymore (that is, the exception is still thrown, but it doesn't interrupt the authentication flow).

I'm afraid though that if I happened to have this file realm defined with a user that happened to have the same name as the user I'm trying to authenticate with JASPIC, that this user would suddenly get a set of extra roles. If my application happened to have roles with the same name, then this could be a rather big problem.

Generated at Fri Oct 28 22:08:25 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.