[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
Environment:

Windows 2008 64bits


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

 Description   

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.



 Comments   
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 :
http://java.net/jira/browse/GLASSFISH-18556

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

Rgs,
JB

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 3.1.2.2 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.





[GLASSFISH-12462] server crashes: CORBA NO_PERMISSION Created: 02/Jul/10  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: lft Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Attachments: Zip Archive mem.zip     Text File server.log_2010-09-17T18-00-08    
Issuezilla Id: 12,462
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-next, 3_1_1-scrubbed

 Description   

Some times during nomal working of GF server (v 3.0.1) log messages like this
appears:
[#|2010-07-01T21:04:34.856+0400|SEVERE|glassfish3.0.1|FRUITCOCTAIL_15985.openbox.fruitcoctail._FruitCoctailSlotMachineBean_Serializable|_ThreadID=272;_ThreadName=Thread-1;|The
log message is null.
javax.ejb.EJBAccessException
at
openbox.session._SessionFacade_Wrapper.getCredit(openbox/session/_SessionFacade_Wrapper.java)
at openbox.core.component.GameComponent.getCredit(GameComponent.java:46)
at
openbox.core.slotmachine.AbstractSlotMachineMath.setPickedLineCount(AbstractSlotMachineMath.java:165)
at
openbox.fruitcoctail.FruitCoctailSlotMachineBean.setPickedLineCount(FruitCoctailSlotMachineBean.java:227)
at sun.reflect.GeneratedMethodAccessor1042.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1056)
at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1128)
at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4087)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5272)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5252)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:201)
at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:75)
at $Proxy266.setPickedLineCount(Unknown Source)
at sun.reflect.GeneratedMethodAccessor1041.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: java.rmi.AccessException: CORBA NO_PERMISSION 9998 Maybe; nested
exception is:
org.omg.CORBA.NO_PERMISSION: ----------BEGIN server-side stack
trace----------
org.omg.CORBA.NO_PERMISSION: vmcid: 0x2000 minor code: 1806 completed: Maybe

at
org.glassfish.enterprise.iiop.impl.POAProtocolMgr.mapException(POAProtocolMgr.java:294)

at
com.sun.ejb.containers.BaseContainer.mapRemoteException(BaseContainer.java:2212)

at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2042)

at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1955)

at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:208)

at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:75)

at $Proxy184.getCredit(Unknown Source)

at sun.reflect.GeneratedMethodAccessor174.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)

at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)

at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)

at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)

at
com.sun.corba.ee.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:119)

at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:235)

at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:187)

at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:147)

at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:225)

at
openbox.session._SessionFacade_Remote_DynamicStub.getCredit(openbox/session/_SessionFacade_Remote_DynamicStub.java)

at
openbox.session._SessionFacade_Wrapper.getCredit(openbox/session/_SessionFacade_Wrapper.java)

at openbox.core.component.GameComponent.getCredit(GameComponent.java:46)

at
openbox.core.slotmachine.AbstractSlotMachineMath.setPickedLineCount(AbstractSlotMachineMath.java:165)

at
openbox.fruitcoctail.FruitCoctailSlotMachineBean.setPickedLineCount(FruitCoctailSlotMachineBean.java:227)

at sun.reflect.GeneratedMethodAccessor1042.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1056)

at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1128)

at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4087)

at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5272)

at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5252)

at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:201)

at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:75)

at $Proxy266.setPickedLineCount(Unknown Source)

at sun.reflect.GeneratedMethodAccessor1041.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)

at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)

at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)

at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)

at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)

at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)

at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)

Caused by: javax.ejb.AccessLocalException: Client not authorized for this
invocation.

at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1850)

at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:200)

... 47 more

---------END server-side stack trace--------- vmcid: 0x2000 minor code: 1806
completed: Maybe

at
com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:276)

at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)

at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:147)

at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:225)

at
openbox.session._SessionFacade_Remote_DynamicStub.getCredit(openbox/session/_SessionFacade_Remote_DynamicStub.java)

... 31 more

…

It appears during calling of methods stateless bean from stateful bean marked
with @RunAs in that places of code where in another case it works without
problems. I have already issued this bug ealier. So I have created workaround
for this bug: just place calling of this methods in loop which exits after 3
tryes or when EJBAccessException is absent. Now I have another problem:
Sometimes this exception starts to be continual (every time when perfoming call
to stateless bean). So application clients just can't continue working cause
this bean is central logic bean of all application. Only domain restart helps.
Domain is production, application is in production use. So just restarting is
not acceptable solution. We don't wont to migrate to the jboss, but this bug
doesn't allow to use GF 3.0.1 as production application server.

P.S. We using jdbcRealm with oracle databse.



 Comments   
Comment by Tom Mueller [ 08/Jul/10 ]

Looks EJB related.

Comment by lft [ 16/Jul/10 ]

No news about this problem? We have to reboot gf server every day. Beacuase it
can't run more than one day without crashing. We tried to declare application
roles in deployment descriptor. The problem persists. So we don't now what to do
now.

Comment by kumarjayanti [ 16/Jul/10 ]

Can u help us reproduce this with a small testcase.

Comment by lft [ 17/Jul/10 ]

I'd love to. But i can't. I don't know why this messages sometimes become cyclic.
I'll try to describe simplified model of my application. There is central
stateless bean (1) that manages abstract user session — it called SessionFacade.
It works with entities that packed with this bean in separate jar file. This
central bean has methods. Some of its methods are accessible for authenticated
clients (we use ProgrammaticLogin) and some for specific role 'COMPONENT'. There
are another (2) beans (stateful). This beans are accessible for authenticated
clients and marked with @RunAs ('COMPONENT-USER'), where COMPONENT-USER is
user of group 'COMPONENT', so every call they make to central bean uses
«COMPONENT» role.
EJBAccessException occurs during calling methods of (1)-st bean from methods of
(2)-nd bean. It seems like @RunAs does not works.
Additional information: we use GF 3.0.1, Oracle database 10.2.0.5, jdbcRealm.
PS I turned on jdbc monitoring, and I sess great values for metrics named
NumConnReleased and NumConnAcquired (about 1795846 for a day). It'is logical
connection, but is it normal?

Comment by lft [ 19/Jul/10 ]

We have another problem that disturbs us and that I was planned to report as
separate issue. But today I thought maybe it some kind related to this thread.
Description of problem: We use ProgrammaticLogin for authentication of
standalone-client applications as I mentioned earlier. After successful loging
in the first call to secure (or unsecure - doesn't matter in this case as we
have tested) EJB method continues for a abnormal long time (up to 30 seconds)
after that other methods or the same method are fast enough (< 1 sec.).

Comment by lft [ 17/Aug/10 ]

Now I'm almost sure this is memory related problem. When I increased Xmx startup
parameter from 512M to 1024M the problem disappeared. When I decreased it again
the problem came back.
I have two identical servers (All hardware and software are identical) with value
512m for Xmx. But numbers of possble parralel sessions are 5 and 10 for the first
and the second. First one works fine without errors. The second can't work more
then 1 day without restart.
I hope this inforation will be useful.

Comment by kumarjayanti [ 08/Sep/10 ]

Hi,

Can you provide a heap-dump that i can analyze ?. Have you tried with latest
builds of V3.1 to see if the problem goes away ?. I have to get a resolution on
this bug soon.

thanks.

Comment by lft [ 08/Sep/10 ]

About my previous post: now I don't think it's memory related problem. I have
monitored gc with -Xloggc option and figurted out that heap jvm memory doesn't
hit -Xmx value . After numbers of experiments It's seems to be jdbc related
problem (jdbcRealm).But I'm in doubt about it. I set 64 initial pool connections
for jdbc connection pool (default is 8), and this error does not happens for two
weeks.

kumarjayanti, I'll try to provide a heap-dump for you next time this error
appears. About GF V3.1 - we can't migrate our production servers to this version
cause it's not stable (as glassfish official site says) and we also can't
reproduce this error on test servers in not prodution enviroment cause it's not
predictable.

Comment by lft [ 08/Sep/10 ]

kumarjayanti, what tool should I use to generate heap dump? What format do you
prefer?

Comment by lft [ 13/Sep/10 ]

One of our servers crashed today with this bug and unfortunately I had no jdk
installed on that server to create heap dump. I needed to make server works
properly as quickly as possible. So I restarted it and only thing I had time to
do is to save linux process memory dump (cat /proc/<pid>/smaps). I'll install
jdk on every server to be able to make core dump next time. This time I'm
posting only linux format process memory dump.

Comment by lft [ 13/Sep/10 ]

Created an attachment (id=4870)
linux-format process dump

Comment by kumarjayanti [ 14/Sep/10 ]

Thanks for the dmp file but i am sorry to say i was not able to make much sense.

I need to know the following :
1. When you say server crash is there actually a Core Dump ?.
2. is there an error of the form OutofMemoryError : Heap Space
3. What does the sever.log at the time of the crash.

Can you please follow this one :
http://blogs.sun.com/alanb/entry/heap_dumps_are_back_with

And provide me a .hprof file (java_pidXXX.hprof) that i can later analyze with jhat.

Do you have anyother tools at your disposal that can pinpoint the problem to us.

Thanks for your patience.

Comment by lft [ 14/Sep/10 ]

1) When I say "server crashes" - I don't mean JVM crash. Glassfish server
continues to work but all deployed EJB applications becomes unusefull.
2) No there is no error like "OutofMemoryError" and I don't think it's
out-of-memory issue.
3) The server.log is full of "CORBA.NO_PERMISSION" messages (see my first post).
After this happens, every time someone call ejb method, message like that I
posted earlier is wrote down to server.log

AS I sad I had no JDK at the moment on remote server, next time i'll use jmap to
generate heap dump (jmap -dump:file=... <pid>). Thanks that you don't ignore our
issue.

Comment by kumarjayanti [ 15/Sep/10 ]

Since this is not a memory issue i don't need the Heap Dump any more. Can you
attach the full server log when the error starts happening. Do you see the word
"purged connections..." in the logs.

Does the error happen under heavy load ?. Do you suspect it is a multithreaded
access bug ?.

The orb uses thread-pool-1 by default and it's max pool size is 200 (in V3.1).
Do you think it will help to increase this size a bit to say 500 ?.

Comment by lft [ 15/Sep/10 ]

> Can you attach the full server log when the error starts happening.
Yes, I'll provide server.log
> Do you see the word "purged connections..." in the logs.
no, I don't see anything like this
> Does the error happen under heavy load ?.
It seems to me that error happen when number of parralel sessions (and threads)
increases rapidly, but I'm not shure about it.
> Do you suspect it is a multithreaded access bug ?.
May be.
> The orb uses thread-pool-1 by default and it's max pool size is 200 (in V3.1).
> Do you think it will help to increase this size a bit to say 500 ?.
I'm not shure this is thread-pool issue and not jdbc-pool issue. As I said
earlier increasing initial connections in jdbc-pool (that used both for entity
beans communication with DB and for security with jdbcRealm) maked error hapen
rarely.
I can turn on monitoring for thread pool to check out thread pool using.

Comment by lft [ 18/Sep/10 ]

Created an attachment (id=4920)
server.log_2010-09-17T18-00-08

Comment by lft [ 18/Sep/10 ]

This is one of the server logs. Logs are changing once a minute. So I decided to
post here only first one. The rest contain same exceptions.

Comment by kumarjayanti [ 30/Sep/10 ]
      • Issue 12115 has been marked as a duplicate of this issue. ***
Comment by kumarjayanti [ 04/Oct/10 ]

Can you attach the granted.policy file and exclude.policy file (if any) that get generated when you deploy
this application.

Thanks.

Comment by lft [ 04/Oct/10 ]

kumarjayanti, I sent logs and policy configs to you via e-mail.

Comment by kumarjayanti [ 06/Oct/10 ]

Will try to fix by V3.1 MS07. The main problem with this issue is the user/customer is not using V3.1 (but
V3.0.1 instead) and the issue cannot be reproduced except in Production.

Have gathered relevant information from the user and now need to investigate manually and see if there is
a problem somewhere. Again after a fix it is not clear how the user can test it unless V3.1 is used, because
a fix in V3.0.1 will only be made as a patch for GlassFish Customers.

Comment by lft [ 06/Oct/10 ]

kumarjayanti ,
Ok. We created script that reboots server every 12 hours when there is no user
sessions. So now we can wait for 3.1 release. But how can you be shure that this
problem will be fixed in 3.1 release. Do you have any suggestions about root
cause of this issue?

Comment by lft [ 06/Oct/10 ]

thanx again that you don't ignore this issue.

Comment by kumarjayanti [ 06/Oct/10 ]

--------
But how can you be shure that this
problem will be fixed in 3.1 release. Do you have any suggestions about root
cause of this issue?
--------

I can't be sure unless you confirm it by using it .
But first i have to analyze all the data u provided to see if i can get to the root cause. Will let u know.

The updates to the bug i did earlier today in terms of setting target milestone etc are project
management requirements that i need to comply with for the upcoming V3.1 release.

Comment by kumarjayanti [ 06/Oct/10 ]

--------
But how can you be shure that this
problem will be fixed in 3.1 release. Do you have any suggestions about root
cause of this issue?
--------

I can't be sure unless you confirm it by using it .
But first i have to analyze all the data u provided to see if i can get to the root cause. Will let u know.

The updates to the bug i did earlier today in terms of setting target milestone etc are project
management requirements that i need to comply with for the upcoming V3.1 release.

Comment by kumarjayanti [ 19/Nov/10 ]

would like to spend time during ms-08 to see if we can find some issue. Since we cannot reproduce this
problem at our end the only way to find some issue is to analyze the code and the logs and generated
policy sent by the user.

Comment by kumarjayanti [ 13/Apr/11 ]

Hi,

Can you verify if this problem exists with the V3.1 release and send us a way to reproduce this.





[GLASSFISH-6781] Active Directory Realm Created: 15/Nov/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Critical
Reporter: mkarg Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,781

 Description   

A lot of operational GlassFishs are swimming in Windows Domains. One idea of
such a Windows Domain is the central user management, based on Microsoft's
Active Directory. So it would be great if the Windows GF Installer would create
an Active Directory Realm by default – just as a lots of "native" Windows
Service like "Exchange" or "MS SQL Server" are doing. Windows Administrators
dislike both, the idea that they must add each user to the domain PLUS
GlassFish's Realm, also the idea that they must set up a Active Directory Realm
manually while they run a specialized Windows-aware installer (that knows that a
AD is in use since the Windows API will tell it).



 Comments   
Comment by mkarg [ 27/Apr/09 ]

This is not a bug but a feature request, so I changed the issue type from DEFECT
to FEATURE.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5819] Rework Security Infrastructure to ease migration Created: 02/Sep/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: barz26 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,819

 Description   

Scenario: Rich Client accessing multiple clustered glassfish servers hosting
secured EJB components with RMI/IIOP.

Problem with current glassfish implementation:

  • The Client side security context is held as thread local / instance variable.
  • Thus if a client needs to access 2 ejbs that are hosted on different servers
    you have a calling sequence like this (simplified):
    ProgrammaticLogin.login(user1,pwd1)
    LookupAndCallEJB1onCluster1()
    logout
    ProgrammaticLogin.login(user2,pwd2)
    LookupAndCallEJB2onCluster2()
    logout

Other application servers like jboss bind the SecurityContext to the
InitialContext and thus allow calling sequences like this:

ProgrammaticLogin.login(user1,pwd1)
ProgrammaticLogin.login(user2,pwd2)
LookupAndCallEJB1onCluster1()
LookupAndCallEJB2onCluster2()
logout

So this RFE asks for
a) a possibility to hand over user+credential information as InitialContext
Properties like with JBOss
(http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch3.chapter.html#d0e9261)

b) a binding of the Client side security context to the InitialContext instead
of holding it as ThreadLocal or inside of ClientSecurityContext



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4119] Unified Authorization support for Servlet, SipServlet, JAX-RS and WSIT WebServices Created: 07/Feb/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Critical
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,119
Status Whiteboard:

v3-prd-item


 Description   

Unified Authorization support for Servlet, SipServlet, JAX-RS and WSIT
WebServices.

  • Support @RolesAllowed Annoation,
  • unified credential representation.
  • API in addition to getUserPrincipal() and isUserInRole() that allows
    Annotaions to be evaluated at runtime.


 Comments   
Comment by kumarjayanti [ 07/Feb/08 ]

V3-PRD-ITem

Comment by kumarjayanti [ 07/Apr/08 ]

marking as FEATURE

Comment by kumarjayanti [ 03/Sep/09 ]

Fixed. JAX-RS uses a delegation model, for WSIT WebServices the support for
annotations is not in the specs. A proprietary impl may be attempted in V3.1

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5109] Form Based Logins for secured resources don't pass the entire request object to servlet filters Created: 05/Jun/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: vpower Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,109

 Description   

We are in the process of planning the move of our applications from our custom authentication
framework which lives on WebSphere with our apps to OpenSSO and Glassfish. It would make our lives
much easier if we could deep link into applications (like directly to http://server:8080/app/page.jsp?
attr=value), but this isn't possible due to how the servlet container hands off requests to servlet filters
of protected resources.

Here is a nicely written description of the issue that I would love to see resolved:

"The reason is that the j2ee agent is configured as a servlet filter in
the webapp. If the resource is protected by Form Based Login, then the
container gets the request before the agent does. The container then
sends out a form based login request, the agent intercepts this request
instead of the original one. Before doing a redirect, the agent tries to
get the original resource url, if the container doesn't have an
interface to provide such information, then agent can only set the goto
url to the webapp's root context." - Hua.Cui (at) Sun

and

"We have a servlet filter that intercepts requests, so for FBL, the
container gets request first and does some stuff and then our filter is
invoked after on the FBL request, so at this point container handled
original request and that point we intercept and take over the FBL
request so that is the url we see, and what we need is a way to call
into the internal session and get the original target url that is set." - Sean.Brydon (at) Sun



 Comments   
Comment by jfarcand [ 29/Aug/08 ]

Make a pass to security team.

Comment by kumarjayanti [ 01/Sep/08 ]

Have you tried integrating your J2ee Agent as a JSR 196 SAM. Please see the
following :

http://blogs.sun.com/enterprisetechtips/entry/adding_authentication_mechanisms_to_the
http://blogs.sun.com/monzillo/entry/pluggable_authentication_in_the_glassfish

If you are satisified with this approach please let us know if we can close the
issue.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5371] Allow custom certificate realms Created: 23/Jul/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: barz26 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 5,371

 Description   

Currently several parts of GF security infrastructure rely on the bundled
certificate realm. That class is declared final and can not be extended nor are
there any plugin hooks in there to allow for custom behavior.

This causes migration issues and limits flexibility. See the following threads
for customer use cases:
http://forums.java.net/jive/thread.jspa?messageID=285352
http://forums.java.net/jive/thread.jspa?messageID=274381

Also it would be nice to be able swap out the certificate realm to a custom one
and use that as backend for WSIT/Metro security features instead of JSR-196
callbacks.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4216] gfv3:WebServices Asynchrony Support Created: 17/Feb/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Critical
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,216
Status Whiteboard:

v3-prd-item


 Description   

Convert GlassFish/WSIT Security Pipes to Tubes to satisfy asynchrony
requirments. Pipes are synchronous.



 Comments   
Comment by kumarjayanti [ 17/Feb/08 ]

marking v3-prd-item

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4217] gfv3:Improve JNDI Security Created: 17/Feb/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Critical
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,217
Status Whiteboard:

v3-prd-item


 Description   

Improve JNDI Security, Support for ReadOnly repository and the need to
differentiate global vs local repository and who is authorized to write.



 Comments   
Comment by kumarjayanti [ 17/Feb/08 ]

marking as v3-prd-item

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4213] gfv3:Add Certificate Repository support Created: 17/Feb/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Critical
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,213
Status Whiteboard:

v3-prd-item


 Description   

Add Certificate repository
Support id based public key lookups as required for xml digital signing and
encryption. Facilitate integration of Directory Server (if appropriate) to serve
as a certificate repository. Support issuer serial, subjet key identifier, and
thumbprint based lookups of public keys. In the absence of reliance on directory
server lookup certificate entries in keystore not truststore.
Currently we ask developers to store Non-CA third party certificates in the
TrustStore.



 Comments   
Comment by kumarjayanti [ 17/Feb/08 ]

CertStore Support in V3. V3-PRD-ITEM

Comment by kumarjayanti [ 17/Feb/08 ]

changing IssueType to FEATURE

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-18556] Characters out of JASPIC GroupPrincipalCallback Created: 24/Mar/12  Updated: 24/Apr/14

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

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

Attachments: Java Source File PolicyFileTest.java    
Tags: JASPIC, character, exception, group, restriction

 Description   

At this time, not all the characters can be used in a group set by GroupPrincipal callback.

Using thoses character will result into bad PolicyFile with non matching rule.

As a consequence, user will not be granted access as per the JACC checks.

(no exception raised, lowering the log level will result into unrelated exception beeing traced as a wrong track)

Example of such a group is :

ROLE_\01\05\00\00\00\00\00\05\15\00\00\00\8a\16\77\12\f6\70\d2\67\92\01\99\5a\b2\34\00\00

Issues here are the backslash () but I anticipate other characters could be at risks.

AFAIK, at this time there is no restricted character requirement as per JASPIC on the group.



 Comments   
Comment by kumarjayanti [ 25/Mar/12 ]

Will try to get comments from Ron on this.

Comment by bjb [ 26/Mar/12 ]

In the PolicyFile, the parseGrantEntry call

e.codeBase = match("quoted string");

But \ was configure as a quote char !

The internal java.io.StreamTokenizer indicates in line 635, that if a \ is used this is for escaping : C style or octal/hexa. But line 661+ there is no search for a second
to be reaplced by a single \ (aka '
') !

So the problem is whatever we do around \ char we will not get a bijective result (writer/parser).

But I've found reference saying that double backslash was used in PolicyFile as single backslash
http://www.eli.sdsu.edu/courses/spring99/cs696/notes/security/security.html
But I have not found that in the JDK code.

I will see to create a simple testcase for this PolicyFile corner case.
If it confirms my assumptions, I will open a JDK bug.

Until, it is fixes, the \ is a char that should be prohibited from group valid characters until we get the StreamTokenizer fixed

Anyway the domain of values for a name and the bijective nature of PolicyFile has to be confirmed from the JVM team.

Comment by bjb [ 26/Mar/12 ]

I've create a JUnit test case to show the JDK bug :

http://pastebin.com/HxmQJWmk

Comment by monzillo [ 26/Mar/12 ]

http://docs.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html

please see section entitled "Win32 Systems, File Paths, and Property Expansion"

Although I do not think what you are seeing is win32 specific, it seems that you must escape the "\" (when it occurs in your group or role names) with a preceding "\".

Comment by bjb [ 26/Mar/12 ]

JUnit test case to show the issue

Comment by bjb [ 26/Mar/12 ]

I think this has nothing to do with platformspecific as the test I have performed is "in memory" only (see version 2 attached in jira).

First the Policy Writer parser does not use double backslash for the backslash escaping while writing (cf generated policy file from GF).

Then, I can not use multiple escape as the parser (streamtokenizer from James ;P ) did not implement the double backslash escaping as usual in C :
http://en.wikipedia.org/wiki/C_syntax#Backslash_escapes

Most backslashes escapes are handled in the stream tokenizer but the escape of the backslash it self apparently.

I've submit another test case suit with triple (double 1/2) and quadruple (real double) backslash. Only the first test with single backslash (aka octet value) works.





[GLASSFISH-21313] Ordering of Cipher Suites kills Forward Secrecy with major browsers Created: 23/Feb/15  Updated: 23/Feb/15

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

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

Ubuntu 14.04 LTS Server x64, java 1.8.0_31 + JCE Unlimited Strength, GlassFish Server Open Source Edition 4.1 (build 13)


Tags: ciper, forward, order,, secrecy, suites,

 Description   

https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy

This is the list of supported cipher suites (when disabling RC4 via JSSE) as received via "asadmin list-supported-cipher-suites" (see below).
As you can see the following cipher suites are nor really "top listed", which means that for major browsers Forward Secrecy is disabled because the selected cipher suite does not support it:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
there are some more...

Here is a list of some of the affected browsers:
IE 11 / Win 7 R via TLS 1.2 ==> TLS_RSA_WITH_AES_128_CBC_SHA256
IE 8-10 / Win 7 R via TLS 1.0 ==> TLS_RSA_WITH_AES_128_CBC_SHA

Glassfish should at least allow to change the order of the "server-side" list of supported cipher suites. Furthermore, Java has even introduced an API for listening a little more to "what the client wants", see http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html :

Cipher Suite Preference:
During TLS handshaking, the client requests to negotiate a cipher suite from a list of cryptographic options that it supports, starting with its first preference. Then, the server selects a single cipher suite from the list of cipher suites requested by the client. Normally, the selection honors the client's preference. However, to mitigate the risks of using weak cipher suites, the server may select cipher suites based on its own preference rather than the client's preference, by invoking the method SSLParameters.setUseCipherSuitesOrder(true).

That means it would also be great to apply SSLParameters.setUseCipherSuitesOrder(bool) via asadmin settings (probably on the http-linteners ssl section).

#####################################################
And here is the complete list of cypher suites (RC4 is disabled):
#####################################################

$ /home/glassfish/bin/asadmin list-supported-cipher-suites
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_DH_anon_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_ECDH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_ECDHE_ECDSA_WITH_NULL_SHA
TLS_ECDHE_RSA_WITH_NULL_SHA
SSL_RSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_anon_WITH_NULL_SHA
SSL_RSA_WITH_NULL_MD5



 Comments   
Comment by nabizamani [ 23/Feb/15 ]

For example, this would allow forward secrecy in IE on Win 7 (maybe there are better cipher suites that allow forward secrecy and which are supported by the different IE versions):

IE 11 / Win 7 R via TLS 1.2 ==> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
IE 8-10 / Win 7 R via TLS 1.0 ==> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

But unfortunately Glassfish only selects this, which has no Forward Secrecy as I believe to know:

IE 11 / Win 7 R via TLS 1.2 ==> TLS_RSA_WITH_AES_128_CBC_SHA256
IE 8-10 / Win 7 R via TLS 1.0 ==> TLS_RSA_WITH_AES_128_CBC_SHA





[GLASSFISH-21307] Secure Client-Initiated Renegotiation cannot be disabled: DoS Danger Created: 21/Feb/15  Updated: 22/Feb/15

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

Type: Bug Priority: Critical
Reporter: nabizamani Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: TLS, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04 LTS Server x64, java 1.8.0_31 + JCE Unlimited Strength, GlassFish Server Open Source Edition 4.1 (build 13)


Tags: DoS, glassfish, renegotiation, security, tls

 Description   

Glassfish 4.1 supports Secure Client-Initiated Renegotiation. However, this opens all doors for DoS attacks, see https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks

As Ivan Ristić found out there was an undocumented ability to disable client-initiated renegotiation in Java 8 (see http://blog.ivanristic.com/2014/03/ssl-tls-improvements-in-java-8.html). However, this seems not to work at all (I guess it has been removed + it is undocumented anyway)! In other words: adding the following to <jdk1.8-HOME>/jre/lib/security/java.security does not help at all (whereas I think OpenJDK has support for this, but I did not crosscheck this):

jdk.tls.rejectClientInitiatedRenegotiation=true
jdk.tls.rejectClientInitiatedRenego=true

I have not found anything that allows to disable Secure Client-Initiated Renegotiation in the Glassfish settings. Since there seems to be no way to
disable it globally via JSSE (<jdk1.8-HOME>/jre/lib/security/java.security) I believe that Glassfish should introduce a way to disable it somehow. I believe this is very critical.



 Comments   
Comment by Anthony Vanelverdinghe [ 22/Feb/15 ]

jdk.tls.rejectClientInitiatedRenegotiation is a system property, so simply adding a JVM Option "-Djdk.tls.rejectClientInitiatedRenegotiation=true" (Configurations -> server-config -> JVM Settings -> JVM Options) should work

Comment by nabizamani [ 22/Feb/15 ]

You are absolutely right, that does the trick. I simply did not recognize that it's a system property (although it is mentioned as such in Ivan's article) because at the same time I was working on jdk.tls.disabledAlgorithms in <jdk1.8-HOME>/jre/lib/security/java.security to disable RC4 (so I just got a little bit confused)...

However, I don't feel very safe using the undocumented system property via JVM options in a production environment because it's just undocumented. Using something undocumented means it could be removed with the next java update and therefore I would need to check if it is still available or not whenever I update my jdk. Therefore I still believe that there should be an explicit Glassfish setting directly in Glassfish. On the other side, everything would be fine if jdk.tls.rejectClientInitiatedRenegotiation would be a documented system property.

Does that sound reasonable? What do you think?

Comment by Anthony Vanelverdinghe [ 22/Feb/15 ]

It actually is documented in the "Compatibility Guide for JDK 8" [1], where it says: "In Oracle's JSSE provider, a new system property, jdk.tls.rejectClientInitializedRenego, is defined to reject client initialized renegotiation in server side. If the system property is set to true, the server side does not accept client initialized renegotiation, and fails with a fatal handshake_failure alert if the receiving client initialized the renegotiation request."

I doubt this property is ever going away. And surely it won't go away in a minor release. So as long as you read the compatibility guides with every major release (which you should do anyway), you're safe.

I don't like the idea of "an explicit GlassFish setting", because of:
1) duplication: it would just duplicate setting the appropriate JVM Option
2) confusion: if the explicit setting is set to false, but the JVM Option is manually set to true, what should happen?

In my opinion, the question is simply: should GlassFish add this option to the default JVM Options, yes or no? And my answer would be "yes".

[1] http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198

Comment by nabizamani [ 22/Feb/15 ]

You are right again - it is documented. However, it is documented as jdk.tls.rejectClientInitializedRenego and not as jdk.tls.rejectClientInitializedRenegotiation.
I have just tested both system properties and only jdk.tls.rejectClientInitializedRenegotiation seems to work - the one that is not documented! Of course, I should stick with jdk.tls.rejectClientInitializedRenego as this is the one that is documented, but it seems not to work.
Can you somehow verify this? Maybe this is just a documentation error in the Compatibility Guide for JDK 8?

I also agree that duplication is not a good idea and avoiding confusion is also a good idea.
You question is correct: should GlassFish add this option to the default JVM Options, yes or no?
My answer is YES as well.

Comment by Anthony Vanelverdinghe [ 22/Feb/15 ]

It's just an oversight in the compatibility guide: in the guide there's a link to the bug report [1], where you will see another related bug, namely "JDK-8017049 - rename property jdk.tls.rejectClientInitializedRenego" [2]
So I bet it went like this: initially this functionality was implemented with a property named "jdk.tls.rejectClientInitializedRenego" & a note was added to the compatibility guide. Later, the developers realized it was clearer to use "jdk.tls.rejectClientInitiatedRenegotiation", so they renamed the property & changed the implementation, but forgot to have the compatibility guide updated.

[1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7188658
[2] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8017049

Comment by nabizamani [ 22/Feb/15 ]

Thank you Anthony, that clarifies a lot. I guessed something like that...
So let's wait and see if "-Djdk.tls.rejectClientInitiatedRenegotiation=true" will be added as default JVM option to the next release of Glassfish or not.





[GLASSFISH-19568] Regression: WebComponentInvocation cannot be cast to EjbInvocation from deploying an ear without web component Created: 22/Jan/13  Updated: 24/Apr/14

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

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The failing ejb devtest is /txprop/simple with the exception from the security module, so starting with the security component (please reassign as you see it fit):

[exec] java.lang.ClassCastException: com.sun.enterprise.web.WebComponentInvocation cannot be cast to com.sun.ejb.EjbInvocation
[exec] at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.afterPostInvoke(EjbSecurityComponentInvocationHandler.java:101)
[exec] at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:254)
[exec] at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1983)
[exec] at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1961)
[exec] at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:212)
[exec] at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)
[exec] at $Proxy280.callHello(Unknown Source)

There are other errors in the run, but this error started happening between the builds that were used for the 4am and 10am test runs on Jan 18th. This is a very old EJB test with no recent modifications.



 Comments   
Comment by marina vatkina [ 22/Jan/13 ]

You can use http://hudson-sca.us.oracle.com/job/ejb-devtests-trunk-single-test/ to setup to run a single ejb devtest.





[GLASSFISH-21308] Support for TLS_FALLBACK_SCSV to prevent downgrade attack Created: 21/Feb/15  Updated: 01/Oct/15

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

Type: Improvement Priority: Critical
Reporter: nabizamani Assignee: JeffTancill
Resolution: Unresolved Votes: 3
Labels: TLS, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04 LTS Server x64, java 1.8.0_31 + JCE Unlimited Strength, GlassFish Server Open Source Edition 4.1 (build 13)


Tags: DoS, glassfish, renegotiation, security, tls

 Description   

see https://community.qualys.com/thread/13896 and especially see
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/



 Comments   
Comment by vahid_shirvani [ 29/Sep/15 ]

My setup is very similar to yours

Ubuntu 14.04 LTS Server x64,
java 1.8.0_60 + JCE Unlimited Strength,
GlassFish Server Open Source Edition 4.1 (build 13)

I even upgraded the OpenSSL to version 1.0.1j but it still didn't solve the issue. The ssllabs test complained.
Accoring to this link https://community.qualys.com/thread/13896 upgrading the Openssl shall solve the issue.

EDIT: Glassfish does not use OpenSSL. Instead it uses the JSSE which has not been patched yet.





[GLASSFISH-11081] Username null in access log for EJB WebService Created: 18/Nov/09  Updated: 25/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v2.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: sauvage Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive EJBTest_pb_user_not_in_accesslog.zip    
Issuezilla Id: 11,081
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude

 Description   

When making a SOAP request to an EJB webservice (with authentication), the user
name is not written in the server_access_log file: the value "NULL-AUTH-USER" is
written instead. Notice the authenticated user is correctly displayed for a web
service in web application.

Ex: with the user "test", we get the line:
"127.0.0.1" "NULL-AUTH-USER" "18/Nov/2009:11:16:44 +0100" "POST
/TestEJBWebServiceService/TestEJBWebService HTTP/1.1" 200 209
instead of the expected:
"127.0.0.1" "test" "18/Nov/2009:11:16:44 +0100" "POST
/TestEJBWebServiceService/TestEJBWebService HTTP/1.1" 200 209

The attached project shows this behaviour.

  • compile and deploy the project in the Glassfish server
  • create a user "test" in the group "all" in the default FILE realm
  • query the webservice TestEJBWebService
  • check the server_access_log file: the username is "NULL-AUTH-USER"

== Request example ==================
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:test="http://Test/">
<soapenv:Header/>
<soapenv:Body>
<test:operation/>
</soapenv:Body>
</soapenv:Envelope>



 Comments   
Comment by sauvage [ 18/Nov/09 ]

Created an attachment (id=3937)
test case

Comment by jluehe [ 18/Nov/09 ]

Reassigning to security.

"NULL-AUTH-USER" is logged if HttpServletRequest#getRemoteUser returns null.

HttpServletRequest#getRemoteUser is implemented (in
org.apache.coyote.tomcat5.CoyoteRequest) in terms of

userPrincipal.getName()

Looks like CoyoteRequest#setUserPrincipal was not called in this scenario, or
was being passed a "null" principal. Normally, setUserPrincipal is called by
com.sun.web.security.RealmAdapter#validate

Comment by jluehe [ 18/Nov/09 ]

Forgot to reassign ...

Comment by kumarjayanti [ 20/Nov/09 ]

This bug is filed on V2, so it will be fixed in V2.

We wanted to see if the same applies to V3. When we tested the App attached by
the user, we see that there is nothing in the access_log file at all
corresponding to the WebService POST request. Even the access to the WSDL
url?wsdl (the GET request) is not coming the server access logs. Whereas when we
try to access a secure WebApp we could see the GET and the corresponding
principal in the access log.

So i guess there is a larger problem of Access Log and WebService requests in V3.

Comment by kumarjayanti [ 07/Oct/10 ]

There is problems in EJB WS in V3 that the access logs do not come at all. I had mentioned to bhakti about
this. Once the core problem is fixed we can also figure out if this bug will apply there.

Comment by kumarjayanti [ 08/Oct/10 ]

marking it for 3.2 since the base infrastructure for emitting access logs for EJBWS is missing in V3.1

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-15042] There is no command to delete message security config Created: 08/Dec/10  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all platform


Issue Links:
Dependency
blocks GLASSFISH-14892 Cannot delete Message Security Closed
Tags: 3_1-exclude

 Description   

I can't find a way to delete message security config.
There is no REST API which is probably due to no command to delete that.
GUI is depending on this to fix http://java.net/jira/browse/GLASSFISH-14892



 Comments   
Comment by kumarjayanti [ 08/Dec/10 ]

./asadmin delete-message-security-provider --layer SOAP XWS_ClientProvider
Command delete-message-security-provider executed successfully.

Comment by srinik76 [ 08/Dec/10 ]

We need a command like delete-message-security.

Comment by kumarjayanti [ 08/Dec/10 ]

I do not see a real need to delete the message-security container. Though from a GUI perspective it might be required for uniformity. We can create a such a command for V3.2

Comment by kumarjayanti [ 08/Dec/10 ]

if required we can add such a command for MS_08 if management approves.

Comment by Anissa Lam [ 16/Dec/10 ]

Assign back to Kumar for adding the command in later release.

Comment by kumarjayanti [ 13/Apr/11 ]

marking it for 4.0 since there is no strong requirement for this in 3.2 timeframe

Comment by larry.mccay [ 21/Sep/12 ]

The GUI bug that was dependent on this has been closed and the delete button has been removed. There is also a complication of making sure that you don't delete the configuration out from under the GUI to contend with. There are existing commands to remove individual providers. Do we have and real pressing need for this functionality?

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-10572] application deployment failures with errors in finding security package classes Created: 26/Oct/09  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: sankarpn Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: AIX
Platform: PC


Attachments: File ejbslapp1.ear    
Issuezilla Id: 10,572
Tags: 3_1-exclude

 Description   

Deploy the attached ejb SL SBean application to reproduce the issue.

In server.log I see this.

Caused by: java.lang.RuntimeException: IIOP Protocol Manager initialization
failed. Possible cause is that ORB is not available in this container
at
com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:811)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:556)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:150)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:144)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:99)
at
org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:207)
... 32 more
Caused by: java.lang.NoClassDefFoundError: sun.security.util.ObjectIdentifier
at com.sun.enterprise.iiop.security.GSSUtils.<clinit>(GSSUtils.java:83)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
at
com.sun.enterprise.iiop.security.CSIV2TaggedComponentInfo.createASContextSec(CSIV2TaggedComponentInfo.java:473)
at
com.sun.enterprise.iiop.security.CSIV2TaggedComponentInfo.createSecurityTaggedComponent(CSIV2TaggedComponentInfo.java:237)
at
com.sun.enterprise.iiop.security.SecIORInterceptor.addCSIv2Components(SecIORInterceptor.java:168)
at
com.sun.enterprise.iiop.security.SecIORInterceptor.establish_components(SecIORInterceptor.java:93)
at
com.sun.corba.ee.impl.interceptors.InterceptorInvoker.objectAdapterCreated(InterceptorInvoker.java:139)
at
com.sun.corba.ee.impl.interceptors.PIHandlerImpl.objectAdapterCreated(PIHandlerImpl.java:339)
at
com.sun.corba.ee.spi.oa.ObjectAdapterBase.initializeTemplate(ObjectAdapterBase.java:143)
at com.sun.corba.ee.impl.oa.poa.POAImpl.initialize(POAImpl.java:474)
at com.sun.corba.ee.impl.oa.poa.POAImpl.create_POA(POAImpl.java:909)
at
com.sun.corba.ee.impl.naming.cosnaming.TransientNameService.initialize(TransientNameService.java:135)
at
com.sun.corba.ee.impl.naming.cosnaming.TransientNameService.<init>(TransientNameService.java:90)
at
org.glassfish.enterprise.iiop.impl.POAProtocolMgr.initializeNaming(POAProtocolMgr.java:200)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:89)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:146)
at
com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:808)
... 37 more
Caused by: java.lang.ClassNotFoundException: sun.security.util.ObjectIdentifier
at java.net.URLClassLoader.findClass(URLClassLoader.java:419)
at java.lang.ClassLoader.loadClass(ClassLoader.java:643)
at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
at
org.apache.felix.framework.ExtensionManager$ExtensionManagerModule.getClassByDelegation(ExtensionManager.java:658)
at org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:108)
at org.apache.felix.framework.ModuleImpl.searchImports(ModuleImpl.java:1364)
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:677)
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:60)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1650)
at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
... 55 more



 Comments   
Comment by sankarpn [ 26/Oct/09 ]

Created an attachment (id=3623)
application archive attached

Comment by sherryshen [ 26/Oct/09 ]

cc

Comment by kumara [ 27/Oct/09 ]

AIX support is being deferred to v3.1.

Comment by kumarjayanti [ 27/Oct/09 ]

the V3 Security Module has the following sun specific imports :

import sun.security.util.PropertyExpander;
import sun.security.util.ObjectIdentifier;
import sun.security.x509.X500Name;
import sun.security.util.DerValue;
import sun.security.util.PropertyExpander.ExpandException;
import sun.security.tools.*;
import sun.security.tools.KeyTool.
import sun.security.util.DerInputStream;
import sun.security.x509.X509CertImpl;
import sun.security.util.DerOutputStream

import sun.security.provider.PolicyFile;

import sun.security.provider.PolicyParser.GrantEntry;
import sun.security.provider.PolicyParser;
import sun.security.provider.PolicyParser.PermissionEntry;
import sun.security.provider.PolicyParser.PrincipalEntry;
import sun.security.provider.PolicyParser.ParsingException

The ones below are actually coming from the fact that we had copied over the JDK
PolicyFile class into V2 in order to make a patch in it (that was not available
as part of the JDK against which V2 was certified) : The JDK issue number is CR
: 6552236

import com.sun.security.auth.PrincipalComparator;
import sun.security.provider.SystemIdentity;
import sun.security.util.Debug;
import sun.security.util.ResourcesMgr;
import sun.security.util.SecurityConstants;
import sun.security.util.Password;

Comment by sankarpn [ 29/Oct/09 ]

not a v3 release stopper

Comment by kumarjayanti [ 05/Oct/10 ]

AIX support not mandatory for V3.1

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-11808] logout is missing in security audit module Created: 19/Apr/10  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,808
Tags: 3_1-exclude

 Description   

According to https://glassfish.dev.java.net/nonav/docs/v3/api/,
there is no logout auditing in GlassFish v3.
Note that in Servlet 3.0, programmatic logout is added. It would be good to
audit the logout in this case.



 Comments   
Comment by kumarjayanti [ 07/Oct/10 ]

target milestone

Comment by kumarjayanti [ 19/Nov/10 ]

moving this to V3.2 since we could not find enough time to fix this given other high prio bugs.

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-11624] delay session creation until after user-data-constraint is enforced on login page Created: 26/Feb/10  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: monzillo Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,624
Tags: 3_1-exclude

 Description   

the Glassfish FormAuthenticator was enhanced to effectively enforce
user-data-constraints on the login page.

we should now take the additional steps of delaying any session creation by the
FormAuthenticator until after the enforcement of any user-data-constraint on the
login form.

This will ensure that the session cookie will be acquired under https if the
login page is secure; which will ensure that browsers will know that the cookie
is not to be sent over an unprotected transport.

This change has security merits but may cause pre-existing applications to
break. As such, we may need to make it possible for an app to select or revert
to the prior functionality.



 Comments   
Comment by kumarjayanti [ 07/Oct/10 ]

setting target milestone

Comment by kumarjayanti [ 19/Nov/10 ]

move to V3.2 since we could not find time to fix this soon enough and it is risky now to fix this since its
late in the cycle

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-10099] Glassfish clustering mode ClassNotFoundException sun.security.pkcs11.SunPKCS11 Windows 64 Bit Created: 08/Oct/09  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v2.1
Fix Version/s: future release

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

Operating System: Windows Vista
Platform: PC


Issuezilla Id: 10,099
Tags: 3_1-exclude

 Description   

This is similar to issue 9332.
The actual OS that this failed on was Windows 2008 Server 64bit edition Service
Pack 1, which was not selectable in the box.

The reason this is a different issue than 9332 is that the stack trace is
different. I want to make sure that it isn't treated as an identical issue
because fixing 9332 may not necessarily fix the problem in Windows. In the nix
environment on issue 9332 it seems that the class is actually resolved, but the
underlying native libraries are of an incorrect version. However in Windows
glassfish attempts to load the sun.security.pkcs11.SunPKCS11 class, which fails
at the classloader level, the actual bytecode is not present in the 64bit
Windows JVM.

This bug possibly could be a bug in the JDK, but as a user of Glassfish we
should attempt to accept non Sun JVMs, with a hard dependency on a sun.xxx class
we are assuming Sun JDK, and further that this specific class exists on all
versions of that JDK. If the bug IS a Sun JVM bug, we should look into changing
glassfish to still run because both are Sun products and there should be a good
story there.

[#|2009-10-08T00:35:07.639-0700|WARNING|sun-appserver2.1|javax.enterprise.system.stream.err|_ThreadID=10;_ThreadName=main;_RequestID=ed45052b-a41a-402c-87c1-183342ddd8c5;|java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.server.PELaunch.main(PELaunch.java:415)
Caused by: java.lang.NoClassDefFoundError: sun/security/pkcs11/SunPKCS11
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
com.sun.enterprise.pluggable.PluggableFeatureFactoryBaseImpl.invoke(PluggableFeatureFactoryBaseImpl.java:84)
at $Proxy0.getSecuritySupport(Unknown Source)
at
com.sun.enterprise.security.SecurityUtil.getSecuritySupport(SecurityUtil.java:364)
at com.sun.enterprise.security.SSLUtils.<clinit>(SSLUtils.java:102)
at
com.sun.enterprise.security.SecurityLifecycle.onInitialization(SecurityLifecycle.java:101)
at
com.sun.enterprise.server.ApplicationServer.onInitialization(ApplicationServer.java:262)
at
com.sun.enterprise.server.ondemand.OnDemandServer.onInitialization(OnDemandServer.java:103)
at com.sun.enterprise.server.PEMain.run(PEMain.java:399)
at com.sun.enterprise.server.PEMain.main(PEMain.java:336)
... 5 more
Caused by: java.lang.ClassNotFoundException: sun.security.pkcs11.SunPKCS11
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at
com.sun.appserv.server.util.ASURLClassLoader.loadClass(ASURLClassLoader.java:144)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 16 more

#]


 Comments   
Comment by coding [ 08/Oct/09 ]

This exception only happens when Glassfish is in Cluster mode, for example
when installed with
lib\ant\bin\ant -f setup-cluster.xml

Or

regular setup.xml and in the admin console you click "Add Cluster Support"

Comment by nradov [ 08/Oct/09 ]
      • Issue 10099 has been confirmed by votes. ***
Comment by Hong Zhang [ 08/Oct/09 ]

assign to security team for initial evaluation

Comment by kumarjayanti [ 09/Oct/09 ]

reassign

Comment by kumarjayanti [ 09/Oct/09 ]

could you please look at the following :

http://forums.java.net/jive/thread.jspa?messageID=256594

the exact same exception as your's and the suggestion was to upgrade the JDK
version.

Once you confirm i can close the issue.

Comment by coding [ 09/Oct/09 ]

Please do not close, the JDK that we are using is already at the very latest
version available right now.

C:\jdk6\bin>java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)

Glassfish is using c:\jdk6 above as the JAVA_HOME.

Comment by kumarjayanti [ 09/Oct/09 ]

The Sun PKCS#11 provider is supported on Solaris SPARC platforms (32-bit and
64-bit Java VM) and on x86 compatible platforms (Solaris, Linux, and Windows
operating systems). It is not supported on 64-bit AMD64 and Itanium platforms.

Which is your platform.

Comment by coding [ 09/Oct/09 ]

Thank you for discovering that... However I still think this needs to be fixed
in Glassfish, please see my original comment:

> This bug possibly could be a bug in the JDK, but as a user of Glassfish we
> should attempt to accept non Sun JVMs, with a hard dependency on a sun.xxx class
> we are assuming Sun JDK, and further that this specific class exists on all
> versions of that JDK. If the bug IS a Sun JVM bug, we should look into changing
> glassfish to still run because both are Sun products and there should be a good
> story there.

Comment by kumarjayanti [ 09/Oct/09 ]

Yes i understand your point. But the PKCS11 support is a non-trivial thing and
IMO it would be difficult for GF to claim support for it on Non-Sun VM's and
platforms.

Would it be ok if GF fails gracefully in your case ?. What is your platform ?.

Comment by coding [ 09/Oct/09 ]

Yes absolutely that would be a GREAT solution. When you say gracefully, you mean
it will actually boot up and run in cluster mode? If so thanks!

Windows 2008 Server 64bit edition Service Pack 1
AMD64

We are using the Sun JDK.

Comment by markdr [ 14/Dec/09 ]

Have seen the same problem when running up a Glassfish Node Agent on Windows
2008 64Bit running on Intel CPU's against JDK 1.6.0_17:

[#|2009-12-14T11:50:25.407+1300|SEVERE|sun-appserver2.1|javax.ee.enterprise.system.nodeagent|_ThreadID=10;_ThreadName=main;|NAGT0014:Unexpected
Node Agent exception.

java.lang.NoClassDefFoundError: sun/security/pkcs11/SunPKCS11
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
com.sun.enterprise.pluggable.PluggableFeatureFactoryBaseImpl.invoke(PluggableFeatureFactoryBaseImpl.java:84)
at $Proxy2.getSecuritySupport(Unknown Source)
at
com.sun.enterprise.security.SecurityUtil.getSecuritySupport(SecurityUtil.java:364)
at
com.sun.enterprise.ee.nodeagent.NodeAgent.initializeSecurity(NodeAgent.java:1368)
at
com.sun.enterprise.ee.nodeagent.NodeAgent.configureAgent(NodeAgent.java:1484)
at
com.sun.enterprise.ee.nodeagent.BaseNodeAgent.init(BaseNodeAgent.java:171)
at
com.sun.enterprise.ee.nodeagent.NodeAgent.synchronizeWithDASInternal(NodeAgent.java:716)
at
com.sun.enterprise.ee.nodeagent.NodeAgent.synchronizeWithDASInternal(NodeAgent.java:595)
at
com.sun.enterprise.ee.nodeagent.BaseNodeAgent.run(BaseNodeAgent.java:144)
at
com.sun.enterprise.ee.nodeagent.NodeAgentMain.startup(NodeAgentMain.java:255)
at
com.sun.enterprise.ee.nodeagent.NodeAgentMain.main(NodeAgentMain.java:396)
Caused by: java.lang.ClassNotFoundException: sun.security.pkcs11.SunPKCS11
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:303)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
... 13 more

Switching to the 32Bit JDK allowed us to continue.

Comment by kumarjayanti [ 04/Oct/10 ]

added keyword

Comment by kumarjayanti [ 13/Apr/11 ]

Not relevant for V3.2





[GLASSFISH-12753] ProgrammaticLogin: Long running first method call Created: 21/Jul/10  Updated: 25/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: lft Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Attachments: Zip Archive mem.zip    
Issuezilla Id: 12,753
Tags: 3_1-exclude

 Description   

We use ProgrammaticLogin for authentication of standalone-client applications.
After successful loging in the first call to EJB method continues for an
abnormal long time (up to 30 seconds) after that other methods or the same
method are fast enough (< 1 sec.).



 Comments   
Comment by lft [ 13/Sep/10 ]

Created an attachment (id=4869)
linux-format process dump

Comment by lft [ 27/Sep/10 ]

any comment on this issue?

Comment by kumarjayanti [ 07/Oct/10 ]

Will try to find out the cause. One thing i can think of is LazyLoading of the ORB (if this is really the case
then i guess we will have to close the bug as WONTFIX). But will check with our ORB expert Ken and let you
know.

U maybe able to disable lazyloading of ORB if this is really an issue for you.

Comment by lft [ 08/Oct/10 ]

"lazyloading" - do you mean jnlp 'download="lazy"' option or something else ?
If you mean jnlp option, I can say that this problem also occur when start
application statically without java web start.

Comment by lft [ 08/Oct/10 ]

I think you meant "lazy component initialization" feature of glassfish server.

Comment by lft [ 08/Oct/10 ]

I tried to set lazy-init="false" in "iiop-listener" tag of domain.xml but with
no success. The problem remains. The interesting thing is that another stateless
bean exposed as web service and accessed through https returns answer without any
delay.

Comment by kumarjayanti [ 19/Nov/10 ]

defer this to V3.2 since this appears to be less critical given the other P2's we have and the time left for
MS7.

Comment by kumarjayanti [ 13/Apr/11 ]

Hi,

Will you be able to test your App with 3.1 and prove to us that this is an issue. Can you give us a testcase.

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-12561] EjbIORConfigurationDescriptor.java.htm does not validate all options for setEstablishTrustInTarget Created: 07/Jul/10  Updated: 09/Apr/12

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

Type: Bug Priority: Major
Reporter: marcobjorge Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 12,561
Tags: 3_1-exclude

 Description   

EjbIORConfigurationDescriptor.java must allow all three options for
EstablishTrustInTarget.

Currently only allows SUPPORTED and NONE.






[GLASSFISH-13389] UTF-8 fails in JDBC principal name Created: 13/Sep/10  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: tmpsa Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File utf8discussion.txt    
Issuezilla Id: 13,389
Tags: 3_1-exclude

 Description   

It appears that a JDBC realm set up for UTF-8 characters (to a MySQL 5.1 table
also set up for UTF-8 characters) does not work for non-ASCII characters (i.e.
anything else than plain 7-bit ASCII chars). For example, the user "Ã-sterman"
can't log in - ever.

Also, the same problem appears to exist for the password.

I have raised the issue in
http://forums.java.net/jive/message.jspa?messageID=396453#396453
but to no avail. you might find some additional information there.
I'll be more than happy to provide any further details, as needed.

My apologies if I have entered this issue under the wrong subcomponent, or
whatever.



 Comments   
Comment by kumara [ 14/Sep/10 ]

-> security (that team owns JDBC realm implementation)

Comment by kumarjayanti [ 07/Oct/10 ]

setting target

Comment by kumarjayanti [ 08/Dec/10 ]

change milestone.

Comment by Nithya Ramakrishnan [ 09/Dec/10 ]

The forum post discussing the issue

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-11862] SunPKCS11 crypto provider should be disabled if no hardware accelerator Created: 06/May/10  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v2.1.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: sauvage Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux
URL: http://issues.hudson-ci.org/browse/HUDSON-6459


Attachments: Zip Archive TestCrypto.zip    
Issuezilla Id: 11,862
Tags: 3_1-exclude

 Description   

Hi,

When trying to use crypto API, I get the following exception on Glassfish
Enterprise Edition on Solaris x86 10:
java.security.ProviderException: update() failed
at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:557)
at sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:457)
at sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:445)
at javax.crypto.Cipher.update(DashoA13*..)
at javax.crypto.CipherOutputStream.write(DashoA13*..)
at javax.crypto.CipherOutputStream.write(DashoA13*..)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DEVICE_ERROR
at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:510)

This error is surely caused by the absence of hardware accelerator.
To workaround this error you have to explicitly specify the security provider to
"SunJCE" as described here: http://www.marceble.com/2009/08/java-security-
providers/.

Notice this bug occurs only on enterprise edition.

Regards,

Laurent.



 Comments   
Comment by sauvage [ 18/May/10 ]

Created an attachment (id=4364)
testcase

Comment by kumarjayanti [ 07/Oct/10 ]

setting target

Comment by kumarjayanti [ 13/Apr/11 ]

Does not affect V3.2





[GLASSFISH-7980] Enhancements in EJB Security Created: 22/Apr/09  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v2.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,980

 Description   

The following security related enhancements/clarifications have been requested
for in the EJB area.

1. is there a way to "harden" the iiop ports.

They are looking for a way to require all iiop client to authenticate using
username/password.

Quoting the user :

I only know the configurations in <ior-security-config> in sun-ejb-jar.xml. But
this is done for every application and not globally.
Is there a flag to require client authentication regardless of the setting in
<ior-security-config> in sun-ejb-jar.xml?
What happens if I disable the IIOP listener that uses no authentication is this
a way to harden the iiop service?

2. What is the way to secure Namespace Lookups from both Standalone clients and
from Intermediates.

We will have to be able to define the security policy of namespace objects such
that it can be satisfied both by user clients (who can provide a username and
password) and by intermediate (e.g., Servlet container) clients (that can at
best provide their own username and password). This is a generic problem with
the implementation of GlassFish csiv2 mechanism configuration and interpretation
systems, and a resolution would also make it easier to secure ejbs.



 Comments   
Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by kumarjayanti [ 03/Sep/09 ]

Marking it an Enhancement.





[GLASSFISH-7085] Administrator needs to know declared roles Created: 23/Jan/09  Updated: 09/Apr/12

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

Type: Improvement Priority: Major
Reporter: mkarg Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,085

 Description   

Using @DeclareRoles, @RolesAllowed etc. a programmer can declare the logical
roles he invented and which must be mapped to physical user groups at deployment
by the server administrator or deployer.

There are two problems:

  • The administrator or deployer does not have insight into the source code, so
    the installer tool must tell him the declared roles. Otherwise he just doesn't
    know them. GlassFish currently has no such tool, so how should the deployer know
    what roles do exist?
  • From time to time it happens that the mapping from roles to groups will change
    due to business reorganization. The administrator then must change the sun-*.xml
    file that contains the mapping, and redeploy the administration. This is not
    nice, since it implies a pause in the availability of the application. It would
    be better if no redeploy would be needed and the mapping from roles to groups
    could just be configures using a live GUI.


 Comments   
Comment by mkarg [ 12/Jul/11 ]

Not even a single comment in over two years? Does not feel like GF team likes to get ideas like this one from ISVs. ;-(

Comment by kumarjayanti [ 12/Jul/11 ]

Sorry for inaction on this. If we have to start anything in this direction there is lots of work to be done and it has to become part of a major release. However the focus of major releases in the recent past has been JavaEE6 and then Clustering.

The GlassFish Engineering is well aware of this limitation and it often comes up as a potential task item, but it has somehow not made it to any release yet.

That said, GlassFish does allow Pluggability of RoleMapper OOTB (to address your point 2) via the In Memory JACC Provider. Please see :

http://blogs.oracle.com/monzillo/entry/prelude_includes_portable_in_memory
http://blogs.oracle.com/monzillo/entry/how_to_configure_an_alternative

The default RoleMapper implementation in the InMemory JACC Provider simply makes use of the mappings in sun-*.xml. However you can write your own that does support a more dynamic way of obtaining the role to group mappings.

As part of our JavaOne 2010 session on GlassFish 3.1 Security we demonstrated a more dynamic impl of this RoleMapper where it would allow changing the role to group mapping without requiring a restart. However we have not found time to put out that code in the public somewhere.

You can also write your own JACC Provider where you can possibly use a completely different interface/mechanism to manage the Role to Group Mappings.

GlassFish also has OOTB the Default P2R feature where the same named Role is mapped to Same Named Group automatically (without requiring explicit listing of G2R in sun*.xml). This can address both 1 and 2 (to an extent).





[GLASSFISH-6990] argument not substituted in IOP5001 message Created: 05/Jan/09  Updated: 09/Apr/12

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

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,990

 Description   

After deploying a (probably faulty) EJB application, I found the following error
message in the server log.

IOP5001: Exception creating security tagged component: [

{0}]
java.lang.RuntimeException: java.lang.ClassNotFoundException:
test.isjee.verifier.ejb.ejb1.HelloRemote

The argument of the IOP5001 message was not substituted.

I checked the source, and just like in issue 6987 the Logger API might have been
understood incorrectly.

With the Logger method that is currently used, there is no need to add an
argument, the stacktrace will be correctly logged with it even when the {0}

is
omitted.

So the fix would be to remove ": [

{0}

]" at the end of message IOP5001 in line 15
of
appserv-commons/src/java/com/sun/logging/enterprise/resource/corba/LogStrings.properties

iiop.createcompund_exception=IOP5001: Exception creating security tagged component



 Comments   
Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Ken Cavanaugh [ 02/Nov/09 ]

This is not in the ORB; it's in the EJB container.

Comment by marina vatkina [ 17/Mar/11 ]

Security code uses iiop.createcompund_exception ID but it is not there in any of the message bundles





[GLASSFISH-6912] Simplify building custom realms Created: 11/Dec/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: cowwoc Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,912

 Description   

As discussed at http://forums.java.net/jive/thread.jspa?messageID=321287&#321287

  • Exception messages should specify exactly what keys Glassfish is looking at
    and what values it found. The message should suggest a solution if possible.
  • The website should clearly indicate what documentation to use for Glassfish v2
    and v3 and deprecate the heck out of all the older documentation (to avoid
    people using it by mistake).

It took me 6 hours (!!) to get this working. I've seen others on the forums
taking days. I am expecting someone new to Glassfish should be able to get this
working in 30 minutes or less.



 Comments   
Comment by paulbrickell [ 26/May/09 ]
      • Issue 6912 has been confirmed by votes. ***
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5058] Need a way for app clients to distinguish between failed authentication and user cancel Created: 22/May/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Tim Quinn Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,058

 Description   

When the security logic on the app client side detects the need to authenticate
the user, it invokes a callback handler (either the built-in default one or a
user-provided one) to gather the credentials.

There is no published way for the developer's app client code to distinguish
between the case in which the user enters invalid credentials and the case in
which the user cancels the dialog (or, in general, declines to enter credentials).

This is especially a problem when authentication takes place during injection,
which happens before the developer's code has gained control. Currently the ACC
aborts the launch of the app client due to authentication errors, but even if it
did not there is no way the client logic can determine that an auth. error has
occurred, or alternatively that the user had canceled out of the dialog.

The security framework should provide a simple way for the developer's logic to
find out whether authentication was attempted and, if so, what the outcome was
(succeeded, failed, canceled).

This is somewhat related to 2310 but is not a duplicate.



 Comments   
Comment by kumarjayanti [ 19/Sep/08 ]

Marking it an Enhancement for V3.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4982] Parameterized interface confuses Roles annotation processor Created: 02/May/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: rycohen2000 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,982

 Description   

Serveral of my session beans' remote interfaces extend a common parameterized
interface, such that

SessionBean->RemoteInteface->ParameterizedInterface.

While this is quite usefule, it totally confuses the annotation processor
looking at the roles annotation in the session bean – often leaving some
methods unsecured while others seem to work as expected. The unsecured methods
were a bit of a shock, since I had left a defensive RolesAllowed annotation on
the class a whole which had no effect whatsoever.

My understanding is that this issue is not addressed by the existing specs, but
the current behavior came a shock to me, and certain apects of are quite
dangerous.

Ideally I would like to see the annotation processor understand that the methods
in the parameterized interface are nothing more than the same methods it is
seeing in the RemoteInterface/SessionBean.

Anyways, I have so far found three ways of getting around this (none of which
are very satisfying):
1. Remove the parameterized interface from the inheritance hierarchy. I tested
this and it works, but it's not really a option at this point as there is too
much client code that relies on its existence.

2. De-parameterize the parameterized interface. Again, I've tested this and it
works, but it eliminates the compile-time checks from which we are supposed to
benefit with a strongly-typed language. It also makes the code less readable -
more plain Objects, casts, etc.

3. Write out the method permissions by hand in the ejb-jar.xml. This works, and
although its painful and probably more error-prone than annotations, it is my
current course of action.

There is a fuller discusion of this at:
http://forums.java.net/jive/thread.jspa?threadID=40129&tstart=15

Thank you,
Ross



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4811] Missing JBoss like DatabaseServerLoginModule Realm Created: 17/Apr/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: elkner Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux
URL: http://iws.cs.uni-magdeburg.de/~elkner/glassfish/auth/


Issuezilla Id: 4,811

 Description   

Comming from JBoss I'm actually missing a JBoss like DatabaseServerLoginModule,
i.e. a module, where one is able to directly specify the query to obtain user
password and groups as a realm property.

OK, I found the GF JDBCRealm and know, that it might be possible to create views
to satisfy its requireents, however this is IHO pretty inconvinient. So I wrote
a slight variation of the JDBCRealm. Please consider to include it into GF:

http://iws.cs.uni-magdeburg.de/~elkner/glassfish/auth/JDBCLoginModule.java
http://iws.cs.uni-magdeburg.de/~elkner/glassfish/auth/JDBCRealm2.java



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4757] asadmin: provide CLI to modify login.conf Created: 13/Apr/08  Updated: 25/Apr/14

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

Type: Improvement Priority: Major
Reporter: elkner Assignee: JeffTancill
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 4,757

 Description   

glassfish has a pretty good CLI (which is actually one of the reasons, why I
switched over from JBoss). However, there is no CLI cmd for modifying the
login.conf of an instance (i.e. add/remove an entry in a reliable way).

I'm wondering about why the realm is not added/removed automatically to/from the
login.conf, when one creates/deletes a realm using the
create-auth-realm/delete-auth-realm command ...



 Comments   
Comment by janey [ 14/Apr/08 ]

I'm glad to hear that you switched to GlassFish because of the usability of CLI
interface - Thank you!

We'll look into adding this feature in v3.

Comment by janey [ 14/Apr/08 ]

Kedar,

I'm assigning this bug to you. Can you give some insight on how to implement
this in CLI?

Thanks!
Jane

Comment by Tom Mueller [ 10/Jan/11 ]

Reassigning to the security team to evaluate whether to implement asadmin subcommands for editing the login.conf file or if there should be a change to create/delete-auth-realm.

Comment by ajorpheus [ 07/Jan/13 ]

Tom,

Has the security team reached a decision about this ? It would be great if we could hear back about any progress on this issue.

In a completely automated setup, where a realm is created by using the 'asadmin create-auth-realm', I assume that right now it's not possible to add a corresponding entry to login.conf ?

Thanks!
Ashutosh.





[GLASSFISH-4719] Role Mapping / Realm Improvements Created: 10/Apr/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mkarg Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,719

 Description   

When deploying an EAR, and the deployer decides to add security features like
separate realm for an application, or mapping of roles to groups, the deployer
needs to modify the EAR (adding sun-application.xml file) and is limited in his
possibilities: Whenever a group of users is no more in a specific role, then he
must change the EAR once more (changing the sun-application.xml file) and redeploy.

That is not very smart for real world, productive use beyond the developer scene.

It would be great to be able to not have to add sun-application.xml file.

Instead it would be great to go to the Web Based Admin Console and have a GUI for:

  • Tell each deployed application, what realm to use.
  • Graphically add / remove users to groups (instead of just a text field)
  • Graphically add / remove roles assigned to groups (a group should be able to
    have more than one role)
  • Graphically add / remove roles directly to users (when there is only one
    admin, he doesn't want to add another group "admins" just for himself)

It is typical that companies have their users added to several groups (admins,
users, sales, support) and have roles assigned to groups (admins will have a lot
of roles, sales will have only a subset) or persons (admin will be admin, no
need of a group when you're the only one)



 Comments   
Comment by Hong Zhang [ 10/Apr/08 ]

Assign to the security team for evaluation.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4215] gfv3:JSR 196 Enabled HttpURLConnection Created: 17/Feb/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,215
Status Whiteboard:

v3-prd-item


 Description   

HttpUrlConnection with embedded jsr 196 integration point to support pluggable
auth mechanisms in http clients; such as to integrate OAUTH support in jax-rs
clients



 Comments   
Comment by kumarjayanti [ 17/Feb/08 ]

V3-PRD-Item

Comment by kumarjayanti [ 17/Feb/08 ]

changing IssueType to FEATURE

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4211] Define and Document how Unsupported Certificate Extensions can be handled during Certificate Validation Created: 17/Feb/08  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,211
Status Whiteboard:

v3-prd-item


 Description   

Define and Document the mechanism by which developers can ovrride the default
TrustManager so as to pass a certificate with unsupported extensions in validation.



 Comments   
Comment by kumarjayanti [ 17/Feb/08 ]

V3 PRD Item

Comment by kumarjayanti [ 17/Feb/08 ]

changing IssueType to FEATURE

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-18175] The key-store, trust-store element in ssl protocol element are not working Created: 12/Jan/12  Updated: 25/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-18179 When SSL keystore or truststore is sp... Sub-task Closed Amy Roh  
Tags: 3_1_2-exclude

 Description   

Specifying the keystore and truststore in ssl protocol element in domain.xml are not working.
One still pick up the keystore and truststore from jvm options.

A sample xml snapshot is as follows:
<protocol security-enabled="true" name="ssl-listener">
<http default-virtual-server="server">
<file-cache></file-cache>
</http>
<ssl key-store="/opscenter/security/keystore/keystore" ssl3-tls-ciphers="+SSL_RSA_WITH_RC4_128_MD5,+SSL_RSA_WITH_RC4_128_SHA" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" trust-store="/opscenter/security/keystore/truststore_gf" cert-nickname="s1as"></ssl>
</protocol>

I notice the following in debugger:
GlassfishSSLImpl#getServerSocketFactory() --> new GlassfishServerSocketFactory()
and we have GlassfishServerSocketFactory#getKeyManagers as follows:

        if (sslUtils == null) {
            initSSLUtils();
        }
        String keystoreFile = (String) attributes.get("keystore");
        if (logger.isLoggable(Level.FINE)) {
            logger.log(Level.FINE, "Keystore file= {0}", keystoreFile);
        }

        String keystoreType = (String) attributes.get("keystoreType");
        if (logger.isLoggable(Level.FINE)) {
            logger.log(Level.FINE, "Keystore type= {0}", keystoreType);
        }
        KeyManager[] kMgrs = sslUtils.getKeyManagers(algorithm);
        if (keyAlias != null && keyAlias.length() > 0 && kMgrs != null) {
            for (int i = 0; i < kMgrs.length; i++) {
                kMgrs[i] = new J2EEKeyManager((X509KeyManager) kMgrs[i], keyAlias);
            }
        }
        return kMgrs;
    }

(a) I notice that the keystoreFile are correctly pick up from protocol ssl element.
(b) the keystoreFile above is computed but "not" used in the computation of key managers
(c) The key managers are dervied from SSLUtils which is looked up from habitat.
However, we have
SSLUtils is scoped by Singleton.class
(ii) inside SSLUtils, the key managers are computed from SecuritySupportImpl.java
(iii) SecuritySupportImpl is also Singleton scoped
also, #initJKS method only get keystores info from jvm options



 Comments   
Comment by Shing Wai Chan [ 12/Jan/12 ]

Per discussion with Kumar, this bug is similar to http://java.net/jira/browse/GLASSFISH-15973.

I have manually classname attribute in ssl protocol element.
Then it works.

Now we have the following questions.
1) Now, by default, we use GlassfishSSLImpl. It seems that we should use "" here.
"" means that we will use the default from Grizzly.
Should we always use "" as a default?

2) If we edit the ssl keystore and truststore from admin console, then the classname will be set to GlassfishSSLImpl. And one cannot set the classname to "" from admin console.

Comment by kumarjayanti [ 12/Jan/12 ]

Shing Wai wrote :
------------
Now we have the following questions.
1) Now, by default, we use GlassfishSSLImpl. It seems that we should use "" here.
"" means that we will use the default from Grizzly.
Should we always use "" as a default?

2) If we edit the ssl keystore and truststore from admin console, then the classname will be set to GlassfishSSLImpl. And one cannot set the classname to "" from admin console.
----------------

Comment on #1 : So we cannot switch to "" as the default because we need to be secure by default.

Comment on #2 : Agreed this is an issue and we need to fix this in the CLI command. when explicit keystore and truststore are specified then the command should remove the classname.

Comment by Shing Wai Chan [ 12/Jan/12 ]

Can you clarify why "" is "not" secure?
If it is really not secure, then I think we should fix our default implementation to support the switching keystores as one don't want to compromise the security by using a two different keystores.

Comment by kumarjayanti [ 13/Jan/12 ]

"" is not secure because in this case the default Grizzly SSLImplementation is used and it expects the keystore and truststore passwords to be supplied

Either as additional attributes in the ssl element,
OR
as System properties javax.net.ssl.keyStorePassword and javax.net.ssl.trustStorePassword.

The default impl as you know reads Keystore and TrustStore from the System properties javax.net.ssl.keyStore and javax.net.ssl.trustStore so there is no issue there.

However you seem to have found an issue that GlassFish cannot be started if trustStore points to a different location other than domain config. This problem is independent of the Default SSL Implementation and i see that you have filed a different bug for that.





[GLASSFISH-17884] provide warning when a security-role-mapping is bogus Created: 02/Dec/11  Updated: 25/Apr/14

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

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

if the user deploys a web-app that has a security-role-mapping that maps a role to a non-existent user and/or group there is no error or warning in the server.log or during deployment. The deployment does not need to fail, since the deployer/admin can resolve the issue without redeploying the app.



 Comments   
Comment by Hong Zhang [ 02/Dec/11 ]

Assign to security team to take a look as they own this part of the DOL.





[GLASSFISH-17883] Deal with missing security-role-mapping in a better way. Created: 02/Dec/11  Updated: 25/Apr/14

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

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If the user deploys web app that has no principals mapped to all of its roles, some or all of the app will not be executable until after the user adds a glassfish-web.xml file via redeployment.

It would be better to do one of two things in this case:

1. fail the deployment (instead of printing a warning in the server log). Since the user will need to add the security-role-mapping elements and redeploy, we might as well fail sooner rather than later. This is very strict.

2. find a realm that that has users and map all the users in that realm to the roles defined in the app automatically. This is very lax. If there is no realm that has users then the deployment should fail similar to the lax case.

Note: if there is a security-role-mapping that is bogus (all unknown users and/or groups) the deployment should not fail, since the user can deployer/administrator can use asadmin to resolve those kinds of issues.



 Comments   
Comment by vince kraemer [ 02/Dec/11 ]

this should probably get your input and then get passed off to deployment to finish





[GLASSFISH-17749] A Dedicated grant{} Section For Applications Should Not Contain Any "Bug-Fixes" Created: 16/Nov/11  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: abien Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude, security

 Description   

The grant section of the server.policy file contains several bug fixes:

grant {
//Workaround for bugs #6484935, 6513799
permission java.lang.RuntimePermission "getProtectionDomain";
permission com.sun.corba.ee.impl.presentation.rmi.DynamicAccessPermission "access";
permission java.util.PropertyPermission "*", "read,write";
permission java.io.FilePermission "<<ALL FILES>>", "read,write";
// work-around for pointbase bug 4864405
permission java.io.FilePermission "$

{com.sun.aas.instanceRoot}

$

{/}lib${/}

databases$

{/}-", "delete";
permission java.io.FilePermission "${java.io.tmpdir}${/}

-", "delete";
permission javax.management.MBeanPermission "[com.sun.messaging.jms.*:*]", "*";
permission java.lang.RuntimePermission "closeClassLoader";
permission java.lang.RuntimePermission "getClassLoader";
//needed by URLClassloader.close() on JDK7
};

It is desirable to factor out these bugfixes into dedicated sections and keep the grant section empty (or with default set of standard permissions).



 Comments   
Comment by Joe Di Pol [ 18/Jan/12 ]

Too late to fix in 3.1.2





[GLASSFISH-17026] ACC should not exit after authentication failure Created: 13/Jul/11  Updated: 25/Apr/14

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

Type: New Feature Priority: Major
Reporter: mkarg Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit de_DE



 Description   

Currently (GFv2ur2, GFv3.1) GlassFish's Application Client Container ("ACC") exits on a failed authentication. This is not very smart. For example, if the user had a typo in the password, it might be better to give the user a second try instead of immediately failing.

Also, existing callbacks should get fired to show a localized message like "Invalid username, please try again." oder "Invalid password, please try again." for the second attempt.

After several attempts it might be OK to fail, but there should be at least an invocation to the JAAS callbacks then, so a GUI can show the reason (like "Too many failing attempts, application will exit now for security reasons.").



 Comments   
Comment by Tim Quinn [ 13/Jul/11 ]

If I recall correctly the system should offer the user up to three tries to enter a valid username and password.

I need to check something in the ACC before I transfer this but the security module is where the retry is implemented.

Comment by mkarg [ 14/Jul/11 ]

I see. At least over here, all GFv3.1.1_b11 instances (and 3.1 and 2ur2) only ask once then fail with security exception. Maybe the problem is that we configured our own graphical callback?

Comment by Tim Quinn [ 14/Jul/11 ]

I am transferring this to the security component which is where the retry logic lives.

Comment by mkarg [ 10/Jul/12 ]

No progress since one year?





[GLASSFISH-17370] GlassFish requires the keystore to have the same password as the truststore. Created: 28/Sep/11  Updated: 25/Apr/14

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

Type: Improvement Priority: Major
Reporter: Amy Roh Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

GlassFish requires the keystore to have the same password as the truststore. OpsCenter integration requires a different keystore and truststore password.



 Comments   
Comment by Amy Roh [ 29/Nov/11 ]

Assign to Kumar in security to support for dynamic keystores.





[GLASSFISH-17105] Dynamic mapping of roles to groups Created: 26/Jul/11  Updated: 25/Apr/14

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

Type: New Feature Priority: Major
Reporter: mkarg Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit de_DE



 Description   

By default, as role "Foo" is mapped to the user group "Foo". This mapping can be modified by using a glassfish-application.xml file containing <security-role-mapping> elements, allowing to map "Foo" to a group or user "Bar" (or a set of them).

Since companies are changing rather often, groups are changing: New groups are defined, old ones are liquidated. Each time this happens, the change must reflect in GlassFish. Unfortunately this means redeployment, as the glassfish-application.xml file is statically bound to the EAR and there is no other, "dynamic", means of role mapping.

My proposal is to define the mapping outside of the EAR by means of GlassFish-administered objectes (like the realms are already).

For example, the JDBC realm could get enhanced in a way that allows to define a database table that maps roles to groups. Using this table in a JOIN with the already used users table, no measurable additional costs have to be spend at runtime. The JOIN is rather simple, and only few additional properties are needed:

  • Name of the Table for the mapping
  • Name of the Column holding <role-name>
  • Name of the Column holding <group-name>

This not only allows more flexibility, it also allows external tools to provide this mapping. For example, a web shop application GUI this way can allow the users to defined groups using the shop application itself, instead of using XML tools.



 Comments   
Comment by mkarg [ 10/Jul/12 ]

Any comments?

Comment by arjan tijms [ 15/Dec/12 ]

Slightly related to this: what about making mapping optional? Standalone applications that take care of their own user management do not need any mapping at all.

There is a setting now in GlassFish that enables this mode (no mapping), but this setting can only be changed via a graphical UI which makes it hard for portable applications to depend on this setting (they e.g. have to ask for this in a readme).





[GLASSFISH-18455] Loading truststore fails if the truststore contains an expired cert Created: 06/Mar/12  Updated: 24/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 3.1.2, 4.0
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In 3.1.2, users upgrading from an old (e.g., vintage 2.x) installation of GlassFish report server start-up failures. Some secure admin upgrade logic runs to update the configuration from pre-3.1.2 to 3.1.2 for the secure-admin element. Part of that logic requires using the keystore, obtained by delegating to SSLUtils.getKeystore(). SSLUtils loads the keystore and truststore at the same time.

The presence of a now-expired cert in the truststore causes SSLUtils to propagate an exception up the stack, further causing the upgrade code to fail which aborts the start-up.

There should be a way to load the keystore and truststore so that the presence of an expired entry does not cause the load to fail.






[GLASSFISH-18602] HTTP Redirect port is ignored if listener port is 80 Created: 06/Apr/12  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: emmanueldufour Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 pro 64bit, java 1.6



 Description   

The automatic redirection of requests from regular HTTP to HTTPS in case the web application requires a secure protocol can be set up in the administration web interface in configurations > server-config>network listener>http-listener1> http tab> redirect port field

so that :
http://servername:httpport
gets redirected to :
httpS://servername:httpSport

However it doesnt work if the http port is 80, in that case the https port is always 443 - more precisely the port is omitted from the redirect url in the http "moved temporarily" message)



 Comments   
Comment by emmanueldufour [ 06/Apr/12 ]

as a side problem, the redirect port field cant be blanked after it has been set. On pressing the button save after deleting the value, the previous value is displayed again

Comment by Shing Wai Chan [ 06/Apr/12 ]

The redirect is triggered by a security constraint. In this case, the url is constructed by security module.





[GLASSFISH-18285] wrong caller principal in @PermitAll annotated call Created: 31/Jan/12  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: andydr Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude

 Description   

We are facing a problem, when an authenticated client calls a @PermitAll annotated method.
The session context caller name is always ANONYMOUS instead of the authenticated user name. If we change the annotation to @RolesAllow(..) the caller name is correct.

Here's a sample code:

 
@Stateless
@PermitAll
public class A {

  @Resource
  private SessionContext ctx;

  public void methodA() {
    String principleName = ctx.getCallerPrinciple().getName();
  }
}

Is there a reason, why the caller name is not propagated?






[GLASSFISH-18315] admin console prompts for username password when using glassfish with karaf Created: 03/Feb/12  Updated: 24/Apr/14

Status: Open
Project: glassfish
Component/s: OSGi, security
Affects Version/s: 3.1.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File gf-karaf-properties.jar    
Tags: 3_1_2-exclude

 Description   

When we embed GlassFish in Apache Karaf (karaf.apache.org), admin console prompts for user name and password and no combination works. To reproduce follow the simple steps given below:

1) Download and install http://karaf.apache.org/index/community/download.html#Karaf2.2.5
2) cd apache-karaf-2.2.5
3) jar xvf gf-karaf-properties.jar
4) Run ./bin/karaf
You will get a prompt like karaf@root>
5) karaf@root> install file:/path-to-glassfish3/glassfish/modules/glassfish.jar
This will print a bundle id (likely to print 49)
6) karaf@root> start 49
You will see some output like "deduced install root blah blah blah..."
7)Now open admin console in browser. You shall see it prompting for user name and password.

To debug what's going on, replace the command in step #2 by following command (all in one line):
KARAF_DEBUG=true JAVA_DEBUG_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009" ./bin/karaf



 Comments   
Comment by Sanjeeb Sahoo [ 03/Feb/12 ]

Properties patch to get rid of javax.annotation.ManagedBean class issue and logging NPE seen using GF in Karaf.

Comment by Joe Di Pol [ 03/Feb/12 ]

Deferring from 3.1.2 release. Not a regression. Not a showstopper.

Comment by Anissa Lam [ 09/Feb/12 ]

I followed the instruction, and use the glassfish.jar from 3.1.2 promoted build 21 .
Although the login screen showed up (which shouldn't) and require you to login, I can login successfully by providing "admin" as username and an empty password, which is the out-of-box configuration.

I can also logout and login again doing the same. "admin" with empty password. Also can create another admin user and set a password.

We need to see why anonymous login is returning false which prevents us from bypassing the login screen. But at least you can login to console.

Comment by Sanjeeb Sahoo [ 09/Feb/12 ]

Anissa,

I am glad user can at least login. Let's hope that you can find the root cause behind prompting of login screen in this case and fix it too.

Sahoo

Comment by Anissa Lam [ 09/Feb/12 ]

yes, looking into that.

Comment by Anissa Lam [ 09/Feb/12 ]

Where can i see glassfish server.log ?
The etc/java.util.logging.properties has
com.sun.enterprise.server.logging.GFFileHandler.file=/tmp/server.log

the file created ok, but it is empty.

Comment by Anissa Lam [ 09/Feb/12 ]

I see that __anonymous-user-enabled returns false, saying The anonymous user is disabled. Thus console puts out the login screen.

Tracing this in the backend login code, everything seems fine until in LoginContextDriver.java doPasswordLogin(Subject subject).

Line# 381:
LoginContext lg = new LoginContext(jaasCtx, s, dummyCallback);
is throwing a LoginException, cause is "No LoginModules configured for fileRealm".

Thus the userName in this line:
String userName = su.getAnonymousUser(habitat); in IsAnonymousUserEnabledCommand becomes null and 'anonymousUserEnabled' in the actionReport is set to false, causing GUI to prompt for user login.

I am assigning this to security.

Comment by Anissa Lam [ 09/Feb/12 ]

put back OSGI as component, it was accidentally removed.





[GLASSFISH-18308] [CTS] AccessControlException running endpoint publishing with grant in server.policy file Created: 02/Feb/12  Updated: 22/Mar/13

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

Type: Bug Priority: Major
Reporter: Dennis MacConnell Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File cts.out     Text File server.log    
Tags: 3_1_2-exclude, 3_1_2-next

 Description   

I'm getting a some failures running a few CTS jaxws endpoint publishing tests.

<snippet from server log>
[#|2012-02-02T06:39:05.469-0500|FINEST|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=117;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper;MethodName=doImplies;|JACC Policy Provider: PolicyWrapper.implies, context (WSW2JDLEndpointTest/WSW2JDLEndpointTest_web_war)- result was(false) permission (("javax.xml.ws.WebSefalservicePermission" "publishEndpoint"))|#]

[#|2012-02-02T06:39:05.469-0500|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=117;_ThreadName=Thread-2;|Exception occurred: java.security.AccessControlException: access denied ("javax.xml.ws.WebServicePermission" "publishEndpoint")|#]

The server.policy file gets updated with the following grant with CTS and you would think that
the access would be granted.

<snippet from server.policy>

grant {
     permission javax.security.auth.AuthPermission "doAsPrivileged";
     permission javax.security.auth.AuthPermission "modifyPrincipals";
     permission javax.security.auth.AuthPermission "modifyPublicCredentials";
     permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
     permission javax.security.auth.AuthPermission  "createLoginContext.fileRealm";
     permission javax.security.auth.PrivateCredentialPermission
                "com.sun.enterprise.security.auth.login.common.PasswordCredential * \"*\"", "read";
     permission org.osgi.framework.AdminPermission "*", "*";
     permission javax.xml.ws.WebServicePermission  "publishEndpoint";
     permission java.security.SecurityPermission   "getPolicy";
     permission java.security.SecurityPermission   "setPolicy";
     permission javax.net.ssl.SSLPermission        "setHostnameVerifier";
};

I attached the CTS run log and the server log with security log settings bumped up to FINEST.



 Comments   
Comment by Dennis MacConnell [ 02/Feb/12 ]

This issues was reported by Dennis MacConnell

Comment by Dennis MacConnell [ 02/Feb/12 ]

I forgot to mention that the test only fails with security manager enabled.

Comment by Joe Di Pol [ 06/Feb/12 ]

Additional information from an e-mail thread:

In the past I have been setting the props in CTS to false:

<snippet from ts.jte>
  http.server.supports.endpoint.publish=false
  http.server.supports.endpoint.publish.2=false

I'm not sure I like that idea anymore and I want to have this issue 
reinvestigated.

Comment by jitu [ 07/Feb/12 ]

IIRC, the test is negative testcase. One shouldn't be granting WebServicePermission/publishEndpoint in the appserver.

So the Endpoint.publish() would throw an exception and the CTS test would be looking for the exception.

Comment by kumarjayanti [ 07/Feb/12 ]

While that is true, there is something strange about this permission.

In JavaSE environment if i add an explicit grant in my Policy File then a simple example performing Endpoint.publish passes when Security Manager is ON.

permission javax.xml.ws.WebServicePermission "publishEndpoint";

But the same thing is not happening in JavaEE environment, despite the explicit Grant the CTS test (and even a simple testcase where we check for WebServicePermission inside a Servlet) fails . And my experiments yesterday show that this strange behavior in JavaEE is only for this Particular Permission. When i try with other permissions that exist in java world there are no problems, the behavior is as expected (if the grant is present then permission check succeeds and if its not then permission check fails).

Comment by Dennis MacConnell [ 07/Feb/12 ]

The same set of tests fail running against glassfish-3.1.1-b12.zip with security manager enabled.

Comment by Lukas Jungmann [ 14/Feb/12 ]

I tested this also on Tomcat 5.5 and 7 and if I grant WebServicePermission in catalina.policy then I'm able to pass the security check in Metro (EndpointImpl class), so the issue seems to be Glassfish specific. Also note that the grant itself works correctly in Glassfish v2. So only Glassfish v3 seems to be affected (tested GF 3.0.1, 3.1.1 and 3.1.2 (branch))

here is what I've done:

I put following into server.policy

grant {
    permission javax.xml.ws.WebServicePermission "publishEndpoint";
    permission java.security.SecurityPermission "getPolicy";
};

I started glassfish with enabled security manager (using -Djava.security.manager)

I created a simple servlet with following snippet in it:

            URL codebase = null;
            try {
                codebase = new File("/home/lukas/NetBeansProjects/permissions-gf/build/web").toURL();
            } catch (MalformedURLException e) {
            } catch (IOException e) {
            }
            CodeSource cs = new CodeSource(codebase, new Certificate[0]);
            PermissionCollection pcoll = Policy.getPolicy().getPermissions(cs);
            Enumeration en = pcoll.elements();
            for (; en.hasMoreElements();) {
                Permission p = (Permission) en.nextElement();
                out.println(p);
                out.println("<br/>");
            }
            SecurityManager sm = System.getSecurityManager();
            try {
                sm.checkPermission(new WebServicePermission("publishEndpoint"));
                out.println("<br/>");
                out.println("<h3>ok</h3>");
                out.println("<br/>");
            } catch (Throwable t) {
                t.printStackTrace(out);
            }

now when I run this servlet what I expect is that it prints out "OK" and no stacktrace (this is the case on Tomcat) but what I get is a stacktrace (on GlassFish)

I also tried to create custom Permission implementation and this gets applied/granted correctly, so it really seems that the issue is about WebServicePermission only.

Interesting thing here is that "javax.xml.ws.WebServicePermission" "publishEndpoint" is included in Policy.getPolicy().getPermissions(cs); but the permission itself is not being granted - this can be seen also in GlassFish logs if security logger level is set to ALL.

I also tried to check the difference between Tomcat and GlassFish web container sources and I haven't seen any major differences

Any idea where or how to follow up? What to try?

Thanks

Comment by kumarjayanti [ 15/Feb/12 ]

Thanks for the analysis.

But what is strange is that the problem on GlassFish manifests only for this One Permission WebServicePermission. If you try any other permission checks (Any Permission defined in Java SE or EE) then you will see that putting the grant in server.policy makes the permission check to pass and removing the grant makes the permission check to fail.

But only for WebServicePermission putting the grant somehow still does not help and the check continues to fail. This makes me suspect that there is something special about this permission implementation that is causing this.

Comment by Joe Di Pol [ 17/Feb/12 ]

This fix did not make the 3.1.2 release. Tagging for consideration in the next update release.





[GLASSFISH-18297] security module prevents the domain to start when javax.ejb is not in module directory Created: 01/Feb/12  Updated: 25/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 3.1.2_b20, 4.0_b22
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 3.1.2


Tags: 3_1_2-exclude, glassfish, minnow, secuirty

 Description   

As part of minnow distribution, we need to be able get rid of ejb related jars. I removed javax.ejb.jar and ejb-internal-api.jar from modules directory and then tried to start the domain. I did all the following experiments on a 3.1.2-minnow branch local workspace. The current goal is to be able to start the domain and deploy a simple war file without javax.ejb.jar and ejb-internal-api.jar present in the modules directory.

1) An other issue is happening before this one first, you need to apply the following workaround to see the issue:

  • update dol.jar's manifest file with the following entry in Import-Package section:
    javax.interceptor;resolution:=optional;version="3.1"
    

2) Then you also need to update security.jar's manifest with the following entries in Import-Package section:

javax.ejb;resolution:=optional;version="3.1"
org.glassfish.ejb.api;resolution:=optional;version="3.1"

3) start the domain, the following trace appears in the server.log:

[#|2012-02-01T19:33:44.424+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=10;_ThreadName=Thread-2;|Unable to start v3. Closing all ports
org.jvnet.hk2.component.ComponentException: injection failed on com.sun.enterprise.v3.admin.AdminAdapter.authenticator with interface org.glassfish.internal.api.AdminAccessController
	at org.jvnet.hk2.component.InjectionManager.error_injectionException(InjectionManager.java:284)
	at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:161)
	at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:93)
	at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:126)
	at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
	at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
	at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
	at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:703)
	at java.util.AbstractList$Itr.next(AbstractList.java:345)
	at com.sun.enterprise.v3.services.impl.GrizzlyService.registerNetworkProxy(GrizzlyService.java:492)
	at com.sun.enterprise.v3.services.impl.GrizzlyService.postConstruct(GrizzlyService.java:407)
	at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
	at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
	at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
	at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
	at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
	at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
	at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
	at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.jvnet.hk2.component.ComponentException: injection failed on com.sun.enterprise.container.common.GenericAdminAuthenticator.snif with class com.sun.enterprise.security.SecuritySniffer
	at org.jvnet.hk2.component.InjectionManager.error_injectionException(InjectionManager.java:284)
	at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:161)
	at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:93)
	at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:126)
	at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
	at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
	at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
	at org.jvnet.hk2.component.Habitat.getComponent(Habitat.java:798)
	at com.sun.hk2.component.InjectInjectionResolver.getServiceInjectValue(InjectInjectionResolver.java:147)
	at com.sun.hk2.component.InjectInjectionResolver.getValue(InjectInjectionResolver.java:88)
	at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:143)
	... 30 more
Caused by: org.jvnet.hk2.component.ComponentException: Failed to create class com.sun.enterprise.security.SecuritySniffer
	at com.sun.hk2.component.ConstructorCreator.create(ConstructorCreator.java:71)
	at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:80)
	at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
	at org.jvnet.hk2.component.Habitat.getBy(Habitat.java:1056)
	at org.jvnet.hk2.component.Habitat.getByType(Habitat.java:1037)
	at com.sun.hk2.component.InjectInjectionResolver.getComponentInjectValue(InjectInjectionResolver.java:159)
	at com.sun.hk2.component.InjectInjectionResolver.getValue(InjectInjectionResolver.java:90)
	at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:143)
	... 41 more
Caused by: java.lang.NoClassDefFoundError: javax/ejb/Stateless
	at com.sun.enterprise.security.SecuritySniffer.<clinit>(SecuritySniffer.java:70)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at java.lang.Class.newInstance0(Class.java:355)
	at java.lang.Class.newInstance(Class.java:308)
	at com.sun.hk2.component.ConstructorCreator.create(ConstructorCreator.java:65)
	... 50 more
Caused by: java.lang.ClassNotFoundException: javax.ejb.Stateless not found by org.glassfish.main.security [16]
	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 58 more
|#]

I tracked the usage of javax.ejb package in the following class:

  • security/core/src/main/java/com/sun/enterprise/security/SecuritySniffer.java

I also tracked the usage of org.glassfish.ejb.api package in the following class:

  • security/core/src/main/java/com/sun/enterprise/security/authorize/EJBPolicyContextDelegate.java


 Comments   
Comment by Joe Di Pol [ 01/Feb/12 ]

Excluding from 3.1.2 release since this is not a stopper for 3.1.2





[GLASSFISH-19102] Creating (misscofigured) jdbcRealm disables usage of other secure Realm Created: 24/Sep/12  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Erwin37 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Red Hat (server machine)
Ubuntu


Tags: admin-gui, fileRealm, jdbcRealm

 Description   

How to recreate:
-Create application to protect with BASIC authentication
-define new user in "file" Realm
-configure application to use "file" Realm
(now you can use successfully file realm)
-create new jdbcRealm (probably with wrong configuration)
-restart Glassfish (via admin-gui, not asadmin which was not tested)!!

now I can't use neither jdbcRealm (if it is properly configured and I believe it is) nor file realm any more

if I dispose jdbcRealm I still can't use file realm, I need to reconfigure domain from scratches

I constantly receive

[#|2012-09-24T15:12:47.251+0200|FINEST|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.login|_ThreadID=70;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.login.LoginContextDriver;MethodName=doPasswordLogin;|doPasswordLogin fails
javax.security.auth.login.LoginException: No LoginModules configured for fileRealm
at javax.security.auth.login.LoginContext.init(LoginContext.java:273)
at javax.security.auth.login.LoginContext.<init>(LoginContext.java:382)
at javax.security.auth.login.LoginContext.<init>(LoginContext.java:459)
at com.sun.enterprise.security.auth.login.LoginContextDriver.doPasswordLogin(LoginContextDriver.java:381)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:240)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:153)
at org.glassfish.admin.rest.cli.SecurityUtil.getAnonymousUser(SecurityUtil.java:343)
at org.glassfish.admin.rest.cli.IsAnonymousUserEnabledCommand.execute(IsAnonymousUserEnabledCommand.java:73)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
at org.glassfish.admin.rest.resources.TemplateExecCommand.executeCommand(TemplateExecCommand.java:127)
at org.glassfish.admin.rest.resources.TemplateCommandGetResource.processGet(TemplateCommandGetResource.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:148)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
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:722)

#]

or similar with jdbcRealm






[GLASSFISH-19138] Unable to configure/bind acustom ldap context with user credentials Created: 09/Oct/12  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: rsoika Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish V3 / V2



 Description   

I am not absolutly sure but I think there is a configuration problem with custom resources for ldap directories.
The problem is, that when a custom ldap resoruce is configurerd in GlassFish together with additional properties for the user
pricipal and user credentials, these information seems to be ignored during binding the ldap context.
So when external ldap server requires an authenticated user to search for objects, the context object can not be used.
The following exception is throwns (for MS Active Directory)

 
javax.naming.NamingException: [LDAP: error code 1 - 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece ]; remaining name 'DC=xxxxx,DC=local'

I am creating the context object with the following code:

 
Context initCtx = new InitialContext();
ldapCtx = (LdapContext) initCtx.lookup("my.jndi.ldap-Custom-Resource");

The situation is the same on GlassFish V2 as also on GlassFish V3 (3.1.1).

When the LdapContext is setup programmatically with the same information like configured in the custom resource configuration the connection works.

To reproduce the problem:
1. create a custom ldap resoruce to an ldap server which did not allow any anonymous access.
2. lookup the resoucre from a ejb
3. try to search a object in the ldap directory
4. search fails with insufficient permission (from the external ldap server)

I have also posted this issue into the form:
http://www.java.net/forum/topic/glassfish/glassfish/unable-bind-ldap-context-custom-ressource



 Comments   
Comment by rsoika [ 12/Oct/12 ]

I think I made a fault during the setup of my resource.
When I configure an external jndi resource (instead of an custom jndi resource) everything works fine.

Maybe the other fault was that I choose 'javax.naming.directory.Directory' as the resource type.
I think 'javax.naming.ldap.LdapContext' is the right resource type to bind the ldap directory. (but javax.naming.directory.Directory works if you can bind Anonymous user)

So maybe you can close this issue?
The only thing what is really missing is a clear documentation about how to bind a ldap server into GlassFish as a jndi resource.
The best what I have found so fare was this blog:

http://javaevangelist.blogspot.de/2007/03/sun-java-system-application-server-9x_15.html

Comment by rsoika [ 19/Mar/13 ]

In the meantime I continued using my external jndi ldap resource for for my applications.
But another problem I recognized was, that the ldap resource becomes stale after some time.
I had this situation with a MS AD. First everything looks fine. But after some time (>10 minutes) the ldap server closes the 'pooled' connection. This is not recognized by the existing external jndi resource. So when you try to reuse it (simply another method call in my EJB) an exception is thrown that the connection was closed and can not be used for lookups (exception comes from the ldap server).
So at the end I came to the only solution that the jndi ldap resource can not be used.
My stateless EJB is not creating the ldap connection manually for each ldap lookup and closes the connection after the lookup.
I think you can verify this behaviour.

After I read more about java LDAP connections I understand that there is no way to verify if a connection is still valid. So there seems no way to pool ldap connections ...?
For my understanding the only way for GlassFish to pool such external jndi ldap resources would be to create a new connection each time the resource is requested from a client. But how should GlassFish be able to decide if the connection can be closed....?

Can you confirm this?





[GLASSFISH-18901] Redirect to originating page fails after authentication Created: 13/Jul/12  Updated: 24/Apr/14

Status: Open
Project: glassfish
Component/s: security, web_container
Affects Version/s: 3.1.2_b23
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: gerrycata Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SUSE Linux Enterprise Server 11 (i586)
VERSION = 11
PATCHLEVEL = 1


Attachments: Java Source File AS400LoginModule.java     Text File GF-Test-Log-2012-07-13.txt     Text File jaas-login-form.txt     Zip Archive jaas-vendor-adapters.zip    
Tags: JSR196, authentication, jaas

 Description   

I have tried every permutation of the SAM that I can find and still can not get the GF container to accept the completed authentication and redirect/forward back to the originally requested resource. The container continues to return with the j_security_check page.

The authentication module (ServerModule based) completes successfully and it works under Tomcat without an issue.

The authentication module currently uses the NameCallback, PasswordCallback, ChoiceCallback, and TextOutputCallback. Those callbacks are not handled under the GF container default callback handler but instead (from what I can gather) uses the GroupPrincipalCallback and the PasswordValidationCallback.

I have created a custom CalllbackHandler to enable handling both sets of callbacks as appropriate and so as not to have to change the authentication module which currently works in the Websphere and Tomcat environments.

I am obviously missing some setting because the container will not redirect/forward to the requested resource after completing the authentication.

The application is using filters, but the filters don't appear to be the problem as they are manipulating the URL returned from the container (j_security_check).

I have attached the project files containing my last attempt to resolve this issue.

If the files provided don't provide sufficient information to identify the piece I am missing, please let me know and I will include any omitted



 Comments   
Comment by gerrycata [ 13/Jul/12 ]

I should note that the login form is a custom form and not using the basic form authentication scheme. I have attached the login form html to this ticket.

Comment by gerrycata [ 13/Jul/12 ]

Login form

Comment by gerrycata [ 08/Apr/13 ]

Is this issue still projected to be addressed in the 4.x release as I have not seen any activity on it? I see that the 4.x release is in beta testing but I have not seen any JAAS related activity mentioned in the release notes.





[GLASSFISH-19064] Glassfish unreasonably denies access to JSF page with HTTP 403, restarting the domain fixes the problem Created: 07/Sep/12  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: arash1988 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested on Ubuntu 12.04 x86 and Debian 6 x64.



 Description   

I've got an @Startup EJB (named EJB1) which connects to an HBase database using a library in its @PostConstruct method. The library itself takes advantage of HBase's Java API. This EJB is injected into another EJB (named EJB2) of which its local interface (EJB2Local) is injected into web-module beans, including an EJB which creates a web service and a managed bean which is tied to the index.xhtml JSF page.

This is how I reproduce and fix the problem:
1. Create and start a clean Glassfish domain.
2. Deploy the ear archive.
3. Glassfish denies access to index.xhtml with an HTTP 403 error. Other parts of the application, including the web services inside the web module, work flawlessly. The following lines get inserted into server.log upon each request for index.xhtml. Starting the domain in --verbose mode does not produce more messages at this point.

INFO: JACC Policy Provider:Failed Permission Check: context (" App/App-war_war ") , permission (" ("javax.security.jacc.WebUserDataPermission" "" "GET") ")
INFO: JACC Policy Provider:Failed Permission Check: context (" App/App-war_war ") , permission (" ("javax.security.jacc.WebUserDataPermission" "" "GET:CONFIDENTIAL") ")
INFO: JACC Policy Provider:Failed Permission Check: context (" App/App-war_war ") , permission (" ("javax.security.jacc.WebUserDataPermission" "/favicon.ico" "GET") ")
INFO: JACC Policy Provider:Failed Permission Check: context (" App/App-war_war ") , permission (" ("javax.security.jacc.WebUserDataPermission" "/favicon.ico" "GET:CONFIDENTIAL") ")

4. Without undeploying the application, restart the domain and let the pre-deployed application start automatically.
5. index.xhtml loads without problems.
6. Undeploying/deploying the ear file does not reproduce the problem. To see the 403 error again, one has to create a new domain.



 Comments   
Comment by shreedhar_ganapathy [ 13/Dec/12 ]

-> Hong - please eval this and if it belongs elsewhere, please reassign.

Comment by Hong Zhang [ 13/Dec/12 ]

A reproducible use case will help us to understand the problem better.

Assign to web team to take initial look to see if the permission file needs to be fixed somehow for this use case, and reassign to appropriate category (security?) as needed.

Comment by Shing Wai Chan [ 13/Dec/12 ]

403 means there is no permission is granted for a given page.
Please provide an app to illustrate this issue.

Comment by Shing Wai Chan [ 17/Jan/13 ]

Change to security component.

Comment by james.falkner [ 15/Aug/13 ]

We are also seeing this with recent builds of Liferay on JDK 6 and 7.

[#|2013-08-15T21:09:50.938+0000|INFO|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=238;_ThreadName=http-thread-pool-8080(5);|JACC Policy Provider:Failed Permission Check: context (" liferay-portal/liferay-portal ") , permission (" ("javax.security.jacc.WebUserDataPermission" "" "GET") ") |#]

[#|2013-08-15T21:09:50.938+0000|INFO|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=238;_ThreadName=http-thread-pool-8080(5);|JACC Policy Provider:Failed Permission Check: context (" liferay-portal/liferay-portal ") , permission (" ("javax.security.jacc.WebUserDataPermission" "" "GET:CONFIDENTIAL") ") |#]




[GLASSFISH-18993] RealmAdapter.createFailOveredPrincipal results in excepcion when LdapRealm is used Created: 11/Aug/12  Updated: 10/May/15

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

Type: Bug Priority: Major
Reporter: rickyepoderi Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux magneto 3.2.0-3-amd64 x86_64 GNU/Linux (debian wheezy)



 Description   

I posted this question in the forums but as nobody said nothing I have decided to open a bug. I am trying to implement a couchbase session manager for glassfish (https://github.com/rickyepoderi/couchbase-manager) and trying to maintain the Security Contenxt in an application that uses JavaEE Security I found an issue.

Currently my application saves in the external repo only the username of the logged user (I checked implementation of the ReplicationStore http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/web/web-ha/src/main/java/org/glassfish/web/ha/session/management/ReplicationStore.java). This way when the client accesses another server, the manager retrieves the session from the repo, it gets the username and performs a silently login using RealmAdapter.createFailOveredPrincipal to get all the principals (http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java). This works perfectly with FileRealm but if I use a LdapRealm it produces the following exception:

[#|2012-07-28T16:21:28.190+0200|WARNING|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=24;_ThreadName=Thread-2;|SEC1114: Exception in LdapRealm when trying to locate groups for user.
java.io.IOException: Incorrect AVA format
at sun.security.x509.AVA.readChar(AVA.java:564)
at sun.security.x509.AVA.(AVA.java:185)
at sun.security.x509.AVA.(AVA.java:145)
at sun.security.x509.RDN.(RDN.java:151)
at sun.security.x509.X500Name.parseDN(X500Name.java:935)
at sun.security.x509.X500Name.(X500Name.java:165)
at sun.security.x509.X500Name.(X500Name.java:152)
at com.sun.enterprise.security.auth.realm.ldap.LDAPRealm.getGroups(LDAPRealm.java:368)
at com.sun.enterprise.security.auth.realm.ldap.LDAPRealm.getGroupNames(LDAPRealm.java:416)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:294)
at com.sun.web.security.RealmAdapter.loginForRunAs(RealmAdapter.java:659)
at com.sun.web.security.RealmAdapter.createFailOveredPrincipal(RealmAdapter.java:714)
at es.rickyepoderi.couchbasemanager.session.CouchbaseWrapperSession.fill(CouchbaseWrapperSession.java:363)
at es.rickyepoderi.couchbasemanager.session.CouchbaseManager.doSessionLoad(CouchbaseManager.java:766)
at es.rickyepoderi.couchbasemanager.session.CouchbaseManager.findSession(CouchbaseManager.java:488)
at es.rickyepoderi.couchbasemanager.session.CouchbaseManager.findSession(CouchbaseManager.java:540)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2860)
at org.apache.catalina.connector.Request.getSessionInternal(Request.java:2777)
at org.apache.catalina.connector.Request.lockSession(Request.java:4154)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:312)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ajp.AjpProcessorTask.invokeAdapter(AjpProcessorTask.java:125)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
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:679)

#]

After checking the LdapRealm (http://java.net/projects/glassfish/sources/svn/content/tags/3.1.2/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java) implementation is easy to understand that the problem is that the getGroups method in that realm expects a DN (LDAP Distinguished Name) and not the plain username.

Please, I just want to know if it can be considered as a bug in the LdapRealm implementation or if I need to change the way I implement JavaEE security retrieval (as I said I posted this question in the forums but nobody answered me, I also tried to be included in the dev list but again no answer).

Thanks!



 Comments   
Comment by mbj_whitestein [ 12/Feb/13 ]

We had the similar issue. The problem in our case was that we've used annotation RunAs with "processAgent" as principal. Workaround for us was to change sun-application.xml in a following way:

<security-role-mapping>
<role-name>processAgent</role-name>
<principal-name>CN=processAgent,CN=Users,DC=company,DC=localdomain</principal-name>
</security-role-mapping>

In other words, we've changed principal-name from simple name (processAgent) to DN - this DN doesn't even need to exist, it's just to satisfy glassfish.

Comment by rsoika [ 10/May/15 ]

I have the same problem using Glassfish 3 togehter with an Microsoft Active Directory





[GLASSFISH-18702] "Exception while visiting com/sun/gjc/spi/jdbc40/ConnectionHolder40.class" (root cause: NullPointerException) during an attempt to authenticate. Created: 08/May/12  Updated: 24/Apr/14

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

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

Windows 7 32 bits.
JDK 7.0 / JEE 6.


Tags: ConnectionHolder40, authentification, login, security

 Description   

Hello,

While attempting to authenticate using a realm based on Derby, I encounter an exception: "Exception while visiting com/sun/gjc/spi/jdbc40/ConnectionHolder40.class" that abort the process.

It's a classical (now) NullPointerException that occurs while visiting something.
We have now plenty of issues opened with such failed visitations, when attempting an action or another.

[#|2012-05-08T16:49:20.012+0200|FINEST|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=125;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper;MethodName=doImplies;|JACC Policy Provider: PolicyWrapper.implies, context (SystemeTest/WebSystemeTest_war)- result was(false) permission (("javax.security.jacc.WebResourcePermission" "/web/auditeurs/accueil/eleve/AccueilEleve.xhtml" "GET"))|#]

[#|2012-05-08T16:49:20.012+0200|FINE|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=125;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.web.integration.WebSecurityManager;MethodName=hasResourcePermission;|[Web-Security] hasResource isGranted: false|#]

[#|2012-05-08T16:49:20.013+0200|FINE|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=125;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.web.integration.WebSecurityManager;MethodName=hasResourcePermission;|[Web-Security] hasResource perm: ("javax.security.jacc.WebResourcePermission" "/web/auditeurs/accueil/eleve/AccueilEleve.xhtml" "GET")|#]

[#|2012-05-08T16:49:20.013+0200|FINEST|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.login|_ThreadID=125;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.login.LoginContextDriver;MethodName=login;|Processing login with credentials of type: class com.sun.enterprise.security.auth.login.common.PasswordCredential|#]

[#|2012-05-08T16:49:20.013+0200|FINE|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.login|_ThreadID=125;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.login.LoginContextDriver;MethodName=doPasswordLogin;|Logging in user [mlebihan] into realm: ST_Realm using JAAS module: jdbcRealm|#]

[#|2012-05-08T16:49:20.014+0200|FINE|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.appserv.security|_ThreadID=125;_ThreadName=Thread-2;ClassName=com.sun.appserv.security.AppservPasswordLoginModule;MethodName=initialize;|Login module initialized: class com.sun.enterprise.security.auth.login.JDBCLoginModule|#]

[#|2012-05-08T16:49:20.058+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=49;_ThreadName=Thread-2;|Exception while visiting com/sun/gjc/spi/jdbc40/ConnectionHolder40.class of size 10310
java.lang.NullPointerException
at org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
at org.glassfish.hk2.classmodel.reflect.util.JarArchive.onSelectedEntries(JarArchive.java:125)
at org.glassfish.hk2.classmodel.reflect.util.DirectoryArchive.parse(DirectoryArchive.java:111)
at org.glassfish.hk2.classmodel.reflect.util.DirectoryArchive.onSelectedEntries(DirectoryArchive.java:92)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

#]

[#|2012-05-08T16:49:21.605+0200|FINE|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.appserv.security|_ThreadID=125;_ThreadName=Thread-2;ClassName=com.sun.appserv.security.AppservPasswordLoginModule;MethodName=abort;|JAAS authentication aborted.|#]

[#|2012-05-08T16:49:21.605+0200|FINEST|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.login|_ThreadID=125;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.login.LoginContextDriver;MethodName=doPasswordLogin;|doPasswordLogin fails
javax.security.auth.login.LoginException: Security Exception
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:870)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
at com.sun.enterprise.security.auth.login.LoginContextDriver.doPasswordLogin(LoginContextDriver.java:382)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:240)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:153)
at com.sun.web.security.RealmAdapter.authenticate(RealmAdapter.java:514)
at com.sun.web.security.RealmAdapter.authenticate(RealmAdapter.java:455)
at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:169)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1333)
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.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
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:722)
Caused by: java.lang.SecurityException
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:871)
... 35 more

#]

Regards,

Grunt.

P.S.: This 3.1.2 release of Glassfish is really hard to stand.
I currently have to undeploy, stop glassfish, start glassfish, deploy an application to avoid another kind of "Exception while visiting... " everyone has today (the issue that tells that force deploy doesn't work, but nothing works with redeploy, in fact).

I never believed that the Glassfish team would dare to publish an application server that is failing so often.
It has NOT been tested.
I hope this 3.1.2 release will be discarded and replaced soon.



 Comments   
Comment by kumara [ 10/May/12 ]

Sorry to hear that GlassFish 3.1.2 is not working for this use case. Will it be possible for you to help by providing detailed steps to reproduce the issue so it can be investigated further? If you have already documented the steps somewhere, please add a pointer to the issue.

The two stack traces are about 1 second apart so it might end up being split into two different bugs. The first stack trace seems to be during "auto deployment" of an archive whereas the second stack trace is from an attempt to authenticate a web request.

Comment by igordcard [ 15/May/12 ]

I also have this issue and I totally support at least the part of "I currently have to undeploy, stop glassfish, start glassfish, deploy an application" for other issues I've been encountering. Please get GlassFish more stable.

Comment by mlebihan [ 28/May/12 ]

The first exception has for cause a synchronized statement in TypesImpl.java:

public TypeImpl getType(int access, String name, TypeProxy parent) {
        Class<? extends Type> requestedType = getType(access);

        TypeProxy<Type> typeProxy = types.getHolder(name, requestedType);
        synchronized(typeProxy) {
            final Type type = typeProxy.get();
            TypeImpl result;
            if (null == type) {
                if ((access & Opcodes.ACC_ANNOTATION)==Opcodes.ACC_ANNOTATION) {
                   result = new AnnotationTypeImpl(name, typeProxy);
                } else
                if ((access & Opcodes.ACC_INTERFACE)==Opcodes.ACC_INTERFACE) {
                    result = new InterfaceModelImpl(name, typeProxy, parent);
                } else {
                    result =  new ClassModelImpl(name, typeProxy, parent);
                }
                typeProxy.set(result);
                return result;
            } else {
                TypeImpl impl = (TypeImpl)type;
                if (ExtensibleTypeImpl.class.isInstance(impl)) {
                    // ensure we have the parent right
                    ((ExtensibleTypeImpl<?>)impl).setParent(parent);
                }
                return impl;
            }
        }

The "synchronized(typeProxy)" fails in a NullPointerException because it is tricked when typeProxy = null.
(here the core reason was a JDBC ressource with a wrong name, but this NullPointer still remains a trouble).

The second exception comes in many cases when an authentification fails.
However, most of time a "SECnnnn: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" message should explain what happened that made it failing.

Comment by cobre420 [ 09/Jan/13 ]

Got similar errors at GF 3.1.2.2 startup. What is the reason of this errors, how can I get rid of them?

[#|2013-01-09T14:14:27.366+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-2;|Exception while visiting netscape/applet/DerivedAppletFrame.class of size 0
java.lang.ArrayIndexOutOfBoundsException: 8
	at org.objectweb.asm.ClassReader.readUnsignedShort(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:362)
	at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
	at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
	at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
	at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
	at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
	at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
|#]

[#|2013-01-09T14:14:27.372+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-2;|Exception while visiting netscape/security/PrivilegeManager.class of size 0
java.lang.ArrayIndexOutOfBoundsException: 8
	at org.objectweb.asm.ClassReader.readUnsignedShort(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:362)
	at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
	at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
	at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
	at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
	at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
	at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
|#]

[#|2013-01-09T14:14:27.376+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-2;|Exception while visiting com/ms/security/PolicyEngine.class of size 0
java.lang.ArrayIndexOutOfBoundsException: 8
	at org.objectweb.asm.ClassReader.readUnsignedShort(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.objectweb.asm.ClassReader.<init>(Unknown Source)
	at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:362)
	at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
	at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
	at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
	at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
	at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
	at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
|#]

[#|2013-01-09T14:14:28.039+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-2;|Exception while visiting netscape/applet/DerivedAppletFrame.class of size 0
java.lang.ArrayIndexOutOfBoundsException
|#]

[#|2013-01-09T14:14:28.290+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-2;|Exception while visiting netscape/security/PrivilegeManager.class of size 0
java.lang.ArrayIndexOutOfBoundsException
|#]

[#|2013-01-09T14:14:28.293+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-2;|Exception while visiting com/ms/security/PolicyEngine.class of size 0
java.lang.ArrayIndexOutOfBoundsException
|#]




[GLASSFISH-16281] Glassfish 3.1 Certificate Login from standalone client fails if using a AppservCertificateLoginModule Created: 29/Mar/11  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: james100 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux 64 bit


Tags: 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

We are using a standalone client to connect to Glassfish 3.1 (release version under linux )
If we try and connect from our standalone client using certificate authentication it all works fine.
When we try and add a AppservCertificateLoginModule to perform authorisation based on the certificate then it fails with an iiop.login_exception. Turing on finer logging we get a

javax.security.auth.common.login.LoginException:No Certificate Credential Found
from LoginContextDriver.java:728

The same AppservCertificateLoginModule works when we connect via a JSP page it is only an iiop connect that fails.
When it fails, it enters our constructor OK but never calls our authenticateUser.
This appears to be a bug with iiop which seems to be the poor cousin these days in Glassfish. We are trying to move from Glassfish 2 but this is a blocker for us.

Our login module is currently simple eg

public class TestCertificateLoginModule extends AppservCertificateLoginModule
{
public TestCertificateLoginModule()
{
super()
_logger.info("Constructor");
}

@Override
protected void authenticateUser() throws LoginException
{
_logger.info("authenticate");
String[] groupArray=

{"ADMIN"}

;
commitUserAuthentication(groupArray);
return;
}
}

We set this up by this adding to our login.conf

certRealm:

{ test.TestCertificateLoginModule requlogLevel="FINE"; } We made glassfish use this by running asadmin set configs.config.server-config.security-service.auth-realm.certificate.property.jass-context=certRealm We are using a simple Stateless session eg @Stateless @DeclareRoles("ADMIN") @AllowRoles("ADMIN") public class TestStateless implements TestStatelessRemote { @Override public String hello() { return "hello"; } }

our sun-ejb-jar.xml contains

<enterprise-beans>
<security-role-mapping>
<role-name>ADMIN</role-name>
<group_name>ADMIN</group-name>
</security-role-mapping>
<ejb>
<ejb-name>TestStateless</ejb-name>
<jndi-name>TestStateless</jndi-name>
<ior-security-config>
<transport-config>
<integrity>required</integrity>
<confidentiality>required</confidentiality>
<establish-trust-in-target>supported</establish-trust-in-target>
<establish-trust-in-client>required</establish-trust-in-client>
</transport-config>
<sas-context>
<caller-propagation>supported<caller-propagation>
</sas-context>
</ior-security-config>

Our client code contains

InitialContext ic = new InitialContext();
TestSessionRemote t = (TestSessionRemote)ic.lookup("TestSession");
t.hello();



 Comments   
Comment by kumarjayanti [ 18/May/11 ]

Seems to be a valid bug, we never tested the AppservCertficateLoginModule with IIOP. Can you paste a full trace for this :

javax.security.auth.common.login.LoginException:No Certificate Credential Found
from LoginContextDriver.java:728

We will attempt to fix it for 3.1.1.

Comment by james100 [ 29/May/11 ]

Hi,

We gave up and moved to LDAP.
I will see if I still have some test code that generates the error

Comment by tmn [ 14/Jun/11 ]

Hi Kumar,
I'm running into this same issue of "Certificate Login from standalone client fails if using a AppservCertificateLoginModule" as described above. I would like to know your progress on solving this issue

Regards,

TMN

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-16264] Embedded GF 3.1 (re)deployment with EJBContainer causes exception: Error linking security policy for ejb-timer-service-app Created: 24/Mar/11  Updated: 21/Sep/15

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: emailnbw Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Premium 64 bit; Glassfish 3.1; JDK 1.6.0_22 32 bit


Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, bug, ejb31, embedded

 Description   

I have a JUnit test that starts up embedded glassfish 3.1 and deploys a module which contains EJBs. I placed the container init code in a @Before method so that it will be started fresh for each test like so:

//Set up the embedded EJB containers env properties
Map<String, Object> p = new HashMap<String, Object>();
p.put(EJBContainer.APP_NAME, "myapp");
p.put(EJBContainer.MODULES, new File("out/production/myapp"));
p.put("org.glassfish.ejb.embedded.glassfish.installation.root", "C:/glassfish3/glassfish");
ejbC = EJBContainer.createEJBContainer(p);

I also have a @After method which closes the container after each test like :

@After
public void tearDown() throws Exception

{ if (ejbC != null) ejbC.close(); }

The problem I am having is that the first test method deploys and runs fine, however, subsequent test methods fail on deployment with the following exception thrown by the EJBContainer.createEJBContainer(p) line of code above:

Mar 24, 2011 10:21:32 AM com.sun.ejb.containers.EjbContainerUtilImpl deployEJBTimerService
INFO: Loading EJBTimerService. Please wait.
classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@167a209
Mar 24, 2011 10:21:32 AM org.hibernate.validator.engine.resolver.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
Mar 24, 2011 10:21:32 AM org.eclipse.persistence.session.file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App
INFO: EclipseLink, version: Eclipse Persistence Services - 2.2.0.v20110202-r8913
Mar 24, 2011 10:21:36 AM org.eclipse.persistence.session.file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App
INFO: file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App login successful
Mar 24, 2011 10:21:36 AM com.sun.ejb.containers.TimerBeanContainer <init>
INFO: [TimerBeanContainer] Created TimerBeanContainer: TimerBean
Mar 24, 2011 10:21:36 AM com.sun.ejb.containers.BaseContainer initializeHome
INFO: Portable JNDI names for EJB TimerBean : [java:global/ejb-timer-service-app/TimerBean, java:global/ejb-timer-service-app/TimerBean!com.sun.ejb.containers.TimerLocal]
classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@167a209
Mar 24, 2011 10:21:36 AM org.glassfish.api.ActionReport failure
SEVERE: Exception while loading the app
Mar 24, 2011 10:21:36 AM org.eclipse.persistence.session.file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App
INFO: file:/C:/Users/nwhite/AppData/Local/Temp/gfembed8734725078398943370tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App logout successful
Mar 24, 2011 10:21:36 AM com.sun.ejb.containers.EjbContainerUtilImpl deployEJBTimerService
WARNING: Cannot deploy or load EJBTimerService:
org.glassfish.deployment.common.DeploymentException: Error in linking security policy for ejb-timer-service-app – Inconsistent Module State
at com.sun.enterprise.security.SecurityUtil.linkPolicyFile(SecurityUtil.java:335)
at com.sun.enterprise.security.SecurityDeployer.linkPolicies(SecurityDeployer.java:279)
at com.sun.enterprise.security.SecurityDeployer.access$100(SecurityDeployer.java:81)
at com.sun.enterprise.security.SecurityDeployer$AppDeployEventListener.event(SecurityDeployer.java:114)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:262)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at com.sun.ejb.containers.EjbContainerUtilImpl.deployEJBTimerService(EjbContainerUtilImpl.java:547)
at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:289)
at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:284)
at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:269)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:755)
at com.sun.ejb.containers.AbstractSingletonContainer.<init>(AbstractSingletonContainer.java:141)
at com.sun.ejb.containers.CMCSingletonContainer.<init>(CMCSingletonContainer.java:77)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:115)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:193)
at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:142)
at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:135)
at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:132)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)

During the shutdown process after the first test runs I noticed the following:

Mar 24, 2011 10:21:19 AM com.sun.ejb.containers.TimerBeanContainer doConcreteContainerShutdown
INFO: [TimerBeanContainer] Shutdown() called....
Mar 24, 2011 10:21:19 AM com.sun.ejb.containers.EJBTimerService onShutdown
INFO: EJB5122:EJB Timer Service shutdown at [2011/03/24 10:21:19]
Mar 24, 2011 10:21:19 AM com.sun.enterprise.web.WebContainer unloadWebModule
SEVERE: WEB0162: [WebContainer] Undeployment failed for context [/ejb-timer-service-app]
Mar 24, 2011 10:21:19 AM org.eclipse.persistence.session.file:/C:/Users/nwhite/AppData/Local/Temp/gfembed671660783214676050tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App
INFO: file:/C:/Users/nwhite/AppData/Local/Temp/gfembed671660783214676050tmp/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App logout successful



 Comments   
Comment by marina vatkina [ 24/Mar/11 ]

Note that the same error can be observed by uncommenting lines marked "** Run the 2nd time **" in client/Client.java under v2/appserv-tests/devtests/ejb/ejb31/embedded/timertest (updated today) and do 'ant all'

Comment by kumarjayanti [ 18/May/11 ]

Please provide us a testcase.

Comment by scatari [ 25/Jun/11 ]

Closing this issue as a reproducible test case hasn't been provided. Please reopen once you have the test case.

Comment by emailnbw [ 25/Jun/11 ]

I am confused by scatari's actions. It appears from that history that kumarjayanti has marked this bug as fixed in 3.1.1 with checkin 14740. Is this not the case?

If this is not the case then there are plenty of details in the original bug report to set up your own test case. In addition Marina has also described how to reproduce this issue.

What more needs to be spoon fed?

This bug makes it impossible to effective unit test with isolated JUnit tests using Embedded Glassfish. Considering one of Embedded Glassfish's important use cases is to make unit testing your EJB easier I think this is a rather important bug to fix.

Comment by scatari [ 25/Jun/11 ]

No updates to the bug since 18/May with the final comment being a request to send a test case. I don't see a comment about 14740 in this tool.

Comment by emailnbw [ 25/Jun/11 ]

@scatari If you click on the 'All' tab in JIRA (I assume you must being using the same JIRA web interface?!) you will see on May 18th right below kumarjayanti's comment about requesting a test case he set the "Fix Version/s" field to 3.1.1 [14740]. To me, that implies a fix was checked in. Does it not?

Once again, there is plenty of detail in my original submission for kumarjayanti (or anyone else) to write a test for this. And again, Marina's comments on 3/24 also spell out how to reproduce this issue using your own devtests!

Comment by kumarjayanti [ 26/Jun/11 ]

The security team and Marina are actively discussing how to fix this...

Comment by marina vatkina [ 27/Jun/11 ]

As everybody said, it was wrong to close it

Comment by scatari [ 27/Jun/11 ]

Can we update the bug as when we have information to show the progress? Not seeing any update to the bug for a month does not prove that it is being worked on.

Comment by marina vatkina [ 06/Jul/11 ]

patch for static refs in the ejb-container

Comment by marina vatkina [ 06/Jul/11 ]

With the currant security hack in 3.1.1, and my patch attached to this issue, the 2nd TS start fails with:

[java] Jul 6, 2011 2:07:11 PM com.sun.enterprise.security.provider.BasePolicyWrapper logMsg
[java] INFO: JACC Policy Provider:Failed Permission Check: context (" ejb-timer-service-app/ejb-timer-service-app_internal ") , permission (" (javax.security.jacc.EJBMethodPermission TimerBean findActiveTimersOwnedByThisServer,Local,) ")
[java] Jul 6, 2011 2:07:11 PM com.sun.ejb.containers.BaseContainer postInvoke
[java] WARNING: A system exception occurred during an invocation on EJB TimerBean method public java.util.Set com.sun.ejb.containers.TimerBean.findActiveTimersOwnedByThisServer()
[java] javax.ejb.AccessLocalException: Client not authorized for this invocation.

Comment by marina vatkina [ 06/Jul/11 ]

The patch is checked in into trunk with rev 47893.

Comment by marina vatkina [ 07/Jul/11 ]

The patch is checked in with rev 47907 to 3.1.1 branch

Comment by scatari [ 11/Jul/11 ]

Fixed in B11.

Comment by marina vatkina [ 11/Jul/11 ]

The security part is not fixed. The EJB part is.

Comment by Cheng Fang [ 13/Jul/11 ]

Assign it to me.

Comment by Cheng Fang [ 15/Jul/11 ]

Stacktrace for the permission check error:

     [java] WARNING: A system exception occurred during an invocation on EJB TimerBean method public java.util.Set com.sun.ejb.containers.TimerBean.findActiveTimersOwnedByThisServer()
     [java] javax.ejb.AccessLocalException: Client not authorized for this invocation.
     [java] 	at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1885)
     [java] 	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
     [java] 	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
     [java] 	at $Proxy130.findActiveTimersOwnedByThisServer(Unknown Source)
     [java] 	at com.sun.ejb.containers.EJBTimerService.restoreEJBTimers(EJBTimerService.java:486)
     [java] 	at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:307)
     [java] 	at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:289)
     [java] 	at com.sun.ejb.containers.EjbContainerUtilImpl.getEJBTimerService(EjbContainerUtilImpl.java:274)
     [java] 	at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:755)
     [java] 	at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:155)
     [java] 	at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:149)
     [java] 	at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:105)
     [java] 	at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
     [java] 	at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
     [java] 	at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
     [java] 	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
     [java] 	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
     [java] 	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
     [java] 	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
     [java] 	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
     [java] 	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
     [java] 	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:129)
     [java] 	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:105)
     [java] 	at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:140)
     [java] 	at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:134)
     [java] 	at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
     [java] 	at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:102)
     [java] 	at com.acme.Client.test(Client.java:81)
     [java] 	at com.acme.Client.main(Client.java:70)
Comment by Cheng Fang [ 15/Jul/11 ]

After applying Kumar's hack (related to inService check) to 3.1.1 build, the ejbdev test embedded/timertest passed when running the second timer tests. I tried the test run several times w/ the same result.

The ejb error Kumar was seeing before (Caused by: java.lang.NoSuchFieldError: moduleName) looks like a setup issue. moduleName field was recently added to 3.2, but not to 3.1.1. When runnign w/ 3.1.1, there should be no trace of it. With 3.2, it should be resolved correctly.

Re-assign to security team to pursue a formal fix.

Comment by syvalta [ 15/Jun/12 ]

Could the "Fix version" be updated as this is still open and 3.1.2 has already been released?

Comment by markds [ 10/Jan/13 ]

Can I ask what is happening with this bug? It still occurs in 3.1.2.2





[GLASSFISH-16093] Rest conversion and CLI based design breaks automatic usermanagement for realms that do not extend FileRealm Created: 23/Feb/11  Updated: 25/Apr/14

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

Type: Bug Priority: Major
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3-1_exclude, 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

In V3.0.1 the console backend would directly use API;s on the Realm (createUser, deleteUser, updateUser and persist) for the ManageUsers function. But now with the CLI based design it would invoke CLI commands create-file-user, delete-file-user etc. This restricts the custom realms to extend FileRealm if they need to get automatic user management.

Fix : create more generic CLI commands called create-user, delete-user , update-user and make the console use those commands (make it FileRealm agnostic). For the FileRealm these new commands can internally delegate to the existing command codes.



 Comments   
Comment by Anissa Lam [ 23/Feb/11 ]

Does it mean GUI code needs to call create-user instead of create-file-user ?
If so, please open up a bug against GUI that depends on this fix, so that we can make the necessary code change in GUI.

Comment by kumarjayanti [ 05/Jun/11 ]

this is a big change for 3.1.1 and we do not have time. Impacts CLI and Rest

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-16474] Initialize AuditManager and Modules as Startup Service : Primarily to account for serverStarted() event Created: 27/Apr/11  Updated: 19/Mar/13

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

Type: Improvement Priority: Major
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred

 Description   

In GlassFish 3.X, the Security Services are started up lazily once the first application (which lists the Security Sniffer) is being deployed. This was done primarily to improve the GF V3 Startup time (Starting all the Security Services : Audit Modules, Realms, loading keystores etc. can consume a lot of time).

While this strategy works fine in general, however there is one issue. The Audit SPI exposes a method called serverStarted(). The GlassFish AuditManager is expected to startup and invoke all the registered audit modules at server startup to log/audit the serverStarted event.

Today in V3.X this particular event is logged but it is delayed until the first application is deployed (as explained above). If a fresh new instance (with no applications deployed) is started and stopped, then neither serverStarted nor serverStopped audit events are logged.

This improvement is to try and fix this, while keeping the lazy startup of other security services. There are some complications around fixing this issue w.r.t OSGI and split-packages. Specifically all the exported public security SPI's of GlassFish are in the package com.sun.appserv.security, the AuditModule SPI is also present in this package. This legacy package is coming on since 8.X and for backward compatilbility we need to support the exact same package.

If we decide to start the AuditManger at Server Startup : a few of the other SPI's present in the same package are heavy-weight and would result in starting the entire security/core module at glassfish startup which can impede the startup performance numbers significantly from previous 3.x release.

So the plan is to introduce a new Base Interface to the Abstract AuditModule SPI. Move the AuditManager (not a publicly exposed class) along with this new Base Interface to a new separate module. Make the AuditManager a GlassFish @Startup service and make it use the new BaseInterface to load the various registered Audit Modules, including the Default GlassFish AuditModule.

A fix was contemplated in V3.1 but we could not get to it due to resource constraints.

Admin GUI/CLI Impact
-----------------
Since we are not changing the publicly exposed AuditModule SPI class (except for introducing a Base Abstract Class) there should be no change in GUI/CLI

DOC Impact
----------
None, except that javadocs would now show this new Base Abstract Class which also has to be made publicly visible.



 Comments   
Comment by kumarjayanti [ 27/Apr/11 ]

Impact on Startup Performance
-------------------------

This change will definitely impact the Startup Performance of V3.2 over V3.1. But it appears to be a necessary change because otherwise we are either completely missing OR delaying the TimeStamp on the serverStarted audit event.

Will try to make the restructuring effort as lean as possible to avoid loading additional unnecessary security classes during Server Startup.

PM should look at this bug and provide us a GO/NoGO.

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16475] Enhance existing LDAP Realm or define a new LDAP Realm which handles Failover... Created: 27/Apr/11  Updated: 25/Apr/14

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

Type: New Feature Priority: Major
Reporter: kumarjayanti Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Enhance existing LDAP Realm or define a new LDAP Realm which handles Failover and a few other features requested by developers on GF mailing lists. Here are the specific feature requests by GlassFish developers on mailing lists :

1. Failover (among list of replicas/backups),
2. possibly support a Split-LDAP (where part of the user-db is in one store and part of it is in another). This one would be lower priority for us.
3. fix problem with current LDAPRealm w.r.t UserSearch and Anonymous Login :http://forums.java.net/node/735641

The LDAP Login Module in JDK : (http://download.oracle.com/javase/6/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/LdapLoginModule.html)
has support for specifying a list of LDAP URL's (in support for item 1 and developers have indicated that it does not have problem 3 as well).

So one approach is to define a new LDAPRealm that makes use of this JDK LDAP Login Module. Then Parity with existing LDAPRealm in GlassFish in terms of its features will not be an issue. Such a realm can then be provided to developers as a separate download rather than make it part of GlassFish V3.2 code base.



 Comments   
Comment by kumarjayanti [ 27/Apr/11 ]

ADMIN GUI/CLI Impact
------------------

None. Since the Security Module is the one that defines the list of Pre-Defined Realms as a CLI, so the security team would take care of it should we decide to include this as a new Pre-Defined Realm.

The other approach is to fix the existing LDAPRealm in GlassFish to additionally support all these features in which case again there is no Impact on Admin GUI/CLI.





[GLASSFISH-16005] cannot configure ssl key-/trust-store per http-listener in admin-gui Created: 16/Feb/11  Updated: 27/Mar/13

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 3.1_b43
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: schaarsc Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed

 Description   

according to GLASSFISH-15973 the per listener configuration does not work with GlassfishSSLImpl and classname needs to be removed from ssl-element. There is no field to choose classname in admin-gui.

I think that admin-gui is the wrong place to fix this, I my opinion GlassfishSSLImpl should do the job and not the user.

Hint: you might not notice the problem if you use nickname=s1as, because then the cert from -Djavax.net.ssl.keystore is used. If you change the nickname you'll get "No available certificate" exception until you remove classname, but then you'll have to add key-store-password to ssl-element



 Comments   
Comment by Anissa Lam [ 16/Feb/11 ]

After reading the comments from GLASSFISH-15973, I am still not sure how exactly GUI should change to provide better user experience.
Request Kumar to tell me what exactly GUI should do. There seems to be discrepancy of what the user prefers to see and what Kumar believes is working by design.

I am transferring this to 'security' for input. Please tell me clearly what fields should be added/modified. thanks.

Comment by schaarsc [ 16/Feb/11 ]

Preferred solution:

  • do not change admin-gui
  • make GlassfishSSLImpl aware of key-store and trust-store attributes

if GlassfishSSLImpl cannot be changed:

  • add classname to gui
  • add key-store-password to gui
  • add trust-store-password to gui
  • add documentation what these values are good for and why / when they need to be specified
Comment by schaarsc [ 16/Feb/11 ]

I noticed that you downgraded this issue to Improvement.
I thinks it's a bug, because if you enter keystore and truststore in the admin-gui it will not do what user expects and there is no way to fix it using admin-gui. domain.xml has to be edited directly.

Comment by Nazrul [ 10/May/11 ]

Lets take a look at this issue

Comment by scatari [ 25/Jun/11 ]

Marking to be considered for next release.





[GLASSFISH-21398] j_security_check protection too restrictive Created: 30/Jul/15  Updated: 30/Jul/15

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

Type: Bug Priority: Major
Reporter: xwibao Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 4.1
GlassFish nightly
Payara 4.1.152



 Description   

In GlassFish, the j_security_check special URL is by default guarded by HTTP basic auth, even if no security is configured for application.

This prevents third-party security frameworks (such as PicketLink) from installing their own handler for j_security_check, which is usually implemented as a filter. No filterchain would be invoked in this case, thus rendering form authentication unusable.

This is exactly what happens in this example. Submitting login form results in browser auth dialog popping up. (Works perfectly in TomEE and WildFly.)

GlassFish could safely ignore j_security_check if security is not configured for the application.






[GLASSFISH-21373] SPNEGO Support Created: 10/Jun/15  Updated: 10/Jun/15

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

Type: Improvement Priority: Major
Reporter: slominskir Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: authentication, authorization

 Description   

Direct support for SPNEGO is oddly missing from GlassFish. Tomcat has this already via:

org.apache.catalina.authenticator.SpnegoAuthenticator

https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#SPNEGO_Valve

Why doesn't GlassFish use this since it uses Tomcat Valves for authentication already?

I have been able to use a third party Servlet Filter to successfully authenticate:

http://spnego.sourceforge.net/

However, the filter approach is limited in the following ways:

1. Doesn't take advantage of the built-in Same-Realm SSO / credential persistence Session Cookie
2. Doesn't use container managed authorization (groups)
3. Doesn't propagate credentials to business layer EJBs

It probably is worth mentioning that there appears to be a now defunct project to use JSR 196 to do SPNEGO in GlassFish at:

https://spnego.java.net/

Aside from appearing to be abandoned and not actually a part of GlassFish it also doesn't support the SSO credential session cookie, and cannot be part of an existing security Realm.

Being part of an existing security Realm and supporting the persistent SSO Cookie appears to be one way to allow integration into an existing Intranet application server that must continue to support the container managed form-based username and password authentication as well. The use of SPNEGO would be a convenient alternative for those use who happen to be on the local network, but the web applications must be accessible via form based login as well. Perhaps there is another way that SPNEGO and traditional form-based container managed security can work together?






[GLASSFISH-20869] Provide a way to change SSO cookie name Created: 23/Oct/13  Updated: 24/Apr/14

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

Type: New Feature Priority: Major
Reporter: haducloc13 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All environments



 Description   

No way to change the name of SSO cookie name now. It was fixed "JSESSIONSSO".






[GLASSFISH-20841] GlassFish submits wrong Client certificate and throws bad_certificate SSL error from Webservice Created: 02/Oct/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: gfuser9999 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
  • GlassFish 2.1.x (if httpsOutBoundKeyAlias is set)
  • GFv301x
  • GFv312x
  • GFv4

Tags: Axis, SSL, bad_certificate, certificate, chooseClientAlias, client, handshake, https, s1as

 Description   

Background

This problem happens especially in GFv3.x as the following
JVM options is added -Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
The impact of this is that it sets the default client cert
to be sent is s1as.

Although this option is there is GFv2, it was not enabled in the JVM
options. So no issues unless one set it. Now the internals of GFv3 opensource
suggest that on startup
1) GFv301 will replace the HttpsURLConnection setDefault to have
a KeyManager that will sent "httpsOutboundKeyAlias"/s1as is client cert
is requested.
2) Gfv312 also does this
3) Now in GFv301, it does not set the SSLContext but in GFv312x
due to change GLASSFISH-15369, it seems that SSLContext.setDefault()
is called to make the SSLContext have a default key manager
that will submit s1as as the client cert if requested

Well the behaviour is that things that work say in GFv2 may not
work in GFv301 (if URLConnection to a https://... that does
optional client cert request). For example

==> https://www.java.net//forum/topic/glassfish/glassfish/axis2-generated-stub-soap-webservice-call-not-working-glassfish-312?force=516

where javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
may happen in GFV312 (but may work in GFv301) due to (3).

Now the problem is this

The issue is that
a) GFv3 set the default alias to sent the client cert globally
b) In GFv312, SSL artifact created from
HttpsURLConnection and SSLContext will have this KeyManager that
does chooseClientAlias() from X509ExtendedKeymanager and always returns s1as
irregardless if the issuer matches with s1as

Look at J2EEKeyManager.java
https://java.net/projects/glassfish/sources/svn/content/tags/3.1.2/security/core/src/main/java/com/sun/enterprise/security/ssl/J2EEKeyManager.java

As you may see, from the code, the fix/issues are:

a) Not setting com.sun.enterprise.security.httpsOutboundKeyAlias may help
(if you do not ever use client cert) but the code may always return null
for some conditions (ie: !server&!acc)
b) Even if the property is explicitly set, the chooseClientAlias
should still check if this alias is compatible with what the SSL server
requested otherwise it should return NULL

Symptom
For this issue even if you added all the SSL cert to the client trust store, if the remote SSL server ask for say an optional client cert (or required), the handshake will fail since the wrong client cert (self-signed s1as) is submitted which is totally different from the valid cert the server accepts.

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1961)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077)
at sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1707)
at sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:122)
at sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:972)
at sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1087)
at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1006)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:285)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:515)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)





[GLASSFISH-20063] GUI cannot handle mulitbyte char in the login page Created: 26/Mar/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: console

 Description   

I am able to create an admin user with multibyte char, eg 中文 through console or CLI.
In console u can create this user by:
Config -> server-config -> Security -> Realms -> admin-realm , manage User button, select and add user.

The admin-keyfile in domain1/config directory is updated correctly.

If i use CLI with this user name, and enter password, it works fine. so, it shows multibyte char is supported.
eg.
%asadmin --user 中文 create-jdbc-resources --connectionpoolid DerbyPool myJDBC

But i cannot login to console using this user name.
Also, I cannot delete this user when i go to
Config -> server-config -> Security -> Realms -> admin-realm , manage User button, select and delete it.



 Comments   
Comment by Jason Lee [ 26/Mar/13 ]

The Console login screen POSTs to j_security_check for the credential validation and does no actual user/pass handling at this point in the user experience. This seems to be an issue in the security layer, so I'm reassigning to that team for evaluation.





[GLASSFISH-19809] usage of internal proprietary API in nucleus/security/core Created: 08/Mar/13  Updated: 08/Mar/13

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

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build, maven, proprietary-api, security, warning

 Description   
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[53,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java:[63,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[70,24] ContentInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[71,24] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[72,24] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[73,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[74,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[252,30] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[504,18] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[504,42] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,33] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,66] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java:[286,46] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUPName.java:[45,27] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[56,29] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[58,37] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[60,11] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[213,12] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[213,30] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[214,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[214,38] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[215,24] ContentInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[217,24] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[217,41] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[218,25] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[220,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[221,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[368,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[368,32] X500Name is internal proprietary API and may be removed in a future release





[GLASSFISH-19805] usage of internal proprietary API in appserver/security/webintegration Created: 08/Mar/13  Updated: 08/Mar/13

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

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build, maven, proprietary-api, security, warning

 Description   
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[75,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[596,16] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[596,37] X500Name is internal proprietary API and may be removed in a future release





[GLASSFISH-19800] usage of internal proprietary API in appserver/security/inmemory.jacc.provider Created: 08/Mar/13  Updated: 08/Mar/13

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

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: build, maven, proprietary-api, security, warning

 Description   
[WARNING] appserver/security/inmemory.jacc.provider/src/main/java/com/sun/enterprise/security/jacc/provider/SimplePolicyProvider.java:[86,50] PolicyFile is internal proprietary API and may be removed in a future release





[GLASSFISH-19799] usage of internal proprietary API in appserver/security/appclient.security Created: 08/Mar/13  Updated: 08/Mar/13

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

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: appclient, build, proprietary-api, security, warning

 Description   
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[174,28] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[177,38] PropertyExpander is internal proprietary API and may be removed in a future release


 Comments   
Comment by Romain Grécourt [ 08/Mar/13 ]

update affect version





[GLASSFISH-19798] usage of internal proprietary API in appserver/security/core-ee Created: 08/Mar/13  Updated: 08/Mar/13

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

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build, proprietary-api, security, warning

 Description   
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[53,24] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[54,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[55,24] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[54,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[105,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[48,18] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[49,24] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[50,24] Password is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[68,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[69,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[69,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[116,25] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[116,39] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[127,8] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[133,8] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[138,12] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[233,32] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[264,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[299,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[372,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[385,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[435,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[443,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[462,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[505,5] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[529,11] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[543,20] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[557,11] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[568,23] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[607,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[621,39] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[671,23] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[742,11] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[746,13] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[824,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[827,29] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[995,33] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[1222,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[1230,44] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyConfigurationImpl.java:[798,37] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyConfigurationImpl.java:[870,17] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[158,56] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[561,20] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[569,26] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[599,25] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[615,25] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[433,20] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[433,45] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[434,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[435,20] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[435,45] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[436,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyWrapper.java:[75,56] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[77,12] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[94,2] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[146,35] Password is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[213,4] PropertyExpander is internal proprietary API and may be removed in a future release


 Comments   
Comment by Romain Grécourt [ 08/Mar/13 ]

change fix version





[GLASSFISH-19686] Java EE security classes are part of nucleus Created: 18/Feb/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Classes like J2EESecurityManager JavaEESecurityLifecycle are part of nucleus when they should not be.






[GLASSFISH-20377] Unable to create file users after changing key file of the file realm Created: 23/Apr/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: winston_jack Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is GlassFish 3.1.2.2 and GlassFish 4 issue.

After changing the key file of file realm of cluster,
I could not create file users.

ex)

asadmin create-auth-realm --classname com.sun.enterprise.security.auth.realm.file.FileRealm --property jaas-context=fileRealm:file=${com.sun.aas.instanceRoot}/config/keyfile1 test
asadmin set cluster.security-service.auth-realm.test.property.file=${com.sun.aas.instanceRoot}/config/keyfile2
asadmin stop-cluster cluster
asadmin start-cluster cluster
asadmin create-file-user --target cluster --authrealmname test user1

This error happened when executing asadmin create-file-user command.

The specified physical file C:\gf4b82\glassfish4\glassfish\domains\domain1/config/keyfile2 associated with the file realm test does not exist.

Likewise, if I set the key file to the other directory of glassfish (such as C:\work\keyfile),
asadmin create-file-user shows this error.
However, file users were created in the key file.

An error occurred during replication Failure: Command create-file-user failed on server instance instance: remote failure: Adding User user1 to file realm test failed. User user1 already exists.

If I tried GlassFish 2.1.1, these problem did not occur.






[GLASSFISH-20363] security devtests cert-realm-custom-loginmodule failure Created: 19/Apr/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk



 Description   

The cert-realm-custom-loginmodule security devtest is failing and has been disabled.

The client is being denied access to the test application that us using <CLIENT-CERT> authentication method.

Debug of the client SSL handshake looks fine but there is no information in the server log so further debug is needed.



 Comments   
Comment by Craig Perez [ 19/Apr/13 ]

Server log entries:

[2013-04-19T15:15:31.082-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(3)] [timeMillis: 1366409731082] [levelValue: 800] [[
cert-realm-custom-loginmodule-web was successfully deployed in 3,797 milliseconds.]]

[2013-04-19T15:15:35.145-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=100 _ThreadName=Thread-16] [timeMillis: 1366409735145] [levelValue: 800] [[
Server shutdown initiated]]





[GLASSFISH-20485] appclient -user xxx option is ignored unless -passwordfile is given Created: 08/May/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: mkarg Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.1, Win 7 Pro SP 1 (64 Bit), JDK 1.7.0_21



 Description   

Steps to reproduce:

  • appclient -name myname -client MyClient.jar

Expected result:

  • Login dialog should default user name to "myname".

Actual result:

  • Login dialog defaults user name to Windows Account.


 Comments   
Comment by Tim Quinn [ 08/May/13 ]

Updated title and component; this applies to the appclient utility

Comment by Tim Quinn [ 08/May/13 ]

The "-name" option on the appclient command specifies the name of the app client to be executed (especially if there are multiple app clients in the EAR), not to tell what username to use for authentication.

The "-user" option is used for specifying the username on the command line.

Markus, can you please confirm whether you are actually using "-name" or "-user" in your example?

Comment by mkarg [ 10/May/13 ]

Sorry for the typos, I was in a hurry.

Actually I typed:

appclient -user myname -Client MyClient.jar

And the ACC's login dialog Shows the user Name field defautled to the value "MARKUS KARG" (which seems to be taken from active directory), but not "myname".

Comment by Tim Quinn [ 24/May/13 ]

I am reassigning this to the security team.

The app client container invokes AppClientSecurityInfoImpl's constructor, passing the username (if the user provided one on the command line, null otherwise).

I looked around a little and it seems that ClientPasswordLoginModule interrogates the UsernamePasswordStore to retrieve a user-provided username and/or password but the code seems not to use those values (I concentrated on the username) in setting the default value in the callback.





[GLASSFISH-20338] security devtests ciphertest failures Created: 17/Apr/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk



 Description   

Disabled tests for ciphers:

  • SSL_RSA_WITH_DES_CBC_SHA
  • SSL_RSA_EXPORT_WITH_RC4_40_MD5

Use of -Dsun.security.ssl.allowUnsafeRenegotiation=true no impact both server and client side






[GLASSFISH-20339] security devtests wss roles failures Created: 17/Apr/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk



 Description   

Disabled the roles tests for security devtests wss suite.

[exec] Apr 12, 2013 4:41:47 PM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[exec] WARNING: ACC013: The -password option is deprecated and will likely be removed in a future release. Please use -passwordfile or let the app client container prompt for the username and/or password if they are needed to access a remote resource.
[exec] com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: java.lang.Exception: Client not authorized for invocation of public java.lang.String com.sun.s1asdev.security.wss.roles.ejbws.HelloEjb.hello(java.lang.String) Please see the server log to find more detail regarding exact cause of the failure.



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

Additionally the roles2, ssl & sslclientcert where previously disabled

  • roles2 has same/similar test failure
  • ssl and sslclientcert have build failures on wsimport looking for WSDL at HTTPS URL




[GLASSFISH-20336] ejb.security_preinvoke_exception for security devtests Created: 17/Apr/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk



 Description   

The security devtests mdb and timerStandalone have been disabled from the set of tests. These tests both fail for the same root cause:

java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

mdb test:

[2013-04-17T11:25:00.018-0700] [glassfish 4.0] [SEVERE] [ejb.security_preinvoke_exception] [javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1366223100018] [levelValue: 1000] [[
SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)
at org.glassfish.ejb.mdb.MessageBeanContainer.<init>(MessageBeanContainer.java:248)
at org.glassfish.ejb.mdb.MessageBeanContainerFactory.createContainer(MessageBeanContainerFactory.java:63)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

Comment by Craig Perez [ 17/Apr/13 ]

timeStandalone test:

[2013-04-17T11:29:06.808-0700] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=98 _ThreadName=Thread-3] [timeMillis: 1366223346808] [levelValue: 800] [[
In SfulEJB:hello()]]

[2013-04-17T11:29:06.819-0700] [glassfish 4.0] [SEVERE] [ejb.security_preinvoke_exception] [javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application] [tid: _ThreadID=98 _ThreadName=p: thread-pool-1; w: 2] [timeMillis: 1366223346819] [levelValue: 1000] [[
SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1628)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:456)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2516)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1906)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:204)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy267.hello(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
]]

Comment by bebbo [ 29/Jul/13 ]

suggested fix: add a null check and create an empty array if null.

if (groups == null)
  groups = new String[0];
return Collections.enumeration(Arrays.asList(groups));




[GLASSFISH-20337] security devtests jmac failure Created: 17/Apr/13  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk



 Description   

The security-jmac-httpservlet test in the jmac security devtests suite is failing and has been disabled.

The expected output includes an adjusted PrintWriter count that is not matching the golden files output.

Otherwise the general behavior and functional output looks correct.



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

From examining the test case, the MyHttpServletResponseWrapper.java only overrides the method write(char[] cbuf, int off, int len) and the test currently outputs a count of 0 vs 218 along with the blank lines that are not lining up 1-1 as previously.

Functionally the SAM is working but either the MyPrintWriter needs changes or the goldenfiles could be updated since the test will validate basic ServerAuthModule wrappering.

[webtest] Expected Output ****************************************
[webtest] Hello World from 196 HttpServlet AuthModule Test!
[webtest] <hr>
[webtest] Hello, shingwai123 from com.sun.s1asdev.security.jmac.httpservlet.HttpServletTestAuthModule
[webtest] PC = security-jmac-httpservlet-web/security-jmac-httpservlet-web
[webtest]
[webtest]
[webtest] <hr>
[webtest] Adjusted count: 218
[webtest]
[webtest] ********************************************************
[webtest] Actual Output ##########################################
[webtest] Hello World from 196 HttpServlet AuthModule Test!
[webtest] <hr>
[webtest] Hello, shingwai123 from com.sun.s1asdev.security.jmac.httpservlet.HttpServletTestAuthModule
[webtest] PC = security-jmac-httpservlet-web/security-jmac-httpservlet-web
[webtest]
[webtest] <hr>
[webtest]
[webtest] Adjusted count: 0





[GLASSFISH-20692] The message "jaccfactory.notfound" in WebSecurityManager is not defined in the property File. Created: 10/Jul/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: xianwu Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)



 Description   

Reproducible operational steps:

asadmin set server.security-service.jacc=h.b.aaaa

asadmin restart-domain

You can see the message below in the server.log

[2013-07-10T13:03:28.431+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core.security] [tid: _ThreadID=83 _ThreadName=Thread-15] [timeMillis: 1373425408431] [levelValue: 1000] [[
jaccfactory.notfound]]

Issues:
"jaccfactory.notfound" is not appropriate as the message logged in server.log.

Detailed description of the issue:

The message is logged by WebSecurityManager
(https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/web/integration/WebSecurityManager.java) as shown below

public class WebSecurityManager {
private static final Logger logger =
Logger.getLogger(LogDomains.SECURITY_LOGGER);
/** lines ignored **/
private synchronized PolicyConfigurationFactory _getPolicyFactory()
throws PolicyContextException {
if (pcf == null) {
try

{ pcf = PolicyConfigurationFactory.getPolicyConfigurationFactory(); }

catch(ClassNotFoundException cnfe)

{ logger.severe("jaccfactory.notfound"); throw new PolicyContextException(cnfe); }

catch(PolicyContextException pce)

{ logger.severe("jaccfactory.notfound"); throw pce; }

}
return pcf;
}
/** lines ignored **/
}

However, the message "jaccfactory.notfound" is not defined in LogStrings.properties
(https://svn.java.net/svn/glassfish~svn/branches/4.0/nucleus/security/core/src/main/resources/com/sun/logging/enterprise/system/core/security/LogStrings.properties) for WebSecurityManager .

I think the message "jaccfactory.notfound" should be defined in LogStrings.properties for WebSecurityManager.

Below is a sample from EJBSecurityManager which has situation.
The message "jaccfactory.notfound" is defined in LogStrings.properties (https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/ejb/ejb-container/src/main/resources/com/sun/logging/enterprise/system/container/ejb/LogStrings.properties)
for EJBSecurityManager (https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/security/application/EJBSecurityManager.java).



 Comments   
Comment by xianwu [ 10/Jul/13 ]

Sorry, there is a typo

"Below is a sample from EJBSecurityManager which has situation." =>
"Below is a sample from EJBSecurityManager which has a similar situation."

Comment by xianwu [ 23/Jul/13 ]

Hi Jeff

The problem is not fixed in 4.0.1 (b02-07_22_2013 build).

To reproduce the problem, you need to start GF Server Admin Console. Below are modified steps.

Reproducible operational steps:

asadmin start-domain

asadmin set server.security-service.jacc=h.b.aaaa

asadmin stop-domain

asadmin start-domain

You can see the message below in the server.log

[2013-07-23T13:44:01.478+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core.security] [tid: _ThreadID=114 _ThreadName=Thread-18] [timeMillis: 1374551041478] [levelValue: 1000] [[
jaccfactory.notfound]]

[2013-07-23T13:44:01.478+1000] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=114 _ThreadName=Thread-18] [timeMillis: 1374551041478] [levelValue: 1000] [[
Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: Error in generating security policy for __admingui – javax.security.jacc.PolicyContextException: java.lang.ClassNotFoundException: JACC:Error PolicyConfigurationFactory : cannot find class : null
at com.sun.enterprise.security.web.integration.WebSecurityManagerFactory.createManager(WebSecurityManagerFactory.java:305)
at com.sun.enterprise.security.ee.SecurityDeployer.loadPolicy(SecurityDeployer.java:234)
at com.sun.enterprise.security.ee.SecurityDeployer.access$000(SecurityDeployer.java:87)
at com.sun.enterprise.security.ee.SecurityDeployer$AppDeployEventListener.event(SecurityDeployer.java:135)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:233)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
]]

start GF Server Admin Console (http://localhost:4848/common/index.jsf)

Can you please reopen it to further investigate?

Regards, Xianwu

Comment by xianwu [ 23/Jul/13 ]

Hi Jeff

Sorry, I inserted server.log in a wrong block.

Here is the correction.

Reproducible operational steps:

asadmin start-domain

asadmin set server.security-service.jacc=h.b.aaaa

asadmin stop-domain

asadmin start-domain

start GF Server Admin Console (http://localhost:4848/common/index.jsf)

You can see the message below in the server.log

[2013-07-23T13:44:01.478+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core.security] [tid: _ThreadID=114 _ThreadName=Thread-18] [timeMillis: 1374551041478] [levelValue: 1000] [[
jaccfactory.notfound]]

[2013-07-23T13:44:01.478+1000] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=114 _ThreadName=Thread-18] [timeMillis: 1374551041478] [levelValue: 1000] [[
Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: Error in generating security policy for __admingui – javax.security.jacc.PolicyContextException: java.lang.ClassNotFoundException: JACC:Error PolicyConfigurationFactory : cannot find class : null
at com.sun.enterprise.security.web.integration.WebSecurityManagerFactory.createManager(WebSecurityManagerFactory.java:305)
at com.sun.enterprise.security.ee.SecurityDeployer.loadPolicy(SecurityDeployer.java:234)
at com.sun.enterprise.security.ee.SecurityDeployer.access$000(SecurityDeployer.java:87)
at com.sun.enterprise.security.ee.SecurityDeployer$AppDeployEventListener.event(SecurityDeployer.java:135)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:233)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
]]

Can you please reopen it to further investigate?

Regards, Xianwu





[GLASSFISH-20626] ssl-inactivity-timeout Created: 12/Jun/13  Updated: 07/Apr/14

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b87_RC3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tak09 Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

asadmin set command does not work for ssl-inactivity-timeout. When this asadmin set ssl-inactivity-timeout is entered, error message is displayed.

C:\glassfish\glassfish-4.0-b87-04_25_2013\glassfish4\bin>asadmin set server-config.network-config.pr
otocols.protocol.http-listener-2.ssl.ssl-inactivity-timeout=5
remote failure: Could not change the attributes: java.lang.IllegalArgumentException: HV000039: Inval
id property path. There is no property sslInactivityTimeout in entity org.glassfish.grizzly.config.d
om.Ssl.
java.lang.IllegalArgumentException: HV000039: Invalid property path. There is no property sslInactiv
ityTimeout in entity org.glassfish.grizzly.config.dom.Ssl.
Command set failed.





[GLASSFISH-19206] Improved Credential and SSL Configuration Created: 22/Oct/12  Updated: 14/Nov/12

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

Type: New Feature Priority: Major
Reporter: JeffTancill Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 5 weeks
Time Spent: Not Specified
Original Estimate: 5 weeks


 Description   

SSL, trust stores, keystores and credential repositories are generally difficult areas to configure for Java EE environments. The configuration and management interfaces are vendor specific and non-standard.

In order to make application archives portable , we need to unify and simplify the approach to this configuration and provisioning. Standardizing the ability to provision keystores and metadata (as necessary) by bundling them with an application at deployment time will provide portability of this configuration.



 Comments   
Comment by JeffTancill [ 14/Nov/12 ]

Deferred for consideration in EE 8





[GLASSFISH-19203] Password Aliasing Created: 22/Oct/12  Updated: 19/Mar/13

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

Type: New Feature Priority: Major
Reporter: JeffTancill Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 6 weeks
Time Spent: Not Specified
Original Estimate: 6 weeks

Tags: ee7platspec

 Description   

Best practices and common enterprise security policies dictate that we not store any passwords in clear text on the filesystem. There are a number of places where passwords are required in configuration, annotations and possibly even application code.
Password aliasing or indirection is a mechanism for storing and referencing a moniker or token instead of an actual clear text password. Resolving the token into an actual password for use at runtime is protected and only available to trusted code.
In order to support this in a portable way, Java EE 7 is standardizing a number of aspects of the solution. At the same time, the standard will not dictate the runtime implementation details for this support.

See http://java.net/downloads/javaee-spec/password-aliasing-ee7-proposal.pdf






[GLASSFISH-19202] JAX-RS and Servlet Constraint Overlap (Support for Multiple Auth Mechanisms) Created: 22/Oct/12  Updated: 19/Mar/13

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

Type: New Feature Priority: Major
Reporter: JeffTancill Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 weeks
Time Spent: Not Specified
Original Estimate: 3 weeks


 Description   

Currently, due to the JAX-RS reliance on the servlet container's authentication mechanism, it is possible to define a security constraint with an URL pattern that encompasses a JAX-RS endpoint as well as other servlets within the application.

When the configured authentication method within web.xml is FORM or any other method that ultimately assumes that there is a user and browser to interact with, the JAX-RS client is presented with a challenge for credentials that it is unable to deal with - such as form based login. Additionally, the URL pattern matching model does not include enough fidelity to differentiate between the underlying JAX-RS resources. JAX-RS was an unique requirement to want provide varying authentication mechanisms for the same URL based upon the nature of the client. Therefore, the URL pattern based constraints are not well suited for indicating resource level constraints.






[GLASSFISH-19437] Open-source Az* implementations are incomplete - cannot get resource/action name Created: 13/Dec/12  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The open-source implementations of the AzResource and AzAction interfaces simply extend AttributesImpl and thus provide no way to obtain the resource name or action name from the respective classes.

In fact, the interfaces themselves lack such methods.






[GLASSFISH-1861] Make default RMI registry secure Created: 01/Jan/07  Updated: 25/Apr/14

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

Type: Improvement Priority: Major
Reporter: km Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,861

 Description   

The RMI Registry that application server starts is insecure. Any program running
on the given machine can always take disadvantage of this insecure nature and might
bring down the GlassFish server.

Take cues from
http://weblogs.java.net/blog/emcmanus/archive/2006/12/securing_the_rm.html

I am filing this as a P2. Assign/redirect appropriately.



 Comments   
Comment by ne110415 [ 27/Feb/07 ]

The link is a very good read of interesting and informative suggestions.

From our perspective, however, I do not think the risk/return for incorporating
the various suggestions would be justified. For one, the blog itself
discourages some of the suggestions from being implemented outside JDK and
other ways might mandate us to monitor interface changes in the JDK - we do use
custom server socket factories. Though changing priority to P5, retaining the
bug in case we do get more ideas to fix this issue.

Comment by Tom Mueller [ 23/Jun/10 ]

Nandini no longer on project.

Comment by Tom Mueller [ 24/Jan/11 ]

The RMI registry runs as part of the JMX service on port 8686.

Consider this small program that plays with the registry:

import java.rmi.*;

public class Rmi {
public static void main(String args[]) throws Exception {
String []n = Naming.list(args[0]);
for (String s : n)

{ System.out.println(s); Remote r = Naming.lookup(s); System.out.println(" " + r.getClass().getName()); System.out.println("trying unbind"); Naming.unbind(s); }

}
}

When run with "//localhost:8686/" as an argument while a GlassFish domain is running on the same system, the program produces the following output:

$ java Rmi //localhost:8686/
//localhost:8686/jmxrmi
javax.management.remote.rmi.RMIServerImpl_Stub
trying unbind

If the program is run again, it produces no output because the "jmxrmi" name has been unbound.

Even if the admin password is set to something, it is still possible to run this program with no password and unbind the "jmxrmi" name. Or, the name could be bound to some other object which could then be used to hijack passwords, etc. I'm not aware of anyway to bring down the GlassFish server directly by using this hole.

Increasing the priority of this issue. Assigning this to the security team to evaluate the importance of fixing this issue for 3.2.





[GLASSFISH-21447] java:app & java:module namespaces temporarily disappear when SAM invoked Created: 22/Oct/15  Updated: 23/Dec/15

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

Type: Bug Priority: Major
Reporter: arjan tijms Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ejb, jaspic, jndi, namespace

 Description   

When trying to obtain something from the JNDI namespace java:app or java:module during invocation of a SAM's validateRequest method an exception is thrown.

However, right before the SAM is invoked, namely in a ServletRequestListener as well as right after the SAM is invoked, namely in a Filter or Servlet this operation succeeds.

The exception thrown is the following:

javax.naming.NamingException: Lookup failed for 'java:module/EJBBean' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Invocation exception: Got null ComponentInvocation ]
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at test.TestServerAuthModule.validateRequest(TestServerAuthModule.java:40)
	at javax.security.authenticationmechanism.DefaultServerAuthContext.validateRequest(DefaultServerAuthContext.java:36)
	at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1654)
	at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1521)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:606)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:702)
	at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:678)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.naming.NamingException: Invocation exception: Got null ComponentInvocation 
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.getComponentId(GlassfishNamingManagerImpl.java:842)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:714)
	at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:167)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)

The lookup code is as follows:

try {
	// java:global/glassfish-sam-ee-namespaces/EJBBean does work
	EJBBean ejbBean = (EJBBean) new InitialContext().lookup("java:module/EJBBean");
	System.out.println("SAM: " + ejbBean.hello());
} catch (NamingException e) {
	System.out.println("SAM: Exception");
	e.printStackTrace();
}

A full reproducer is provided as Maven project at: https://github.com/arjantijms/glassfish-sam-ee-namespaces

Building and deploying this project to a stock GlassFish, then requesting http://localhost:8080/glassfish-sam-ee-namespaces/servlet prints the following in the log:

RequestListener: Hello from EJB
SAM: Exception
javax.naming.NamingException: Lookup failed for 'java:module/EJBBean' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} (rest of exception as above)
Servlet: Hello from EJB

Expected is:

RequestListener: Hello from EJB
SAM: Hello from EJB
Servlet: Hello from EJB

Deploying the same application to JBoss WildFly 9.0.1 or 10.0rc3 (with a modified standalone.xml to activate jaspic) indeed prints the above.



 Comments   
Comment by monzillo [ 23/Oct/15 ]

Glassfish should be modiefied such that such JNDI lookups may be made from within the SAM.
Also The JASPIC spec is silent on this, and should be amended to ensure that such lookups are required to supported.

Comment by arjan tijms [ 02/Nov/15 ]

After some research in the code it appears GlassFish sets and unsets the required context every time a web listener or component is called via a call to an InvocationManager. E.g. setting up the context:

private void preInvoke(WebModule ctx) {
    WebModule wm = (WebModule)ctx;
    ComponentInvocation inv = new WebComponentInvocation(wm);
    invocationMgr.preInvoke(inv);
}

And unsetting it:

private void postInvoke(WebModule ctx) {
    WebModule wm = (WebModule)ctx;
    ComponentInvocation inv = new WebComponentInvocation(wm);
    invocationMgr.postInvoke(inv);
}

Calls like these should be done prior to a SAM being called. The exact calls can't be done directly, because there would be a circulair dependency between web-glue.jar (where WebComponentInvocation lives) and websecurity.jar (where the RealmAdapter that calls the SAM lives).

However, firing an event for one of the existing listeners seems to work, as this will effectively invoke code such as shown above.

E.g. in com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate, add a try/catch with the context.fireContainerEvent calls as shown below for validateRequest

   if (serverAuthConfig != null) {
            //JSR 196 is enabled for this application
        	try {
        		context.fireContainerEvent(BEFORE_CONTEXT_ATTRIBUTE_ADDED, null);
        		result = validate(request, response, config, authenticator, calledFromAuthenticate);
        	} finally {
        		context.fireContainerEvent(AFTER_CONTEXT_ATTRIBUTE_ADDED, null);
        	}
        } 

And for secureResponse in com.sun.web.security.RealmAdapter.invokePostAuthenticateDelegate:

 if (messageInfo != null) {
                    //JSR 196 is enabled for this application
                    sAC = (ServerAuthContext) messageInfo.getMap().get(SERVER_AUTH_CONTEXT);
                    if (sAC != null) {
                    	try {
                    		context.fireContainerEvent(BEFORE_CONTEXT_ATTRIBUTE_ADDED, null);
                    		AuthStatus authStatus =  sAC.secureResponse(messageInfo, null); // null serviceSubject
                    		result = AuthStatus.SUCCESS.equals(authStatus);
                    	} finally {
                    		context.fireContainerEvent(AFTER_CONTEXT_ATTRIBUTE_ADDED, null);
                    	}
                    }
                }

Simular code should be added to com.sun.web.security.RealmAdapter.logout to support cleanSubject, but this requires a few more changes since context is not directly available in that method. Furthermore, for validateRequest firing the events should probably be moved into the validate() method, which should have context as extra parameter.

Finally, there should probably a new event be added and used instead of "AFTER_CONTEXT_ATTRIBUTE_ADDED".

I tested a GlassFish 4.1.1 build patched with the above changes at it fixes the problem. I also executed all JASPIC tests from the Java EE 7 samples project and no new failures occurred.

As for the reproducer linked from the issue descriptor, it now logs this on the patched GlassFish:

RequestListener initialized: Hello from EJB
SAM: Hello from EJB
Servlet: Hello from EJB
SAM SR: Hello from EJB
RequestListener destroyed: Hello from EJB
Comment by arjan tijms [ 23/Dec/15 ]

Note that Payara fixed this downstream. See https://github.com/payara/Payara/pull/581





[GLASSFISH-21520] file user commands fail if server instance is running. Created: 02/Mar/16  Updated: 02/Mar/16

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 4.1, 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: yama0428 Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

asadmin create-file-user command always fails if server instance is running.

D:\glassfish4\glassfish\bin>asadmin start-cluster cluster
Command start-cluster executed successfully.

D:\glassfish4\glassfish\bin>asadmin start-cluster cluster2
Command start-cluster executed successfully.

D:\glassfish4\glassfish\bin>asadmin create-file-user --target cluster2 myuser1
Enter the user password>
Enter the user password again>
remote failure: An error occurred during replication
Failure: Command create-file-user failed on server instance instance: remote failure: Configuration for target cluster2 not found.
Command create-file-user failed.

D:\glassfish4\glassfish\bin>asadmin create-file-user --target server myuser2
Enter the user password>
Enter the user password again>
remote failure: An error occurred during replication
Failure: Command create-file-user failed on server instance instance: remote failure: Configuration for target server not found.
Failure: Command create-file-user failed on server instance cluster2_1: remote failure: Configuration for target server not found.
Command create-file-user failed.

The same problem exists in update-file-user, delete-file-user command.

D:\glassfish4\glassfish\bin>asadmin update-file-user --target server --groups group1 myuser2
remote failure: An error occurred during replication
Failure: Command update-file-user failed on server instance instance: remote failure: Configuration for target server not found.
Failure: Command update-file-user failed on server instance cluster2_1: remote failure: Configuration for target server not found.
Command update-file-user failed.
D:\glassfish4\glassfish\bin>asadmin delete-file-user --target server  myuser2
remote failure: An error occurred during replication
Failure: Command delete-file-user failed on server instance instance: remote failure: Configuration for target server not found.
Failure: Command delete-file-user failed on server instance cluster2_1: remote failure: Configuration for target server not found.
Command delete-file-user failed.





[GLASSFISH-19349] Choosing SSL cipher suites in GlassFish admin GUI results in many "Unrecognized cipher" warnings in GlassFish log Created: 15/Nov/12  Updated: 24/Apr/14

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

Type: Bug Priority: Major
Reporter: rdelaplante Assignee: JeffTancill
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using the web admin GUI I went into the configuration of http-listener-2 which has SSL enabled. I went to the SSL tab and clicked the "select all" button for all cipher suites EXCEPT the 40 bit and 56 bit ciphers, and then pressed save. My goal is to disable the 40 bit and 56 bit ciphers. I noticed the following in my GlassFish log. Note that I already have the unlimited strength JCE installed in my JDK:

INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 1ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_RC4_128_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_AES_128_CBC_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].

Why did it offer cipher suites that are unrecognized in the first place? Which ones were actually used?






[GLASSFISH-10380] login failures must be logged at INFO level Created: 17/Oct/09  Updated: 09/Apr/12

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

Type: Improvement Priority: Minor
Reporter: sankarpn Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 10,380

 Description   

for admin login failures there are no messages logged at INFO level. This is a
useful information for administrators. It may not clutter the server.log since
there may not be many login attempts for admin account.



 Comments   
Comment by sankarpn [ 18/Oct/09 ]

After filing this issue I thought about the situation, where asadmin prompting
for user/password after trying the default login if the domain is protected. If
it is protected, every time asadmin is entered without a user/password it will
try the default login and if it fails it will prompt for the auth info.

So every time asadmin is executed without user/password in first place all of
those will be logged in server.log as login failures messages which may not be
desirable to see. Hence reducing its priority to P4 and making it as RFE.





[GLASSFISH-12581] GF v2.1.1: Unable to connect to LDAPS directory server instance in OpenSSO Created: 08/Jul/10  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v2.1.1
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: cmwesley Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,581
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude

 Description   

In Sun Glassfish Enterprise Server 2.1.1 Enterprise Edition or Oracle Glassfish
Enterprise Server 2.1.2 Enterprise Edition, a user can not configure OpenSSO 8.0
update 2 to use an LDAPS enabled directory server instance. The same
configuration works just fine in Sun Glassfish Enterprise Server 2.1 but fails
in v2.1.1 and v2.1.2.

Steps to Reproduce can be made available on request by sending an email to the
submitter (cmwesley). The procedure contains credentials for hosts on the lab
network.



 Comments   
Comment by cmwesley [ 08/Jul/10 ]

Here is the error that appears in the server.log with the JVM option
"-Djavax.net.debug=ssl:handshake:verbose".

[#|2010-07-07T13:24:17.565-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
%% Created: [Session-7, TLS_ECDHE_RSA_WITH_RC4_128_SHA]|#]

[#|2010-07-07T13:24:17.565-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|

    • TLS_ECDHE_RSA_WITH_RC4_128_SHA|#]

[#|2010-07-07T13:24:17.565-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|

      • Certificate chain|#]

[#|2010-07-07T13:24:17.566-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
chain [0] = [
[
Version: V3
Subject: CN=qa-m4000-sol1-02.red.iplanet.com, O=sun.com, OU=identity,
L=santaclara, ST=CA, C=US
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

Key: SunPKCS11-__SUN_SJSAS_internal RSA public key, 1024 bits (id 164, session
object)
modulus:
143508468974260818174812041739440781929174299049130742818631511275379083164218201442004385797787487753497152294299630341089733868626540681105061382667279879479702945134352301742833356977150016922886738076617003199821552766624994873499861742828459438345069399341108624378349064013443678704662955792900502878031
public exponent: 65537
Validity: [From: Fri Jun 25 13:19:41 PDT 2010,
To: Fri Mar 21 13:19:41 PDT 2014]
Issuer: CN=Certificate Manager, OU=Identity, O=Sun, L=Santa Clara,
ST=California, C=US
SerialNumber: [ 024b]

Certificate Extensions: 3
[1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL server
]

[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 19 5F 44 67 E7 98 F8 73 CF 9C 39 8D EF CA A3 A7 ._Dg...s..9.....
0010: 5F 9A 09 43 _..C
]

]

[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
Data_Encipherment
]

]
Algorithm: [MD5withRSA]
Signature:
0000: 75 3C 8B 5D ED 85 A0 8B 11 09 B5 1C C9 9E 97 94 u<.]............
0010: FD 2C 4C 4B DA DA B1 F9 E5 7E 1A 16 CE 4D 63 96 .,LK.........Mc.
0020: 6B 48 CE 3A 3F CC 76 89 6C 9D CA 15 A3 C3 16 3D kH.:?.v.l......=
0030: CF 14 11 B4 8E A8 F0 FA 83 4F AB B3 54 4B 8A D0 .........O..TK..

]|#]

[#|2010-07-07T13:24:17.567-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
chain [1] = [
[
Version: V3
Subject: CN=Certificate Manager, OU=Identity, O=Sun, L=Santa Clara,
ST=California, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: SunPKCS11-__SUN_SJSAS_internal RSA public key, 512 bits (id 13, session
object)
modulus:
10162914521239337124817424634574674436827552258603980346722071889531003856304570700106790950587367333995653623899444895250154926863273450784243021510717421
public exponent: 65537
Validity: [From: Wed Apr 04 00:00:00 PDT 2007,
To: Thu Apr 04 01:00:00 PDT 2019]
Issuer: CN=Certificate Manager, OU=Identity, O=Sun, L=Santa Clara,
ST=California, C=US
SerialNumber: [ 01]

Certificate Extensions: 5
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 19 5F 44 67 E7 98 F8 73 CF 9C 39 8D EF CA A3 A7 ._Dg...s..9.....
0010: 5F 9A 09 43 _..C
]
]

[2]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL CA
S/MIME CA
Object Signing CA]

[3]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 19 5F 44 67 E7 98 F8 73 CF 9C 39 8D EF CA A3 A7 ._Dg...s..9.....
0010: 5F 9A 09 43 _..C
]

]

[4]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]

[5]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 2A 9F 72 DF CF C5 8A 89 06 32 06 EF A4 5C 79 16 *.r......2...\y.
0010: 12 E4 1E FE F9 85 B9 02 91 96 35 80 16 F6 47 25 ..........5...G%
0020: 3F 8D 88 E5 34 80 BB 8F ED 2D C8 FB 4C A3 23 DF ?...4....-..L.#.
0030: 0E 68 82 E9 83 FA 62 D8 D1 3F 41 90 65 3B 4C D0 .h....b..?A.e;L.

]|#]

[#|2010-07-07T13:24:17.567-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
***|#]

[#|2010-07-07T13:24:17.567-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
Found trusted certificate:|#]

[#|2010-07-07T13:24:17.568-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
[
[
Version: V3
Subject: CN=Certificate Manager, OU=Identity, O=Sun, L=Santa Clara,
ST=California, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: SunPKCS11-__SUN_SJSAS_internal RSA public key, 512 bits (id 13, session
object)
modulus:
10162914521239337124817424634574674436827552258603980346722071889531003856304570700106790950587367333995653623899444895250154926863273450784243021510717421
public exponent: 65537
Validity: [From: Wed Apr 04 00:00:00 PDT 2007,
To: Thu Apr 04 01:00:00 PDT 2019]
Issuer: CN=Certificate Manager, OU=Identity, O=Sun, L=Santa Clara,
ST=California, C=US
SerialNumber: [ 01]

Certificate Extensions: 5
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 19 5F 44 67 E7 98 F8 73 CF 9C 39 8D EF CA A3 A7 ._Dg...s..9.....
0010: 5F 9A 09 43 _..C
]
]

[2]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL CA
S/MIME CA
Object Signing CA]

[3]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 19 5F 44 67 E7 98 F8 73 CF 9C 39 8D EF CA A3 A7 ._Dg...s..9.....
0010: 5F 9A 09 43 _..C
]

]

[4]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]

[5]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 2A 9F 72 DF CF C5 8A 89 06 32 06 EF A4 5C 79 16 *.r......2...\y.
0010: 12 E4 1E FE F9 85 B9 02 91 96 35 80 16 F6 47 25 ..........5...G%
0020: 3F 8D 88 E5 34 80 BB 8F ED 2D C8 FB 4C A3 23 DF ?...4....-..L.#.
0030: 0E 68 82 E9 83 FA 62 D8 D1 3F 41 90 65 3B 4C D0 .h....b..?A.e;L.

]|#]

[#|2010-07-07T13:24:17.569-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|

      • ECDH ServerKeyExchange|#]

[#|2010-07-07T13:24:17.569-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
Server key: SunPKCS11-__SUN_SJSAS_internal EC public key, 192 bits (id 170,
session object)
public x coord: 2139813156550960910329964508009219320493669599206146807517
public y coord: 5618476019888108170324771309466457220116996115766507866712
parameters: secp192r1 [NIST P-192, X9.62 prime192v1] (1.2.840.10045.3.1.1)|#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|

      • CertificateRequest|#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
Cert Types: |#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|RSA|#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|,

#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|DSS|#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|,

#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|ECDSA|#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
Cert Authorities:|#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
<CN=Certificate Manager, OU=Identity, O=Sun, L=Santa Clara, ST=California, C=US>|#]

[#|2010-07-07T13:24:17.575-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
<CN=qa-m4000-sol1-02.red.iplanet.com, CN=15636, CN=Directory Server, O=Sun
Microsystems>|#]

[#|2010-07-07T13:24:17.576-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|

      • ServerHelloDone|#]

[#|2010-07-07T13:24:17.576-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|

      • Certificate chain|#]

[#|2010-07-07T13:24:17.576-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
***|#]

[#|2010-07-07T13:24:17.576-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
ConnSetupMgr, handling exception: java.lang.RuntimeException: Could not parse
key values|#]

[#|2010-07-07T13:24:17.576-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|
ConnSetupMgr|#]

[#|2010-07-07T13:24:17.576-0700|INFO|glassfish2.1|javax.enterprise.system.stream.out|_ThreadID=32;_ThreadName=ConnSetupMgr;|,
SEND TLSv1 ALERT: |#]

Comment by kumarjayanti [ 21/Jul/10 ]

status whiteboard value set correctly

Comment by kumarjayanti [ 04/Oct/10 ]

added keyword

Comment by kumarjayanti [ 13/Apr/11 ]

not applicable for v3.2





[GLASSFISH-7319] Audit Appserver management operations (Start/Stop) feature doesn't in V3 Created: 12/Mar/09  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: sonialiu Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,319

 Description   

OS: solaris10
build: promoted build40
After user enabled the default audit mechanism, the Appserver (V2/V2.1) allowed
user to check audit information in the server.log while
start-domain/stop-domain. The feature works fine for V2/V2.1 but seems V3
doesn't support it. Here are steps to reproduce the bug:
1. Enable audit/default audit module:
asadmin set server-config.security-service.audit-enabled=true
asadmin set
server-config.security-service.audit-module.default.property.auditOn=true
Check domain.xml and see the following values are set.
<audit-module classname="com.sun.enterprise.security.Audit" name="default">
<property name="auditOn" value="true"/>
</audit-module>
...
<security-service audit-enabled="true" audit-modules="default">
...
2. stop domain (asadmin stop-domain domain1)
3. start domain (asadmin start-domain domain1). Check server.log, we should see
the following message displayed like in V2.1:
"Audit: Application server startup complete"
But i did not see it for v3.
4. Stop domain. check the server.log, we should see the following message:
"Audit: Application server shutdown complete" like in V2.1
But it did not display for V3.
The "Audit Appserver management operations (Start/Stop)" feature is missing in
the V3.



 Comments   
Comment by kumarjayanti [ 14/Sep/09 ]

For V3, there is an issue, in order to reduce the server startup time we are
delaying the startup of Security Services until the first application is deployed.

We tried to separate out the audit-module related code and try to initialize it
during the sever startup, but that was not possible since it was creating a
split package for the exposed public SPI Class AuditModule

So we have fixed the code such that the "Server Started audit log" will appear
1. Immediately on server start if there are some deployed applications in the
server.
2. If the server did not have any deployed apps then the "server started audit
log" will appear once the first app is deployed on the server. So there will be
a delay or it may never occur if no apps are ever deployed on it before it is
shutdown again.

We need to fix this behaviour but we do not want to trade it for the cost of
increasing server startup-time while at the same time maintaining
backward-compatibility. I am marking it as a P4.

As for "Server Shutdown Audit Log" there is bug in V3 code elsewhere and the
code in security module is fine. So we have filed a bug for it, please track
that bug : https://glassfish.dev.java.net/issues/show_bug.cgi?id=9500

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-9289] SecurityContext return PrincipalImpl for custom login and realm Created: 27/Aug/09  Updated: 25/Apr/14

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

Type: New Feature Priority: Minor
Reporter: maisonneuve_michel Assignee: