[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-4118] Adds digest authentication support for Realms. Created: 07/Feb/08  Updated: 06/Mar/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: venu
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,118
Status Whiteboard:

v3-prd-item


 Description   

Support HTTP digest authentication, authorization, and P-asserted identity for
Sailfin/JSR289



 Comments   
Comment by kumarjayanti [ 07/Feb/08 ]

Marking P2 since it's a P1 PRD Item

Comment by kumarjayanti [ 03/Apr/08 ]

The last part of Description "and P-asserted identity for Sailfin/JSR289" is
not applicable to V3 unless SailFin Features become part of V3.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is 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-4214] gfv3:Component Identity Propagation Created: 17/Feb/08  Updated: 06/Mar/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: venu
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,214
Status Whiteboard:

v3-prd-item


 Description   

Use of programmaticLogin(or new api) to establish passwordcredential by embedded
clients (including web service clients) propagation of caller/component identity
on web service invocation from SJSAS 9.0 PRD also required for embedded token
aquisition.



 Comments   
Comment by kumarjayanti [ 17/Feb/08 ]

Use of programmaticLogin(or new api) to establish passwordcredential by embedded
clients (including web service clients) propagation of caller/component identity
on web service invocation from SJSAS 9.0 PRD, also required for embedded token
aquisition.

Comment by kumarjayanti [ 17/Feb/08 ]

changing IssueType to FEATURE

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is 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-4212] gfv3: Limit Failed Login attempts for Realms Created: 17/Feb/08  Updated: 06/Mar/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: venu
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,212
Status Whiteboard:

v3-prd-item


 Description   

disallow authentication of a user from an addess for a configured freeze-out
time when the number of consecutive failed attempts from the same source address
for a given user exceeds a configured threshold. Modify the admin console to
support the configuration of this feature [must consider DOS ramifications] see
recent 1-pager, and also include support for password constraints via creation
of user-mgmt interface. Carry-over from 9.0 PRD



 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 change to set fix version to "not determined" where the issue is open but the value is 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-3731] LDAPRealm: Selection of group through the DN Created: 05/Oct/07  Updated: 06/Mar/12

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

Type: Improvement Priority: Critical
Reporter: granat Assignee: raharsha
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: 3,731

 Description   

Hi,

In our central LDAP server, a lot of applications are grouped like this:

  • applications
  • app1
  • role1
  • role2
  • app2
  • role1
  • role2

We do not define the roles as being unique in the whole tree to make it easier
for the LDAP administrators to handle them. The Users are mapped to the
application roles either directly or through an organisation group (analog
application, but for organisational purposes).

The problem I have is that GlassFish V2 doesn't allow the field definition of
the group to be the DN (which is the only thing different between app1/role1 and
app2/role1) and I can only input the cn (which in this case would be wrong,
giving users permissions they should not have). I think the problem is because
DN is not something you can get as a field from the ldap protocol but is a
special method call.

greets
jeremie



 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-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-8544] princpals always wrapped in "WebPrincipal" Created: 17/Jun/09  Updated: 09/Jul/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: svnfightsvn Assignee: monzillo
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 8,544

 Description   

I have a custom realm and login module in which I add a custom principal to the
person's subject. The custom principal class extends
com.sun.enterprise.deployment.PrincipalImpl and adds some other member variables
to the principal. The idea is that I want to retrieve this principal from the
HttpServletRequest after authentication and cast it to my appropriate subclass.
Since the name of the principal is the same as what gets entered in a login
form and since the class extends PrincipalImpl class, it is the default
principal that gets used upon login.
However, it seems that I ALWAYS end up with a "com.web.security.WebPrincipal"
implementation when I call httpServletRequest.getUserPrincipal(); It seems that
Glassfish is wrapping any authenticated principal in this WebPrincipal class
with no way to retrieve the custom principal.
I have found code in com.web.security.WebProgrammaticLogin and
com.sun.web.security.RealmAdapter class (possibly others) that creates this
WebPrincipal after the login in performed.

A quick snippet of code:
--------------------------
LoginContextDriver.login(user, password, realm);
SecurityContext secCtx = SecurityContext.getCurrent();
WebPrincipal principal = new WebPrincipal(user, password, secCtx);
httpServletRequest.setUserPrincipal(principal);
--------------------------

I don't know, but is WebPrincipal necessary? If the authentication succeeds,
the SecurityContext will already have a principal in it (my custom ones, the
"initiator"). Instead of creating a new "WebPrincipal" object, can't we just
stick the principal from the SecurityContext into the request?



 Comments   
Comment by jluehe [ 18/Jun/09 ]

-> security

Comment by monzillo [ 19/Jun/09 ]

The WebPrincipal contains what amounts to a Subject, so that "other" principals
(e.g. group principals) and credentials resulting from the authentication, can
be remembered in the authentication session, and recovered (without repeating
the authentication process) when a subsequent request is made on the session.
The implementation is historical, and the focus was on defining a representation
for use by the container. I think it's utility (to non-containr code) could be
improved, wrt to custom principals.

that said, all EE containers are required to support an api that can be used to
obtain a subject containing all the principals, corresponding to the request,
including your custom principal.

Subject s = (Subject)
javax.security.jacc.PolicyContext.getContext("javax.security.auth.Subject.container");

this policycontext handler may be called from your application code, at which
time it will return a subject containing the principals corresponding to the
run-as identity of the component from which it was called. This handler was
provided for use by the container policy subsystem, and when called from the
policy system and prior to dispatch into the component, it returns a subject
containing the principals of the caller. when the component is configured to
run-as its caller, the distinction is moot.

You can see more details in the jacc spec (I believe null is returned when
authentication has not occurred).

let us know if the PolicyContext api satisfies your immediate need.

I also think we should add a getCustomPrincipal method to WebPrincipal.

Comment by kumara [ 01/Sep/09 ]

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

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.

Comment by cpiggott [ 09/Jul/12 ]

I have this exact same issue. I need to attach extra information to a Principal, so I made a custom AppservPasswordLoginModule that overwrites commit() and attaches my own CustomPrincipal to the Subject. When it gets to my (JAX-RS) webapp it's a WebPrincipal with no way to get to the customPrincipal inside.





[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-15453] The code in CLI commands in security should be restructured a bit Created: 06/Jan/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: kumarjayanti Assignee: Nithya Ramakrishnan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

The code in some of the Security Related CLI commands which we inherited from Admin teams for the V3.1 release can be rewritten using some of the newer API's available in Backend.






[GLASSFISH-15429] Modifying keyfile path in a newly created config does not properly list the users Created: 04/Jan/11  Updated: 16/Nov/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-15406 Unable to edit custom admin-realm in ... Closed
Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

1. asadmin copy-config default-config new-config
2. asadmin get new-config.security-service.auth-realm.admin-realm.property.file
new-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
3. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.
4. file /tmp/v3/admin-keyfile is not currently created.
5. asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
6. cat /tmp/v3/admin-keyfile
test;

{SSHA256}mjyhJFWxU8xUnGMY5bt+ngwj3tf6v6yOTKB7DgGKJUu6Neky/GVOsQ==;asadmin
user1;{SSHA256}

rImtlHJuqi6AMSypIUyBdcs2CUEPQq3pIEHSEsndYQmhBl4ZBT+fJA==;user1
<user test is properly added to admin-keyfile under /tmp/v3 as expected.>
8. asadmin list-file-users --authrealmname admin-realm new-config
user1
Command list-file-users executed successfully.
<Expected is test,user1 but it lists user1 which it takes from $

{instance_root}

/domains/domain1/config/keyfile but it should list from /tmp/v3/admin-keyfile>

The list-file-users needs to be fixed to list from /tmp/v3/admin-keyfile



 Comments   
Comment by kumarjayanti [ 04/Jan/11 ]

Srini,

Either there is no bug or you have not given me the complete set of steps. With the steps that you provided it is not clear how the user :"user1" is already present in the /tmp/v3/admin-keyfile.

Also are you using the latest builds. Here are the steps that i executed and i see no problems

1.)

$ ./asadmin start-domain
Waiting for domain1 to start ..........
Successfully started the domain : domain1
domain Location: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1
Log File: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

2.)
$ ./asadmin copy-config default-config new-config

Command copy-config executed successfully.

3)
$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.

4)
$ mkdir /tmp/v3
$ > /tmp/v3/admin-keyfile

5)
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

6)
$ cat /tmp/v3/admin-keyfile
test;

{SSHA256}

H0J8mMtMJp1BcPynsBqyDw8r0WWI30796BaFrsdmei3eBh3YDILKKg==;asadmin

7)
$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
Command list-file-users executed successfully.

8)
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config user1
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

9)
$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
user1
Command list-file-users executed successfully.

Comment by kumarjayanti [ 04/Jan/11 ]

Cannot reproduce. Make sure you are using the very latest glassfish build. And please provide the exact steps to reproduce.

I will try some other combination in the meantime to see if i can reproduce anything like what u mention.

Comment by srinik76 [ 04/Jan/11 ]

I have not created the file. As per the requirement do we need to create the file.

If not created we see this problem.

Comment by kumarjayanti [ 04/Jan/11 ]

The Keyfile needs to be created physically and ideally this should be done before even the set command is executed to change the keyfile property.

That said, if the keyfile is not created then when i test purely from CLI i do not get the problem you see. I see the create-file-user fails.

Comment by Anissa Lam [ 04/Jan/11 ]

It is the responsibility of the user to create the keyfile ( I hope the documentation specifies that) or the security code should be smart enough to detect that the keyfile doesn't exist and create that for the user.
GUI should NOT create the keyfile.

As commented in GLASSFISH-15406, there is error given if the keyfile doesn't exist.
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
remote failure: Adding User test to file realm admin-realm failed.
Command create-file-user failed.

GUI should show the error to the user.
However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear.

Comment by srinik76 [ 04/Jan/11 ]

Tested with the latest build, create-file-user fails with following message

asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
remote failure: Adding User test to file realm admin-realm failed. /tmp/v3/admin-keyfile (No such file or directory)
/tmp/v3/admin-keyfile (No such file or directory)

list-file-users also should report that /tmp/v3/admin-keyfile is not found, but it lists the user (admin)

asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

Comment by kumarjayanti [ 05/Jan/11 ]

Anissa Said :
----------

GUI should show the error to the user.
However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear.

--------

I checked the code and the CLI command tried to do the following :
report.setMessage(
localStrings.getLocalString("create.file.user.useraddfailed",
"Adding User

{0}

to the file realm

{1}

failed",
userName, authRealmName) + " " + localalizedErrorMsg);
report.setActionExitCode(ActionReport.ExitCode.FAILURE);
report.setFailureCause(e);

It appears when the Message is set it takes priority over setFailureCause in the admin framework. I can remove the setMessage for the next release. Or if you think it is important for you since this message has to be displayed in the GUI then please reopen the bug and i will ask for approval.

I see a similar problem with list-file-users as well where it sets all the 3 items on the report object and hence the message that was set takes priority and that message is currently not very good.

I can fix both of them as part of this. The question is would you like messages fixed for V3.1.

Comment by srinik76 [ 05/Jan/11 ]

Reopening issue after discussing with kumar.

Now from the security side it will check for the keyfile existence while listing file users.

Comment by kumarjayanti [ 05/Jan/11 ]

1) How bad is its impact? (Severity)
While we are unable to reproduce it by pure CLI operations it appears GUI seems to observe some incorrect file-user listing in this case. Also the message log for the Failure can be improved to indicate the real cause.

2) How often does it happen? (Frequency)
This will occur only when keyfile of a file-realm points to a non-existent File.

3) How much effort is required to fix it? (Cost)
Minor : the fix is to add a check for non-existent keyfile and throw an error.

4) What is the risk of fixing it? (Risk)

None (does not affect the Runtime). GUI wants these enhancements.

Comment by Anissa Lam [ 05/Jan/11 ]

Approved.

Comment by kumarjayanti [ 05/Jan/11 ]

fixed

Comment by srinik76 [ 05/Jan/11 ]

Fix works fine, but when the key file is created

list-file-users should report none, but lists admin user.

Waiting for comments from kumar to reopen the issue.

Comment by srinik76 [ 06/Jan/11 ]

After changing the key file and restarting the server, it works fine.

Comment by srinik76 [ 06/Jan/11 ]

Comments from Kumar in email

Hi Srini, Anissa,

I think i understand what is happening.

1. default-config is copied as new-config
2. Now the admin-realm is selected in the GUI from this new-config
3. Its KeyFile property is changed to some XYZ and the change is saved. Using an asadmin set-command
4. A physical XYZ file is created
5. Now again ManageUsers is clicked on the admin-realm of new-config
5.1. At this time ListFileUsers command still shows the original admin user that is part of the admin-realm in default-config

Is this a correct description of the issue ?. If that is true then yes that can happen.

1. Step 2 loads the admin-realm in the Backend.
2. Setp 3 modifies the property of the realm in the Config-Layer
3. Backend is not informed of this change. And since the new-config is not the running config of the Server (DAS) the ConfigListener Mechanism (which is in place) does not come into picture. So the backend realm is never updated.
4. ListFileUsers command which executes as part of step (5) above does a refresh of the keyfile contents but it never goes back to the config-layer to see if the keyfile has changed. And it does not make sense for ListFileUsers to do that (checking for changes to the realm definition in config-layer). Things would have worked if it did that but really the syncing between Config-Layer and Backend should have happened when step (3) above invoked the "asadmin set" command to modify the keyfile property.

There are 4 solutions :

1. I can provide a new hidden command which has to be executed by GUI whenever they do a asadmin set on any realm (and file-realm in particular). This command would then try to sync the Config change made by the set to the backend. For some realms this inplace update cannot be performed for-example

  • if it is an LDAPRealm of the active server config and there are applications currently using that realm and the set command tries to modify the URL of the LDAP server or the base-dn of the LDAPRealm. Such changes will require a RESTART of the Application Server.

2. Fix ListFileUsers to re-read the config-layer. Not a good idea and not the right fix.

3. GUI can indicate after the set-command that Appserver should be restarted.

4. GUI should not use an asadmin set to modify the keyfile location. Instead it should delete the existing Realm and create a New Realm with modified properties.

Let me know which approach would be best for V3.1.

regards,
kumar

Waiting for Anissa's comments to decide what approach (1 out of 4 suggested by kumar) to be taken for the solution.
Anissa/Kumar, Can I reopen the bug?

Comment by kumarjayanti [ 06/Jan/11 ]

I am also not sure if a Property change in realm (using asadmin set) in an active server config will cause the Config Change Event which can be received by a registered ConfigListener.

Comment by Anissa Lam [ 06/Jan/11 ]

As i understand it, only GUI user sees this problem. CLI user will not have such an issue. Correct me if i am wrong. But i just tried using CLI to do all the steps and list-file-user reports the correct list.
So, what exactly is missing in GUI code, compared to CLI, that causes this error in GUI only ? I want to understand this, and that maybe how we should fix it.

The corresponding steps in CLI works perfectly fine, and list-file-user is reporting the list of users from the new key file correctly.

~ 1) asadmin copy-config default-config TEST-config
Command copy-config executed successfully.
~ 2)
~ 2) asadmin list-file-users --authrealmname admin-realm server-config
admin
Command list-file-users executed successfully.
~ 3)
~ 3)
~ 3) asadmin get configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file
configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
Command get executed successfully.
~ 4)
~ 4) asadmin set configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile
configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile
Command set executed successfully.
~ 5)
~ 5)
~ 5) touch /tmp/keyFile
~ 6)
~ 6) asadmin list-file-users --authrealmname admin-realm TEST-config
Command list-file-users executed successfully.
~ 7)
~ 7)

Comment by Anissa Lam [ 06/Jan/11 ]

Re-open issue as this is still under active discussion and GUI depends on the fix.

Comment by kumarjayanti [ 06/Jan/11 ]

Your step two :
~ 2) asadmin list-file-users --authrealmname admin-realm server-config

should be changed to

2) asadmin list-file-users --authrealmname admin-realm TEST-config

and IMO that will reproduce the problem in CLI

Comment by kumarjayanti [ 06/Jan/11 ]

I retested after implementing solution 1. Here is the output :

$ ./asadmin start-domain
Waiting for domain1 to start ..........
Successfully started the domain : domain1
domain Location: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1
Log File: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

$ ./asadmin copy-config default-config new-config
Command copy-config executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile
Command set executed successfully.

$ ./asadmin __synchronize-realm-from-config --realmname admin-realm new-config
Synchronization of Realm admin-realm from Configuration Successful.
Command __synchronize-realm-from-config executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
Command list-file-users executed successfully.

$ cat /tmp/mykeyfile

$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
Command list-file-users executed successfully.

Comment by kumarjayanti [ 06/Jan/11 ]

The new hidden command will set RESTART required if the change was done to an active server config

$ ./asadmin set server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile
server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile
Command set executed successfully.

$ ./asadmin __synchronize-realm-from-config --realmname file server-config
Restart required for configuration updates to active server realm: file.
Command __synchronize-realm-from-config executed successfully.

And here is how the code in the command sets the information required for GUI for a restart. I picked up this code from :

core/kernel/src/main/java/com/sun/enterprise/v3/admin/GetRestartRequiredCommand.java

private void setRestartRequired(ActionReport report) {
report.setActionExitCode(ActionReport.ExitCode.SUCCESS);
ActionReport.MessagePart mp = report.getTopMessagePart();

Properties extraProperties = new Properties();
Map<String, Object> entity = new HashMap<String, Object>();
mp.setMessage(_localStrings.getLocalString("RESTART_REQUIRED",
"Restart required for configuration updates to active server realm:

{0}

.",
new Object[]

{realmName}

));
entity.put("restartRequired","true");
extraProperties.put("entity", entity);
((ActionReport) report).setExtraProperties(extraProperties);
}

Comment by kumarjayanti [ 06/Jan/11 ]

checked in the Partial Fix which will make the GUI work.

GUI has to invoke the new hidden command whenever an asadmin set is invoked on any realm.

The CLI this bug still remains if someone does the following sequence of operations :

1. asadmin copy-config default-config new-config
2. asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.
3. asadmin get new-config.security-service.auth-realm.admin-realm.property.file
new-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
4. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.
5. create the physical keyfile at /tmp/v3/admin-keyfile

After doing these steps, the following command will give a wrong answer :

1. asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

This is because the asadmin set command in step-4 above updates the Configuration Layer but does not update the Backend Realm which was loaded while executing step 2. So the list command will continue to list the user admin which was present in the original realm's keyfile (one that it was referring to before the set command changed it).

Summary of the CLI Bug : If an asadmin set command is executed to change a realm-property for a realm that was loaded by the backend (due to an earlier CLI command targeted at the realm) , then the realm continues to behave as if the set command was not executed. The workaround is to restart Appserver after a set command has been used to change a property of an already loaded realm.

Comment by Scott Fordin [ 15/Apr/11 ]

Issue added to 3.1 Release Notes.





[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-4595] Allow empty Base DN in LDAP Realm Created: 03/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: weberjn Assignee: raharsha
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,595

 Description   

If you create a new LDAPRealm you have to fill in a Base DN.

Unfortunately the Lotus Domino LDAP server has its user entries flat at the
toplevel, i.e. there is nothing above cn=myUser, no common root.

For Tomcat getting the users of this LDAP server is configured like this
(http://wiki.apache.org/tomcat/JNDI_HowTo), there is neither userBase nor roleBase:

<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionURL="ldap://ourldap"
userSearch="(cn=

{0}

)"
userRoleName="o"
/>

A user might have a DN like CN=Donald Duck,OU=marketing,O=DuckWest
or N=Daisy Duck,OU=sales,O=DuckEast

There is nothing above DuckWest and DuckEast.

So it should be possible not to specify a base DN.



 Comments   
Comment by kumara [ 01/Sep/09 ]

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

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-4524] Provide CLI/GUI support to add/modify/remove certificates to JKS Created: 28/Mar/08  Updated: 06/Mar/12

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

Type: New Feature Priority: Major
Reporter: claudio Assignee: claudio
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,524

 Description   

Actually glassfish v2 (b09d-fcs) doesn't have a CLI/GUI interface to easily
manage (add/modify/remove/request/search) certificates from a JKS database.

The features should be:

  • add certificate
  • provide a GUI interface to add certificates, signed by a CA.
  • support
  • RSA keys
  • JKS database as specified at the following properties
    -Djavax.net.ssl.keyStore
    -Djavax.net.ssl.trustStore
  • renew currently installed certificates
  • remove certificate
  • validate if any listener is using it
  • enable/disable each certificate
  • CA
  • list installed CAs
  • view detailed data for each CA
  • install a CA
  • enable/disable each CA
  • provide documentation about its usage


 Comments   
Comment by claudio [ 08/Apr/08 ]

I have setup a project over java.net related to this

https://certadmin.dev.java.net/

  • at this time, it is pending approval, a login is required to see any of its
    content.
Comment by claudio [ 08/Apr/08 ]

assigning to claudio

Comment by claudio [ 08/Apr/08 ]

development have started on March, 28, 2008

Comment by claudio [ 08/Apr/08 ]

changing it to v3 and changing it to STARTED

  • sorry, no more issue tracking spam
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-4390] JAAS – JDBCRealm too inflexible Created: 06/Mar/08  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: wip2 Assignee: raharsha
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,390

 Description   

The current com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm is too
limiting. And does not allow for Roles to be changed without a server restart.

Consider a more flexible approach in V3 (and retrospectively in V2?) such as
http://flexiblejdbcrealm.wamblee.org/

This allows for the deployment of ‘any’ database structure for JAAS
authentication. (the configuration is currently done at deployment by [SQL]
prepared statements).

If anybody has some spare time on there hands this could be extended to
include cashing and the use of remote EJBs [2.x / 3.x]. In my case I have a
remote database of CUSTOMERS which I want to authenticate them using JAAS and
can’t do it in Glassfish (without the FlexibleJDBCRealm workaround).



 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-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-1302] Improving certificate realm Created: 13/Oct/06  Updated: 06/Mar/12

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

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 1,302

 Description   

In the current Glassfish the "certificate" realm flexibility is limited. When
using applications over SSL, the this realm is enforced. Moreover, the
implementation class must be
com.sun.enterprise.security.auth.realm.certificate.CertificateRealm. This
implementation does not support login modules. Although principal names can be
placed in sun-application.xml it is curently impossible to change/assign user
roles or to add new users without redeploying the application.

A way should be added to allow extension of certificate realm behaviour.

Bogdan



 Comments   
Comment by Shing Wai Chan [ 03/Jan/07 ]

Changing user roles are not supported even in other realm.
In general, the role will not be changed for a given user and application.

Comment by bdaniliuc [ 14/Jan/07 ]

My understanding is that it is not possible to create new roles. But it is
possible to have something like this:

<security-role-mapping>
<role-name>Accounting</role-name>
<group-name>Accounting</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>Management</role-name>
<group-name>Management</group-name>
</security-role-mapping>

and have a LDAP realm that has user A in Accounting and B in Management and
then move A from Accounting in Management without actually redeploying the
application. It is also possible to add a user to any of the given groups and
the user will be allowed to access the application without redeploying it.
With certificate realm it is currently not possible to:

  • perform additional validation on the certificate, for example OCSP
    validation, or validation against a CRL stored in LDAP.
  • separate users in groups based on some criteria, for example based on OU
    information.
Comment by Shing Wai Chan [ 31/May/07 ]

reassign

Comment by cpdprogramacion [ 11/Jul/07 ]
      • Issue 1302 has been confirmed by votes. ***
Comment by raharsha [ 13/Nov/07 ]

Accept 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-1015] Provide more config options for realms Created: 24/Aug/06  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: barz26 Assignee: raharsha
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: 1,015

 Description   

If a custom realm fails the app server is doing a fallback to the default/file
realm. A better solution would be to provide a configuration item where it can
be specified:

  • if the server should refuse to start at all after a realm failure.
  • if applications using this realm shall be disabled


 Comments   
Comment by Shing Wai Chan [ 31/May/07 ]

reassign

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-16473] Introduce a default CertStore in GlassFish that can be used by JSR196 CertStoreCallback Created: 27/Apr/11  Updated: 18/Oct/12

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: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred

 Description   

In Metro Security there is a usecase which requires that the Server store the Client Certificates and Vice-Versa. In such situations today we store the client certificate in the Server Truststore and similarly the Server Certificate is stored in the Client Truststore. Storing non-CA certificates in TrustStore is not a good idea from a security perspective.

The Java CertStore (http://download.oracle.com/javase/6/docs/api/java/security/cert/CertStore.html) is an appropriate place to store such other-party non-CA certificates. The JSR196 CertStoreCallback in GlassFish however returns the GF truststore as the CertStore.

As a first step we would like to introduce a new keystore in the domain config that will be exposed as a CertStore via the JSR196 Default CallbackHandler in GlassFish. In a later release (if developers really ask for it) we could think of a CertStore configuration element under security-service. That would allow more flexibility on what the CertStore backend really is (for example an LDAP). Today Metro developers have the option of overriding the whole GlassFish JSR-196 CallbackHandler, and this would allow them to have any arbitary CertStore implementation.



 Comments   
Comment by kumarjayanti [ 27/Apr/11 ]

Impact on ADMIN GUI/CLI
----------------------

Since Keystore contents are really not managed by Admin GUI/CLI today so adding a new keystore to the domain config does not cause any impact on Admin.

Impact on Cluster Replication Framework
------------------------------

The Cluster replication framework should apply the same rules for this new keystore (named certstore.jks) as it does for the GF keystore and truststore. IOW, instance config's should have a copy of the certstore.jks. And updates to certstore.jks on the DAS followed by touching domain.xml should cause the updated certstore.jks to be synced to the instances upon cluster restart.

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-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-21129] User ID in File security realm affects role mapping Created: 14/Jul/14  Updated: 14/Jul/14

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

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

using nightly build from 2014-07-14
using following param in config:
<security-service activate-default-principal-to-role-mapping="true">



 Description   

Suppose following two simple classes:

@Stateless
@RunAs("student")
@PermitAll
public class Student {

    @Resource
    private SessionContext context;

    @EJB
    Notebook notebook;

    public String getNotebookPrincipal(){
        return notebook.getCallerPrincipal();
    }

    public String getStudentPrincipal(){
        return context.getCallerPrincipal().toString();
    }
}

and:

@Stateless
@RunAs("notebook")
@RolesAllowed("student")
public class Notebook {

    @Resource
    private SessionContext context;

    public String getCallerPrincipal(){
        return context.getCallerPrincipal().toString();
    }
}

When I have following mapping then it's fine:

User ID Group
student student
notebook student:notebook

but I cannot see any reason, why it should fail with e.g.:

User ID Group
john student
notebook student:notebook

Getting:

Caused by: javax.ejb.EJBAccessException
	at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2351)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2123)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy254.getCallerPrincipal(Unknown Source)
	at test.sceurity.__EJB31_Generated__Notebook__Intf____Bean__.getCallerPrincipal(Unknown Source)
	at test.sceurity.Student.getNotebookPrincipal(Student.java:29)
	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:606)
	at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
	at sun.reflect.GeneratedMethodAccessor296.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
	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:606)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
	... 103 more
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation
	at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1960)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
	... 137 more


 Comments   
Comment by tremes [ 14/Jul/14 ]

Maybe I am wrong, but I understand that @RunAs specifies role name and not user name. I would attach simple reproducer app, but looks like I cannot.





[GLASSFISH-21025] Expired certificate: GTE CyberTrust Created: 01/Apr/14  Updated: 21/Sep/15

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

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

GF 4.0 GA ZIP, Win 7 Pro SP1 (64 Bit), JDK 1.8.0 (32 Bit)


Tags: 4_0_1-review

 Description   

After starting GlassFish 4.0 on JDK 1.8.0 I got the following SEVERE message in the server.log. I do not think that it is nice that a freshly installed brand-new GlassFish prints a SEVERE message... Would be better in GlassFish bundles an updates certificate instead.

[2014-04-01T14:45:11.671+0200] [glassfish 4.0] [SEVERE] [java_security.expired_certificate] [javax.enterprise.system.ssl.security.com.sun.enterprise.security.ssl.impl] [tid: _ThreadID=111 _ThreadName=admin-listener(7)] [timeMillis: 1396356311671] [levelValue: 1000] [[
SEC5054: Certificate has expired: [
[
Version: V3
Subject: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 2048 bits
modulus: 23741889829347261660812437366387754385443431973861114865490414153884050331745811968523116847625570146592736935209718565296053386842135985534863157983128812774162998053673746470782252407673402238146869994438729551246768368782318393878374421033907597162218758024581735139682087126982809511479059100617027892880227587855877479432885604404402435662802390484099065871430585284534529627347717530352189612077130606642676951640071336717026459037542552927905851171460589361570392199748753414855675665635003335769915908187224347232807336022456537328962095005323382940080676931822787496212635993279098588863972868266229522169377
public exponent: 65537
Validity: [From: Fri Aug 14 16:50:00 CEST 1998,
To: Thu Aug 15 01:59:00 CEST 2013]
Issuer: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
SerialNumber: [ 01b6]

Certificate Extensions: 4
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:5
]

[2]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [1.2.840.113763.1.2.1.3]
[] ]
]

[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]

[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 76 0A 49 21 38 4C 9F DE F8 C4 49 C7 71 71 91 9D v.I!8L....I.qq..
]
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 41 3A D4 18 5B DA B8 DE 21 1C E1 8E 09 E5 F1 68 A:..[...!......h
0010: 34 FF DE 96 F4 07 F5 A7 3C F3 AC 4A B1 9B FA 92 4.......<..J....
0020: FA 9B ED E6 32 21 AA 4A 76 C5 DC 4F 38 E5 DF D5 ....2!.Jv..O8...
0030: 86 E4 D5 C8 76 7D 98 D7 B1 CD 8F 4D B5 91 23 6C ....v......M..#l
0040: 8B 8A EB EA 7C EF 14 94 C4 C6 F0 1F 4A 2D 32 71 ............J-2q
0050: 63 2B 63 91 26 02 09 B6 80 1D ED E2 CC B8 7F DB c+c.&...........
0060: 87 63 C8 E1 D0 6C 26 B1 35 1D 40 66 10 1B CD 95 .c...l&.5.@f....
0070: 54 18 33 61 EC 13 4F DA 13 F7 99 AF 3E D0 CF 8E T.3a..O.....>...
0080: A6 72 A2 B3 C3 05 9A C9 27 7D 92 CC 7E 52 8D B3 .r......'....R..
0090: AB 70 6D 9E 89 9F 4D EB 1A 75 C2 98 AA D5 02 16 .pm...M..u......
00A0: D7 0C 8A BF 25 E4 EB 2D BC 98 E9 58 38 19 7C B9 ....%..-...X8...
00B0: 37 FE DB E2 99 08 73 06 C7 97 83 6A 7D 10 01 2F 7.....s....j.../
00C0: 32 B9 17 05 4A 65 E6 2F CE BE 5E 53 A6 82 E9 9A 2...Je./..^S....
00D0: 53 0A 84 74 2D 83 CA C8 94 16 76 5F 94 61 28 F0 S..t-.....v_.a(.
00E0: 85 A7 39 BB D7 8B D9 A8 B2 13 1D 54 09 34 24 7D ..9........T.4$.
00F0: 20 81 7D 66 7E A2 90 74 5C 10 C6 BD EC AB 1B C2 ..f...t\.......



 Comments   
Comment by Nithya Ramakrishnan [ 02/Apr/14 ]

Removed the expired trustedcert entry from the cacerts.jks in the source repository.

Transmitting file data ....
Committed revision 63173.

Comment by David Delabassee [ 27/Jun/14 ]

The Embedded Container still carry the expired CyberTrust Cert





[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-20037] Investigate the Restricted Permissions vs Allowed Permissions (or Not restricted policy) for Application Packaged Permission feature Created: 25/Mar/13  Updated: 28/Mar/13

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

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


 Description   

In the current commuted code (revision 60776), the domain restriction is through the restrict.server.policy file, this has following issues:

1) the AllPermission in restriction list means that the app declared permission can not include AllPermission, and does not mean the application can not declare other permissions. This is an exception compared to other entries in the restriction file, i.e., other entries are checked against the declared permissions by "imply" call.

2) By restriction list, the admin knows what he wants to restrict, but still has no full picture of what the application may get. An configured allowed list can limit the applications to have permissions exist on the allowed list, but the list might be long since an exhaustive list is needed. A metafile policy approach for the allowed list (or not-restricted policy) may be able to define restriction by following some syntax. A declared permission can be granted only if it is implied by a permission on the not restricted list. When the Not restricted list/collection is empty, no declared permission can be declared; including AllPermission.

We need to investigate this further from the points of security completeness, and also useability point of view.






[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