[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: 0
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 Ve [ 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 Ve [ 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 Ve [ 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-21308] Support for TLS_FALLBACK_SCSV to prevent downgrade attack Created: 21/Feb/15  Updated: 21/Feb/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: 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   

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






[GLASSFISH-20689] @runAs annotation fails when ejb is called from servlet during deplyment Created: 09/Jul/13  Updated: 19/Sep/14

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

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

OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-1ubuntu1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)



 Description   

I have a EAR project containing an EJB and a WEB module. The EJB module contains a stateless session ejb with a runAs annotation:

@DeclareRoles({ "org.imixs.ACCESSLEVEL.MANAGERACCESS" })
@RunAs("org.imixs.ACCESSLEVEL.MANAGERACCESS")
@Stateless
@Local
public class UserGroupService {
....

In the web module there is a Servlet defined whith a loadOnStartup=1 option:

@WebServlet(loadOnStartup=1)
public class SetupServlet extends HttpServlet {
	@EJB
	UserGroupService userGroupService;

To declare the RunAs annotation the EAR module contains a glassfish-application.xml file with

	<security-role-mapping>
		<role-name>org.imixs.ACCESSLEVEL.MANAGERACCESS</role-name>
		<group-name>IMIXS-WORKFLOW-Manager</group-name>
		<principal-name>IMIXS-WORKFLOW-Service</principal-name>
	</security-role-mapping>	

So I think I map a principal to that role which is used to by the RunAs annotation.
In addition the ejb module contains a glassfish-ejb-jar.xml file with :

	<ejb>
			<ejb-name>UserGroupService</ejb-name>
			<principal>
				<name>IMIXS-WORKFLOW-Service</name>
			</principal>
		</ejb>

During deployment the servlet should call some methods of the UserGroupService. The UserGroupService is injected as far as I can see during debugging.
But now I got a "Could not create stateless EJB" exception when the servlet tries to call a EJB method.

The same ear deploys on GlassFish 3.1.2.2 without any problem.
Are there any changes in the security definition? Or is there something going wrong during the deployment process of GlassFish4



 Comments   
Comment by rsoika [ 30/Dec/13 ]

I am now running nightly build glassfish4.0.1.b04-12_28_2013
But it seems that I have still the same issue. The only log file information is:

WARNING: A system exception occurred during an invocation on EJB ProfileService, method: public org.imixs.workflow.ItemCollection org.imixs.marty.ejb.ProfileService.lookupProfileById(java.lang.String)

Can I do anything to provide you with helpful information? Or can you tell me what that issue depends on?

Comment by rsoika [ 30/Dec/13 ]

During deployment I see the following warning. But no information why that warning is shown:

[2013-12-30T16:09:01.431+0100] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.tools.deployment.dol] [tid: _ThreadID=59 _ThreadName=AutoDeployer] [timeMillis: 1388416141431] [levelValue: 900] [[
enterprise.deployment.backend.computeRunAsPrincipal]]

Comment by rsoika [ 14/Jan/14 ]

I have not tested the application with WildFly. I can deploy the same application without any problems on WildFly 8

Comment by Nithya Ramakrishnan [ 05/Mar/14 ]

Hi,

Have you tried moving the security-role-mapping to glassfish-ejb-jar.xml from glassfish-application.xml ?
If the same prb exists, couuld you pls attach the app ?





[GLASSFISH-20692] The message "jaccfactory.notfound" in WebSecurityManager is not defined in the property File. Created: 10/Jul/13  Updated: 19/Sep/14

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

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

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)



 Description   

Reproducible operational steps:

asadmin set server.security-service.jacc=h.b.aaaa

asadmin restart-domain

You can see the message below in the server.log

[2013-07-10T13:03:28.431+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core.security] [tid: _ThreadID=83 _ThreadName=Thread-15] [timeMillis: 1373425408431] [levelValue: 1000] [[
jaccfactory.notfound]]

Issues:
"jaccfactory.notfound" is not appropriate as the message logged in server.log.

Detailed description of the issue:

The message is logged by WebSecurityManager
(https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/web/integration/WebSecurityManager.java) as shown below

public class WebSecurityManager {
private static final Logger logger =
Logger.getLogger(LogDomains.SECURITY_LOGGER);
/** lines ignored **/
private synchronized PolicyConfigurationFactory _getPolicyFactory()
throws PolicyContextException {
if (pcf == null) {
try

{ pcf = PolicyConfigurationFactory.getPolicyConfigurationFactory(); }

catch(ClassNotFoundException cnfe)

{ logger.severe("jaccfactory.notfound"); throw new PolicyContextException(cnfe); }

catch(PolicyContextException pce)

{ logger.severe("jaccfactory.notfound"); throw pce; }

}
return pcf;
}
/** lines ignored **/
}

However, the message "jaccfactory.notfound" is not defined in LogStrings.properties
(https://svn.java.net/svn/glassfish~svn/branches/4.0/nucleus/security/core/src/main/resources/com/sun/logging/enterprise/system/core/security/LogStrings.properties) for WebSecurityManager .

I think the message "jaccfactory.notfound" should be defined in LogStrings.properties for WebSecurityManager.

Below is a sample from EJBSecurityManager which has situation.
The message "jaccfactory.notfound" is defined in LogStrings.properties (https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/ejb/ejb-container/src/main/resources/com/sun/logging/enterprise/system/container/ejb/LogStrings.properties)
for EJBSecurityManager (https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/security/application/EJBSecurityManager.java).



 Comments   
Comment by xianwu [ 10/Jul/13 ]

Sorry, there is a typo

"Below is a sample from EJBSecurityManager which has situation." =>
"Below is a sample from EJBSecurityManager which has a similar situation."

Comment by xianwu [ 23/Jul/13 ]

Hi Jeff

The problem is not fixed in 4.0.1 (b02-07_22_2013 build).

To reproduce the problem, you need to start GF Server Admin Console. Below are modified steps.

Reproducible operational steps:

asadmin start-domain

asadmin set server.security-service.jacc=h.b.aaaa

asadmin stop-domain

asadmin start-domain

You can see the message below in the server.log

[2013-07-23T13:44:01.478+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core.security] [tid: _ThreadID=114 _ThreadName=Thread-18] [timeMillis: 1374551041478] [levelValue: 1000] [[
jaccfactory.notfound]]

[2013-07-23T13:44:01.478+1000] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=114 _ThreadName=Thread-18] [timeMillis: 1374551041478] [levelValue: 1000] [[
Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: Error in generating security policy for __admingui – javax.security.jacc.PolicyContextException: java.lang.ClassNotFoundException: JACC:Error PolicyConfigurationFactory : cannot find class : null
at com.sun.enterprise.security.web.integration.WebSecurityManagerFactory.createManager(WebSecurityManagerFactory.java:305)
at com.sun.enterprise.security.ee.SecurityDeployer.loadPolicy(SecurityDeployer.java:234)
at com.sun.enterprise.security.ee.SecurityDeployer.access$000(SecurityDeployer.java:87)
at com.sun.enterprise.security.ee.SecurityDeployer$AppDeployEventListener.event(SecurityDeployer.java:135)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:233)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
]]

start GF Server Admin Console (http://localhost:4848/common/index.jsf)

Can you please reopen it to further investigate?

Regards, Xianwu

Comment by xianwu [ 23/Jul/13 ]

Hi Jeff

Sorry, I inserted server.log in a wrong block.

Here is the correction.

Reproducible operational steps:

asadmin start-domain

asadmin set server.security-service.jacc=h.b.aaaa

asadmin stop-domain

asadmin start-domain

start GF Server Admin Console (http://localhost:4848/common/index.jsf)

You can see the message below in the server.log

[2013-07-23T13:44:01.478+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core.security] [tid: _ThreadID=114 _ThreadName=Thread-18] [timeMillis: 1374551041478] [levelValue: 1000] [[
jaccfactory.notfound]]

[2013-07-23T13:44:01.478+1000] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=114 _ThreadName=Thread-18] [timeMillis: 1374551041478] [levelValue: 1000] [[
Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: Error in generating security policy for __admingui – javax.security.jacc.PolicyContextException: java.lang.ClassNotFoundException: JACC:Error PolicyConfigurationFactory : cannot find class : null
at com.sun.enterprise.security.web.integration.WebSecurityManagerFactory.createManager(WebSecurityManagerFactory.java:305)
at com.sun.enterprise.security.ee.SecurityDeployer.loadPolicy(SecurityDeployer.java:234)
at com.sun.enterprise.security.ee.SecurityDeployer.access$000(SecurityDeployer.java:87)
at com.sun.enterprise.security.ee.SecurityDeployer$AppDeployEventListener.event(SecurityDeployer.java:135)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:233)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
]]

Can you please reopen it to further investigate?

Regards, Xianwu





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

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 4.0
Fix Version/s: 4.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-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: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 4.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-19790] configure-ldap-for-admin should be investigated such that the default security service configuration is updated when switching admin realm to LDAP. Created: 07/Mar/13  Updated: 19/Sep/14

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

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


 Description   

configure-ldap-for-admin should be investigated such that the default security service configuration is updated when switching admin realm to LDAP.






[GLASSFISH-14860] create-file-user should allow specifying target Created: 29/Nov/10  Updated: 19/Sep/14

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

Type: Bug Priority: Minor
Reporter: Anissa Lam Assignee: kumarjayanti
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-14797 Realm: error when adding a user to a ... Closed
blocks GLASSFISH-14770 Realm: new user added to admin-realm ... Closed
Tags: 3-1-regression

 Description   

list-file-users , delete-file-user takes in target, but create-file-user doesn't.

Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username

Without being able to specify the target during creation, it seems this user is created for EVERY instance.
here is what i see:

%asadmin create-file-user --authrealmname file userABC

Command create-file-user executed successfully.

%asadmin list-file-users --authrealmname file server
userABC
Command list-file-users executed successfully.

%asadmin list-file-users --authrealmname file instance-1
userABC
Command list-file-users executed successfully.

Besides missing the target option, list and delete doesn't takes in config name as target.
%asadmin list-file-users --authrealmname file sever-config
org.glassfish.api.admin.CommandException: remote failure: Unable to find a valid target with name sever-config
Command list-file-users failed.
This doesn't sound right since any security realm is based on configuration, so it should take in config name as target as well.

GUI issue (GLASSFISH-14797) and (GLASSFISH-14770) is depending on this bug fix. We want the following to happen:

1. add 'target' as an option for create-file-user (blocks GLASSFISH-14770)
2. config name should be a valid target. (blocks GLASSFISH-14797)



 Comments   
Comment by kumarjayanti [ 30/Nov/10 ]

Note : create-file-user and delete-file-user already support a --target option. It has to be a --target since the username is the operand for these commands and this is not any different from V2.

Added CONFIG as a targetype.

Note : When dealing with create-file-user and delete-file-user you really need to look at what the Property

<property value="$

{com.sun.aas.instanceRoot}

/config/keyfile" name="file" />

is pointing to. For example the same property above appears in default-config and server-config. So if you do

create-file-user with one config and do list-file-users with another config. You might see the new user under the second config if they share the same keyfile. This is not a bug in security.

Comment by kumarjayanti [ 30/Nov/10 ]

fixed

Comment by Anissa Lam [ 18/Dec/10 ]

I have to reopen this issue.
I don't see a target option for create-file-user with the latest nightly build 12/18.

Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username
Command create-file-user failed.

Comment by Anissa Lam [ 18/Dec/10 ]

Raising the issue. This has to be fixed for 3.1

Comment by kumarjayanti [ 19/Dec/10 ]

------------------
%asadmin list-file-users --authrealmname file sever-config
org.glassfish.api.admin.CommandException: remote failure: Unable to find a valid target with name sever-config
Command list-file-users failed.
This doesn't sound right since any security realm is based on configuration, so it should take in config name as target as well.
-------------------

This command above is giving a bogus config as argument and hence the failure is correct. I think you misspelled server-config as sever-config.

---------here is the output for right config------
./asadmin list-file-users --authrealmname file server-config
test1
test
Command list-file-users executed successfully.
-------------------------------------------

Same issue with delete-file-users

-------------------
$ ./asadmin delete-file-user --authrealmname file --target server-config test1
Command delete-file-user executed successfully.
$ ./asadmin list-file-users --authrealmname file server-config
test
Command list-file-users executed successfully.
--------------------

And create-file-users does accept a --target option :

---------------------------------
$ ./asadmin create-file-user --authrealmname file --target server-config test2
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
$ ./asadmin list-file-users --authrealmname file server-config
test2
test
Command list-file-users executed successfully.

----------------------------------

And here is the output of create-file-user --help (it does show the --target option in the help and a config is acceptable as an argument.

$ ./asadmin create-file-user --help

asadmin Utility Subcommands create-file-user(1)

NAME
create-file-user - creates a new file user

SYNOPSIS
create-file-user[--help] [--authrealmname auth_realm_name]
[--target target
[--groups user_groups[:user_groups]*] user_name

DESCRIPTION
Thecreate-file-user subcommand creates an entry in the key-
file with the specified username, password, and groups. Mul-
tiple groups can be created by separating them with a colon
(. If auth_realm_name is not specified, an entry is
created in the keyfile for the default realm. If
auth_realm_name is specified, an entry is created in the
keyfile using the auth_realm_name.

This subcommand is supported in remote mode only.

OPTIONS
--help
-?

Displays the help text for the subcommand.

--target
This is the name of the target on which the command
operates. The valid targets are config, instance, clus-
ter, or server. By default, the target is the server.

This option is valid only in domains that are configured
to support clusters, such as domains that are created
with the cluster profile or the enterprise profile.

--groups

This is the group associated with this file user.

--authrealmname
This is the file where the file users are stored.

OPERANDS
user_name This is the name of file user to
be created.

Java EE 6 Last change: 01 December 2010 1

asadmin Utility Subcommands create-file-user(1)

EXAMPLES
Example 1 Creating a User in the File Realm

This example creates a file realm user named sample_user. It
is assumed that an authentication realm has already been
created using the create-auth-realm subcommand.

asadmin> create-file-user
--groups staff:manager
--authrealmname auth-realm1 sample_user
Command create-file-user executed successfully

EXIT STATUS
0 subcommand executed successfully

1 error in executing the subcom-
mand

SEE ALSO
create-auth-realm(1), delete-file-user(1), list-file-
users(1), update-file-user(1), list-file-groups(1)

Comment by kumarjayanti [ 19/Dec/10 ]

closing the issue as cannot reproduce unless you give me the specific create-file-user command that is failing/refusing to accept a --target.

Comment by Anissa Lam [ 19/Dec/10 ]

ok, man page is correct and include --target.
But usage does NOT have --target as an option. Thats why i was confused.

Please fix the usage text so there is no confusion. I still see issues with creating and listing file user. will file another bug.

Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username

Also, since authrealmname is optional, what is the realmname defaults to if not specified. Man page didn't specify that either.

Comment by kumarjayanti [ 19/Dec/10 ]

Where is the usage controlled from and how do you get the usage string ?. Can you tell me the command which prints the usage ?, why is there a separate Usage apart from --help which shows up the manpage. It is not the security code that controls the usage. So please transfer the bug to Docs or Admin.

Here is the usage that we have in comments on top of create-file-user.

/**

  • Create File User Command
  • Usage: create-file-user [--terse=false] [--echo=false] [--interactive=true]
  • [--host localhost] [--port 4848|4849] [--secure | -s]
  • [--user admin_user] [--userpassword admin_passwd]
  • [--passwordfile file_name] [--groups user_groups[:user_groups]*]
  • [--authrealmname authrealm_name] [--target target(Default server)]
  • username
    *
  • @author Nandini Ektare
    */
Comment by Anissa Lam [ 19/Dec/10 ]

Tom,
Can you comment on how to fix the usage of a command ? If this is a trivial fix, maybe we should address that for 3.1
thanks

Comment by Tom Mueller [ 20/Dec/10 ]

The usage message is either automatically generated based on the @Param annotations, or, if the @I18n annotation is provided, and the appropriate key exists in the LocalStrings.properties file, then the usage message is taken from the properties file.

In the case of create-file-user, it is the latter. The usage message is in the LocalStrings.properties file, and that message is missing the --target part.

Reassigning back to Kumar to fix.

Comment by Tom Mueller [ 21/Dec/10 ]

The 2.1.1 release has a --target option for the create-file-user command, so this is a regression.





[GLASSFISH-20182] configure-ldap-for-admin command should allow the full set of LDAP configuration, not just basedn and ldap-group Created: 04/Apr/13  Updated: 19/Sep/14

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

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

Issue Links:
Related
is related to GLASSFISH-19525 Enabling secure admin fails if admin ... Resolved

 Description   

(inspired by a comment from javashawn on GLASSFISH-19525)

[W]hen we originally began working with setting up GF admin realm to use LDAP we were trying to understand why the configure-ldap-for-admin subcommand only let you set the basedn and ldap-group attributes? This is what started us down the path of using a domain template that populated the other attributes (such as group-search-filter). It seems like the configure-ldap-for-admin command should allow for setting the same properties available for the LDAPRealm?






[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-1861] Make default RMI registry secure Created: 01/Jan/07  Updated: 25/Apr/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 1,861

 Description   

The RMI Registry that application server starts is insecure. Any program running
on the given machine can always take disadvantage of this insecure nature and might
bring down the GlassFish server.

Take cues from
http://weblogs.java.net/blog/emcmanus/archive/2006/12/securing_the_rm.html

I am filing this as a P2. Assign/redirect appropriately.



 Comments   
Comment by ne110415 [ 27/Feb/07 ]

The link is a very good read of interesting and informative suggestions.

From our perspective, however, I do not think the risk/return for incorporating
the various suggestions would be justified. For one, the blog itself
discourages some of the suggestions from being implemented outside JDK and
other ways might mandate us to monitor interface changes in the JDK - we do use
custom server socket factories. Though changing priority to P5, retaining the
bug in case we do get more ideas to fix this issue.

Comment by Tom Mueller [ 23/Jun/10 ]

Nandini no longer on project.

Comment by Tom Mueller [ 24/Jan/11 ]

The RMI registry runs as part of the JMX service on port 8686.

Consider this small program that plays with the registry:

import java.rmi.*;

public class Rmi {
public static void main(String args[]) throws Exception {
String []n = Naming.list(args[0]);
for (String s : n)

{ System.out.println(s); Remote r = Naming.lookup(s); System.out.println(" " + r.getClass().getName()); System.out.println("trying unbind"); Naming.unbind(s); }

}
}

When run with "//localhost:8686/" as an argument while a GlassFish domain is running on the same system, the program produces the following output:

$ java Rmi //localhost:8686/
//localhost:8686/jmxrmi
javax.management.remote.rmi.RMIServerImpl_Stub
trying unbind

If the program is run again, it produces no output because the "jmxrmi" name has been unbound.

Even if the admin password is set to something, it is still possible to run this program with no password and unbind the "jmxrmi" name. Or, the name could be bound to some other object which could then be used to hijack passwords, etc. I'm not aware of anyway to bring down the GlassFish server directly by using this hole.

Increasing the priority of this issue. Assigning this to the security team to evaluate the importance of fixing this issue for 3.2.





[GLASSFISH-3850] Changing default realm does not indicate that a server restart required Created: 09/Nov/07  Updated: 25/Apr/14

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

Type: Bug Priority: Minor
Reporter: r_sudh 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: 3,850
Status Whiteboard:

as91ur1-na


 Description   

When using the web based Admin Console, changing the Default Realm under
Configuration > Security does not indicate that the server needs to be restarted
for the change to take affect.

Either the GUI needs to display the "Restart required" warning message or maybe
this is a bug in the Security module where the change is not being applied right
away.



 Comments   
Comment by Anissa Lam [ 12/Nov/07 ]

I believe changing Default Realm doesn't require server restart. Using CLI, i
did 'list-domains' and it also doesn't say server require restart.

I am transferring this to 'security'.
If changing default realm shouldn't require server restart, then what the user
reported here is expected and is not a bug.

If changing default realm really require server restart, then whatever is told
to GUI and CLI is wrong, someone needs to fix this.

Either way, this is not a GUI issue.

Comment by basler [ 12/Nov/07 ]

Not a show stopper for 91ur1

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

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-3967] Method RegStoreFileParser.getPersistedEntries() is not thread safe Created: 04/Jan/08  Updated: 25/Apr/14

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

Type: Bug Priority: Minor
Reporter: aarongreenhouse 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: 3,967

 Description   

The method
com.sun.enterprise.security.jmac.config.RegStoreFileParser.getPersistedEntries()
is not thread safe. It has two problems: (1) it accesses the field entries
without synchronizing on confFile, and (2) it should return a copy of the list,
not a pointer to the list, because you cannot trust the caller of the method to
access the list with the correct synchronization.

The method should be written as

List<EntryInfo> getPersistedEntries() {
synchronized (confFile)

{ return Collections.unmodifiableList(new ArrayList<EntryInfo>(entries)); }

}

This version returns an unmodifiable copy of the list of entries. Technically
you just need to return a copy, but there isn't any good reason to allow the
caller to modify the copy, it will likely just cause problems.

If you really don't want to return a copy, you can instead return a wrapped
version of the list that is properly protected:

List<EntryInfo> getPersistedEntries() {
synchronized (confFile)

{ return Collections.unmodifiableList(Collections.synchronizedList(entries, confFile)); }

}

This version avoids copying, prevents the caller from modifying the list, and
prevents the caller from viewing the list while the list is being modified
inside RegStoreFileParser.

I think the copying solution is less likely to cause future issues, but I can
understand if you want to avoiding copying. I don't know enough about how often
or even when this method is called to make a better recommendation.



 Comments   
Comment by kumarjayanti [ 08/Feb/08 ]

started

Comment by harpreet [ 10/Apr/08 ]

assigning to Kumar

Comment by harpreet [ 15/Apr/08 ]

Based on input from Kumar - issue not critical to v2.1. Marking it for next release.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumarjayanti [ 13/Apr/11 ]

marking for 3.2





[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-5250] Stability tests using SSL listener results in crash Created: 02/Jul/08  Updated: 25/Apr/14

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

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

Operating System: Solaris
Platform: Sun


Attachments: Text File Case5250-java.security    
Issuezilla Id: 5,250
Status Whiteboard:

as911-na


 Description   

We've been doing some stability tests for opensso and encountered an issue with
our SSL setup. During the test the server will crash with "not enough swap?"
message.

[#|2008-06-19T16:16:15.677-0500|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=18;_ThreadName=httpSSLWorkerThread-39390-3;_RequestID=4b5c5ebc-db89-40af-b0d4-4ccfb95c2cb2;|WEB0777:
Unblocking keep-alive exception
java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory(Native Method)
at sun.nio.ch.NativeObject.<init>(NativeObject.java:60)
at sun.nio.ch.AllocatedNativeObject.<init>(AllocatedNativeObject.java:34)
at
sun.nio.ch.DevPollArrayWrapper.updateRegistrations(DevPollArrayWrapper.java:190)
at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:163)
at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:68)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
at sun.nio.ch.SelectorImpl.selectNow(SelectorImpl.java:88)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLUtils.doRead(SSLUtils.java:181)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLByteBufferInputStream.doRead(SSLByteBufferInputStream.java:70)
at
com.sun.enterprise.web.connector.grizzly.ByteBufferInputStream.read(ByteBufferInputStream.java:167)
at
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:727)
at
org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:401)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.parseRequest(DefaultProcessorTask.java:684)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:566)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLReadTask.process(SSLReadTask.java:440)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLReadTask.doTask(SSLReadTask.java:228)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)

#]

A core file was generated. The main error reported in the hs_err_pidxxx.log file
was :

  1. java.lang.OutOfMemoryError: requested 1064 bytes for intptr_t in
    /BUILD_AREA/jdk6_06/hotspot/src/share/vm/runtime/deoptimization.cpp. Out of swap
    space?
    #
  2. Internal Error (allocation.inline.hpp:42), pid=452, tid=108
  3. Error: intptr_t in
    /BUILD_AREA/jdk6_06/hotspot/src/share/vm/runtime/deoptimization.cpp

We were able to reproduce the problem with JDK1.5 and JDK1.6 (though it took a
lot longer).

We also were able to reproduce this by simply hitting the index.html page using
our load generator.

The following tuning was applied :

File : /opt/famperftests/glassfish/glassfish/domains/domain1/config/domain.xml
(using asadmin command line tool)
Parameter tuning :

1. Acceptor Threads
Current Value : acceptor-threads=8
Recommended Value : acceptor-threads=8

2. Max Pending Count Threads
Current Value : max-pending-count=8192
Recommended Value : max-pending-count=8192

3. Queue Size
Current Value : queue-size=8192
Recommended Value : queue-size=8192

4. native-library-path-prefix (if Solaris 8)
Current Value : native-library-path-prefix=<No value set>
Recommended Value : native-library-path-prefix=/usr/lib/lwp

5. Max and Min Heap Size
Current Value : Min Heap: -Xms3136M Max Heap: -Xmx3136M
Recommended Value : -Xms3136M -Xmx3136M

6. LogGC Output
Current Value :
-Xloggc:/opt/famperftests/glassfish/glassfish/domains/domain1/logs/gc.log
Recommended Value :
-Xloggc:/opt/famperftests/glassfish/glassfish/domains/domain1/logs/gc.log

7. JVM in Server mode
Current Value : -server
Recommended Value : -server

8. Stack Size
Current Value : -Xss128k
Recommended Value : -Xss128k

9. New Size
Current Value : -XX:NewSize=392M
Recommended Value : -XX:NewSize=392M

10. Max New Size
Current Value : -XX:MaxNewSize=392M
Recommended Value : -XX:MaxNewSize=392M

11. Disable Explicit GC
Current Value : -XX:+DisableExplicitGC
Recommended Value : -XX:+DisableExplicitGC

12. Use New Parallel GC
Current Value : -XX:+UseParNewGC
Recommended Value : -XX:+UseParNewGC

13. Print Class Histogram
Current Value : -XX:+PrintClassHistogram
Recommended Value : -XX:+PrintClassHistogram

14. Print GC Time Stamps
Current Value : -XX:+PrintGCTimeStamps
Recommended Value : -XX:+PrintGCTimeStamps

15. OverrideDefaultLibthread (if Solaris 8)
Current Value : <No value set>
Recommended Value : -XX:+OverrideDefaultLibthread

16. Enable Conc Mark Sweep GC
Current Value : -XX:+UseConcMarkSweepGC
Recommended Value : -XX:+UseConcMarkSweepGC

18. Parallel GC Threads
Current Value : -XX:ParallelGCThreads=8
Recommended Value :



 Comments   
Comment by kumarjayanti [ 02/Jul/08 ]

Reassigning since this seems like a Grizzly issue

Comment by jfarcand [ 04/Jul/08 ]

Hum, can you download the latest nightly? I suspect you are facing:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=4945

Download the latest v2.1 b40 from here:

https://glassfish.dev.java.net/public/alldownloads.html#GlassFish_v2_1_branch

As a workaround, could you turn acceptor-thread back to 1, and instead allocate
more Thread using <request-processing ...thread-count=""/>. If you are still
seeing the problem, can you give us more information about the load generator
you are using? We gonna needs to reproduce the problem internally

Thanks!

Comment by nphilipp [ 07/Jul/08 ]

Ok. Just upgraded to build40.

What thread-count would you recommend ? By leaving it to the default (see below)
we're seeing some really bad throughput. We have about 100 threads used for load
generation hitting index.html on the HTTPS listener.

<request-processing header-buffer-length-in-bytes="8192"
initial-thread-count="2" request-timeout-in-seconds="30" thread-count="5"
thread-increment="1"/>

Comment by oleksiys [ 08/Jul/08 ]

Did you try to run client and server on different PCs? So we can exclude possible client-side problems?

WBR

Comment by nphilipp [ 30/Jul/08 ]

oleksiys,

client and server are on different machine. The load generator is "The Grinder"
which essentially simulates https connections coming from a web browser.

Please let me know what else you need to start testing this on your side. I'd
like to have a confirmation that you can reproduce this.

Thanks,
N.

Comment by oleksiys [ 08/Aug/08 ]

can you pls. provide the instructions how I can configure and run grinder loadtest?

Thank you.

Comment by oleksiys [ 08/Aug/08 ]

Can I get access to the testing environment, both client and server (SSH access) to be able to reproduce
the issue and try patches.

Pls. let me know if it's possible.

Comment by oleksiys [ 26/Aug/08 ]

It looks like this is JVM issue. GC is not able to clean up unused objects in time.
Once I added small trick to find out which object type could cause the leak in the SSL scenario. Basically
I add all the created sslEngines to a WeakHashMap.

AtomicInteger counter = new AtomicInteger();
Map<SSLEngine, Integer> sslMap = new WeakHashMap<SSLEngine, Integer>();

public SSLEngine createSSLEngine()

{ SSLEngine engine = sslContext.createSSLEngine(); sslMap.put(engine, counter.incrementAndGet()); return engine; }

the OutOfMemory error never occurred again.

The corresponding JVM issue was created:
https://jdk6.dev.java.net/issues/show_bug.cgi?id=23

Comment by nphilipp [ 10/Sep/08 ]

This issue wasn't resolved.

After much further investigation, it appears that simply by commenting out the
sunpkcs11 provider in the java.security file, the memory growth doesn't happen
anymore.

So this is a problem that will affect all users of Glassfish using SSL in a high
performance / high throughput environment. Since this provider is the default
provider for JDK 1.5 and 1.6 this will most likely show up.

Proper action should be taken to address this in the Glassfish container so
customers won't be impacted. I am re-opening this bug hoping that this will be
recognized as a high priority item. The OpenSSO project would be eager to
support Glassfish as its container, but this issue is too serious for us to ignore.

See follow up comments for more information.

Thanks,
N.

Comment by nphilipp [ 10/Sep/08 ]

Created an attachment (id=1813)
java.security file after removing the sun.security.pkcs11.SunPKCS11 provider

Comment by nphilipp [ 10/Sep/08 ]

When the sun.security.pkcs11.SunPKCS11 provider is removed from the
java.security file, the test case (GET of index.html over HTTPS) has been run
for at least 15 minutes with very minimal memory increase (see prstat output
below). Prior to commenting out the provider, the process would reach the 32 bit
max process size in less than 5 minutes (over 3Gb).

No SunPKCS11 provider :
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
27873 root 515M 279M sleep 59 0 0:01:26 0.2% java/164
27873 root 539M 500M cpu6 0 0 0:57:47 60% java/193
27873 root 539M 500M cpu18 10 0 1:06:04 62% java/193
27873 root 539M 536M cpu8 0 0 2:12:57 47% java/193
27873 root 539M 536M cpu9 59 0 2:52:45 48% java/196
27873 root 539M 536M cpu12 12 0 3:35:39 36% java/193
27873 root 539M 536M sleep 59 0 3:57:59 15% java/193
27873 root 539M 536M sleep 59 0 3:57:59 0.0% java/193

Now throughput without this provider is not as good and very erratic.

With SunPKCS11 provider :
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
27853 root 517M 282M sleep 59 0 0:01:28 0.0% java/161
27853 root 883M 880M cpu13 50 0 0:09:01 37% java/193 (after
about 30sec)
27853 root 1343M 1338M cpu27 30 0 0:17:31 42% java/193 (after
about 1min)
27853 root 1898M 1894M cpu0 0 0 0:26:44 36% java/193 (after
about 1:30 min)
27853 root 2460M 2456M cpu20 39 0 0:35:32 29% java/195 (after
about 3min)

I stopped the test since this is a clear enough example of the memory consumption.

Comment by oleksiys [ 11/Sep/08 ]

Looks like this is related to the security.
Forwarding to Kumar...

Comment by kumarjayanti [ 11/Sep/08 ]

Hi philipp,

Would you kindly run the same test with GF V2 :

https://glassfish.dev.java.net/downloads/v2ur2-b04.html

with the sun.security.pkcs11.SunPKCS11 provider present in your java.security
file and let me know if you are seeing the same problem with GF V2 or not.

From the messages exchanged so far on this issue, it does appear it occurs with
V2.1 as well, but i want to confirm if that is true.

Thanks.

Comment by nphilipp [ 11/Sep/08 ]

Yes, the problem occurs with v2ur-b04. This issue was initially reported on that
build (v2ur2-b04) actually. We upgraded to 2.1 build40 only after jfarcand asked
us to.

Thanks,
N.

Comment by kumarjayanti [ 19/Sep/08 ]

created CR P2 : 6750401 on JAVA

Comment by harpreet [ 20/Oct/08 ]

Please scrub issue and see if it is critical to v2.1.

Comment by kumarjayanti [ 03/Nov/08 ]

adding status whiteboard tag : as911-na

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumarjayanti [ 13/Apr/11 ]

The JDK bug 6750401 is fixed in JDK 7.





[GLASSFISH-9289] SecurityContext return PrincipalImpl for custom login and realm Created: 27/Aug/09  Updated: 25/Apr/14

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

Type: New Feature Priority: Minor
Reporter: maisonneuve_michel Assignee: JeffTancill
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: 9,289

 Description   

Hello,
I write custom login and realm for add attributes to Principal.
I override commit() in my login class and call getSubject() for change
PrincipalImpl object with my custom Principal.

When server process to login, the constructor
SecurityContext(String userName, Subject subject, String realm)
set the initiator with new PrincipalImpl(userName)
this.initiator = PrincipalGroupFactory.getPrincipalInstance(userName, realm);

after SessionContext return this PrincipalImpl when call getCallerPrincipal().

I've redirect this constructor on SecurityContext(Subject subject) and modify my
login module for add new DistinguishedPrincipalCredential(Principal prin) to
subject.getPublicCredentials().
Now SessionContext return my custom Principal.

Please reply me if it's good method and if you can modify this for futur version.
Thanks.



 Comments   
Comment by kumarjayanti [ 28/Aug/09 ]

Will take a look. We have been discussing about this issue recently.

Comment by kumarjayanti [ 03/Sep/09 ]

Will consider this feature for V3.1

Comment by maisonneuve_michel [ 04/Sep/09 ]

Thanks

Comment by kumarjayanti [ 13/Apr/11 ]

Marking it for 4.0





[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-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-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-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-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-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-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-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-16038] Don't send port 443 on HTTPS redirect Created: 17/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: Minor
Reporter: ryanitus Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

RHEL 4



 Description   

When the redirect port for an http listener is set to 443 and security is enabled, the Location provided in the HTTP redirect response headers is given as https://<server>:443/.

This causes the address to display in Safari as https://<server>:443/ rather than https://<server>/. This can cause confusion for users. Other browsers do not display the 443, but Safari does.

On the latest version of Apache Tomcat, the same behavior is not true. Please update the web container of glassfish to not send port 443 on https redirects.

Should be a simple if condition check to see if redirect port is standard 443 or not.



 Comments   
Comment by ryanitus [ 17/Feb/11 ]

I pulled a view of the 3.1 code (not sure if it's the right/latest one or not).

I found this file: ./3.1/web/web-core/src/main/java/org/apache/catalina/realm/RealmBase.java
It seems to correspond to the same file from tomcat. It does have the condition check.

This file also does a redirect to https, but does not have the condition check: ./3.1/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java





[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-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-16461] Changing Digest Algorithm with an existing security (authentication) realm is not possible. Created: 26/Apr/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: Minor
Reporter: myfear Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 3.1 (build 43)
Name of the Operating System: Windows 7
Binary Architecture name of the Operating System: amd64, Version: 6.1
JRE name: Java HotSpot(TM) 64-Bit Server VM Vendor: Sun Microsystems Inc. Version: 19.1-b02



 Description   

You can not change a Digest Algorithm with an existing security (authentication) realm.

Steps to reproduce:
1) Create new Realm with the Admin-GUI

<auth-realm name="TestJDBCRealm" classname="com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm">
<property name="user-name-column" value="usr"></property>
<property name="assign-groups" value="User"></property>
<property name="password-column" value="pwd"></property>
<property name="group-name-column" value="group"></property>
<property name="group-table" value="groups"></property>
<property name="user-table" value="usr"></property>
<property name="datasource-jndi" value="jdbc/sample"></property>
<property name="jaas-context" value="jdbcRealm"></property>
</auth-realm>

"click save"

2) edit realm and enter "MD5" => everything works

3) reload admin - UI (Realm now also in the left hand tree)
4) edit realm and enter "DES" => New value is NOT saved.



 Comments   
Comment by Tom Mueller [ 27/Apr/11 ]

There appears to be two problems here.

1. On Windows only, an attempt to save the value "DES" for the digest-algorithm produces a bean validation error. From the command line, it looks like this:

C:\test>3.1\glassfish3\bin\asadmin set configs.config.server-config.security-ser
vice.auth-realm.testrealm.property.digest-algorithm=DES
remote failure: Could not change the attributes: Constraints for this AuthRealm
configuration have been violated: on property [ ] violation reason [ jaas-conte
xt, datasource-jndi, user-table, group-table, user-name-column, password-column,
group-name-column and digest-algorithm properties need to be specified. Digest-
algorithm needs to be: 'none' or other JDK supported algorithms such as MD5 or S
HA ]
Constraints for this AuthRealm configuration have been violated: on property [
] violation reason [ jaas-context, datasource-jndi, user-table, group-table, use
r-name-column, password-column, group-name-column and digest-algorithm propertie
s need to be specified. Digest-algorithm needs to be: 'none' or other JDK suppor
ted algorithms such as MD5 or SHA ]
Command set failed.

However, if the digest-algorithm is set to SHA and then back to DES, then it works (either from the command line or the console). This happens on Windows but not on Linux, so there is something platform specific here. Also, after the algorithm is set to SHA, then the algorithm can be set to any value, such as "asdf".

So there is something wrong with the validation logic for the auth realm config bean.

2. The second problem is that the admin GUI is not reporting the failure of the set command due to the bean validation error. So it looks like the console just fails to save the value even though it reported that the values were saved. After fixing the auth-realm validation error, please assign this bug to the admin-gui category so that this second problem can be fixed.

A work-around for this issue is to set the digest-algorthm to SHA first, and then set it to the desired value.





[GLASSFISH-16463] Specifying a Security Algorithm which is not a MessageDigest Type leads to misleading error message (JDBCRealm) Created: 26/Apr/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: Minor
Reporter: myfear Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 3.1 (build 43)
Name of the Operating System: Windows 7
Binary Architecture name of the Operating System: amd64, Version: 6.1
JRE name: Java HotSpot(TM) 64-Bit Server VM Vendor: Sun Microsystems Inc. Version: 19.1-b02



 Description   

Specifying a Security Algorithm which is not a MessageDigest Type leads to misleading error message.

Steps to reproduce:
1) Create new Realm with the Admin-GUI

<auth-realm name="TestJDBCRealm" classname="com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm">
<property name="user-name-column" value="usr"></property>
<property name="assign-groups" value="User"></property>
<property name="password-column" value="pwd"></property>
<property name="group-name-column" value="group"></property>
<property name="group-table" value="groups"></property>
<property name="user-table" value="usr"></property>
<property name="datasource-jndi" value="jdbc/sample"></property>
<property name="jaas-context" value="jdbcRealm"></property>
<property name="digest-algorithm" value="MD5withRSA"></property>
</auth-realm>

"click save"

Leads to the following error:

Creation of Authrealm TestJDBCRealm failed. com.sun.enterprise.security.auth.realm.BadRealmException: No local string defined

"SEVERE: RestResponse.getResponse() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/configs/config/server-config/security-service/auth-realm'; attrs = '

{classname=com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm, name=TestJDBCRealm, target=server-config, property=jaas-context=jdbcRealm:datasource-jndi=jdbc/sample:user-table=usr:user-name-column=ACCOUNT:password-column=PASSWORD:group-table=groups:group-name-column=GROUPS:digest-algorithm=MD5withRSA:assign-groups=User:}

'"






[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-16861] hard-coded message with no message ID Created: 14/Jun/11  Updated: 25/Apr/14

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

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

WinXP, GF 3.2 latest workspace



 Description   

Below java file contains hard-coded log messages:

http://wikis.sun.com/display/glassfish/GlassFishV3LoggingMessageFormat

security\webintegration\src\main\java\com\sun\web\security\RealmAdapter.java

There are multiple messages hard-coded instead of using LogStrings.properties file for localization.

One particularly that stands out is the following, as it is logged during QL.

[#|2011-06-15T11:19:32.217+1000|WARNING|glassfish3.2|javax.enterprise.system.container.web.com.sun.web.security|_ThreadID=30;_ThreadName=Thread-1;|Exception
com.sun.enterprise.security.auth.login.common.LoginException: Login failed: Failed file login for j2ee.
at com.sun.enterprise.security.auth.login.LoginContextDriver.doPasswordLogin(LoginContextDriver.java:394)

As a proper message is logged just before it, the stacktrace can simply be logged without a message:

_logger.log(Level.WARNING,"web.login.failed", le.toString());
_logger.log(Level.WARNING, null , le);






[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-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-17225] Better Default Audit Module Created: 23/Aug/11  Updated: 25/Apr/14

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

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

Any



 Description   

The current default Audit Module should be replaced with a better one, and the current log message to server.log for failed login attempts should be removed.

A. Currently, a failed loging attempt (I'm using a jdbc realm) causes a WARNING message to server.log, complete with a longish and irrelevant traceback. That spams server.log so that it's hard to find any real server problems. A failed login attempt is a pretty normal event and not a server problem at all, and should therefore be logged somewhere else. For example in an audit.log file in the same directory as server.log (and rotated in the same way).

B. The current Default Audit Module can be turned on to show failed login attempts. However, it too writes to server.log, where no such messages for "normal operations" should be writtten. What is even worse, turning it on produces lots and lots of totally irrelevant and uninteresting messages. So it is not helpful at all.

Two things should be done:

1. Remove the log message to server.log. It is currently changed in 3.1.2 to INFO level, so at least we are spared the voluminous traceback. (Thanks, Kumar!) But there should be no such messages in server.log at all, so please change the level to DEBUG or whatever.

2. Create and supply a Better Default Audit Module that writes to a separate log file, say audit.log . It should, by default, be activated out-of-the-box, and only log failed login attempts. (Timestamp, User name, IP address). Nothing more, nothing less. It should probably have settable properties for logging other things that might be of interest, but those should by default be set to 'false'.

This will also be of great help to sysadmins, who now easily can see login attacks.

For a previous discussion on this subject, see also http://www.java.net/forum/topic/glassfish/glassfish/login-failures-spams-serverlog .



 Comments   
Comment by tmpsa [ 27/Jan/14 ]

I would like to add some more suggestions.

1. It would probably be nice if the log entry had some extra information at login failures. Currently (version 3.1.2.2) the log message (in server.log) is "Login failed: Security Exception". I think it would be useful to add the source IP address; for example "Login failed: Security Exception, IP 111.222.333.444"

2. Random salt for each password hash (Is there a separate bug for this? I can't find any).

3. There should be a way to configure lockout, based on intrusion attempts. Each consecutive failed login attempt from the same IP address to the same user should result in:
a. increasing delay before responding (for example 10% longer each time)
b. lockout after N failed attempts

Items 2 and 3 would require some additional columns in a JDBC realm, of course.

There may be more wisdom on this particular subject that I am not aware of, my apologies if I have missed something. In any case, the security features in Glassfish need to be of "industrial strength". Hope this helps.





[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-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-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-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-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-18269] [intermittent] SSLHandshakeException message on deploy; "PortUnification exception. java.lang.NoClassDefFoundError: javax/crypto/SunJCE_b" in the instance log Created: 30/Jan/12  Updated: 25/Apr/14

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

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

Attachments: Zip Archive all-instances-jstacks.zip     Zip Archive first-test.zip     Zip Archive second-test.zip    
Tags: 312_qa, 3_1_2-exclude

 Description   

GF Build 19
Setup: 10 instance cluster
Platform: OEL6
JDK: JRockit

This issue occurred on the first test (deploy) that was done after a fresh install, creation of the Cluster and Enabling of Instance Access Logs.

All application deploys fail and the cluster becomes unusable.

[Note: It was found while creating a setup for debugging issue 18211]

Output from asadmin deploy:
****
INFO: Command Executed at agent machine agent1: /space/gf-ha/glassfish3/bin/asadmin --user admin deploy --availabilityenabled=true --force=true --target st-cluster /space/gf-ha/agent-repository/glassfish-samples/clusterjsp.ear
Output : Application deployed with name clusterjsp.
WARNING: Command _deploy did not complete successfully on server instance instance102: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
Command deploy completed with warnings.

The second test showed the following output from asadmin deploy:
*****
INFO: Command Executed at agent machine agent1: /space/gf-ha/glassfish3/bin/asadmin --user admin deploy --availabilityenabled=true --force=true --target st-cluster /space/gf-ha/agent-repository/glassfish-samples/clusterjsp.ear
Output : Command deploy failed.

Jan 29, 2012 4:22:29 PM com.sun.dft.glassfish.utils.Utility logCommandOutput
SEVERE: remote failure: Error occurred during deployment: Keys cannot be duplicate. Old value of this key property, nullwill be retained. Please see server.log for more details.
clusterjsp disabled failed
Failure: Command disable failed on server instance instance102: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
*****

instance102 has the following message on deploy:
******
[#|2012-01-29T16:19:00.226-0800|WARNING|glassfish3.1.2|grizzly|_ThreadID=22;_ThreadName=Thread-4;|GRIZZLY0059: PortUnification exception.
java.lang.NoClassDefFoundError: javax/crypto/SunJCE_b
at javax.crypto.Cipher.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getCipher(JsseJce.java:180)
at com.sun.net.ssl.internal.ssl.CipherBox.<init>(CipherBox.java:85)
at com.sun.net.ssl.internal.ssl.CipherBox.newCipherBox(CipherBox.java:119)
at com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.newCipher(CipherSuite.java:369)
at com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.isAvailable(CipherSuite.java:407)
at com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.isAvailable(CipherSuite.java:386)
at com.sun.net.ssl.internal.ssl.CipherSuite.isAvailable(CipherSuite.java:144)
at com.sun.net.ssl.internal.ssl.CipherSuiteList.buildAvailableCache(CipherSuiteList.java:215)
at com.sun.net.ssl.internal.ssl.CipherSuiteList.getDefault(CipherSuiteList.java:239)
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.initServer(SSLServerSocketImpl.java:130)
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.<init>(SSLServerSocketImpl.java:118)
at com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:52)
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:443)
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:183)
at com.sun.grizzly.config.SSLConfigHolder.initializeSSL(SSLConfigHolder.java:361)
at com.sun.grizzly.config.SSLConfigHolder.configureSSL(SSLConfigHolder.java:239)
at com.sun.grizzly.config.HttpProtocolFinder.configureSSLIfNeeded(HttpProtocolFinder.java:248)
at com.sun.grizzly.config.HttpProtocolFinder.find(HttpProtocolFinder.java:105)
at com.sun.grizzly.config.ConfigProtocolFinderWrapper.find(ConfigProtocolFinderWrapper.java:72)
at com.sun.grizzly.portunif.PUReadFilter.findProtocol(PUReadFilter.java:522)
at com.sun.grizzly.portunif.PUReadFilter.execute(PUReadFilter.java:193)
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)

#]
******

Logs Attached:

  • logs from 2 tests
    Note: The client logs are in ant.output. Other logs are under <test-name>/logs/
  • JStacks of all the instances and the domain.


 Comments   
Comment by Tom Mueller [ 30/Jan/12 ]

Is this problem related to Grizzly?

Comment by oleksiys [ 30/Jan/12 ]

doesn't look so, IMO it's something security or/and jdk related.

Comment by varunrupela [ 30/Jan/12 ]

Marked the issue as intermittent as recreating the cluster and running the tests again did not show the problem.

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

As discussed in Bug Swat this has only been seen once and that case was on JRockit. QA will continue to monitor further tests. At this point this is not considered a 3.1.2 stopper.

Comment by varunrupela [ 02/Feb/12 ]

The same set of machines and environment has been used a number of times (after this error was observed) to re-install GF and re-create the cluster setup. The exact error in the log has not yet been observed.

However, we did observe an output error message with "SSLHandshakeException" on running asadmin commands after an instance showed an OutOfMemory error (while investigating another bug).





[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-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-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-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-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-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-18669] CONSIDER ALLOWING A CHOICE BETWEEN USING THE JKS AND JCEKS KEYSTORE FORMATS Created: 01/May/12  Updated: 24/Apr/14

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

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

Generic



 Description   

Java supports two formats for its keystores, JKS and JCEKS.

The JCEKS differs from JKS by using stronger encryption standards to protect its contents - something that is highly desirable in many environments, such as the financial sector amongst others.

Unfortunately while GlassFish Server does use JCEKS for its master password file, the use of JKS is hardcoded in a number of classes. It should be possible to remove this hardcoding and let the customer choose which store-type to use when the domain is created (defaulting to the current JKS).



 Comments   
Comment by kumarjayanti [ 01/May/12 ]

if you have actually greped the code then please list out the places where this is hardcoded.

I guess some of the admin code has it hardcoded. But otherwise the core security code does not hardcode it. It uses the javax.net.ssl.keystoreType jvm option to determine the type of server keystore. For example it should be possible to use PKCS12 stores with glassfish for SSL.

Comment by tecknobabble [ 01/May/12 ]

From the 3.1.2 source. These are the obvious places, ignoring any false hits from file suffixes such as ".jks" and only looking at java source and not any other files.

security/core/src/main/java/com/sun/enterprise/security/KeyTool.java
127 // Get the keystores from the engines.
128 pkcs12KeyStore = KeyStore.getInstance ("PKCS12", provider);
129 jksKeyStore = KeyStore.getInstance ("JKS");

admin/cli/src/main/java/com/sun/enterprise/admin/cli/LocalServerCommand.java
192 protected boolean loadAndVerifyKeystore(File jks,String mpv) {
193 FileInputStream fis = null;
194 try {
195 fis = new FileInputStream(jks);
196 KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType()); <== Typically "JKS" unless overridden in security properties
197 ks.load(fis, mpv.toCharArray());

web/web-glue/src/main/java/com/sun/enterprise/web/connector/coyote/PECoyoteConnector.java
070 private static final String DEFAULT_KEYSTORE_TYPE = "JKS";
071 private static final String DEFAULT_TRUSTSTORE_TYPE = "JKS";
...
1313 String prop = System.getProperty("javax.net.ssl.keyStore");
1314 String keyStoreType = System.getProperty("javax.net.ssl.keyStoreType",DEFAULT_KEYSTORE_TYPE);
1315 if (prop != null)

{ 1316 // PE 1317 setKeystoreFile(prop); 1318 setKeystoreType(keyStoreType); 1319 }

...
1349 prop = System.getProperty("javax.net.ssl.trustStore");
1350 if (prop != null)

{ 1351 // PE 1352 setTruststore(prop); 1353 setTruststoreType(DEFAULT_TRUSTSTORE_TYPE); 1354 }

common/common-util/src/main/java/com/sun/enterprise/security/store/AsadminTruststore.java
102 private void init(File keyfile, final char[] password)
103 throws CertificateException, IOException,
104 KeyStoreException, NoSuchAlgorithmException
105 {
106 _keyFile = keyfile;
107 _keyStore = KeyStore.getInstance("JKS");
108 _password = password;

admin/util/src/main/java/com/sun/enterprise/admin/util/SecureAdminClientManager.java
327 private KeyStore instanceCertOnlyKS(final Certificate instanceCert) throws KeyStoreException

{ 328 final KeyStore ks = KeyStore.getInstance("JKS"); 329 ks.setCertificateEntry(instanceAlias, instanceCert); 330 return ks; 331 }

common/common-util/src/main/java/com/sun/enterprise/security/store/AsadminSecurityUtil.java
213 private KeyStore openKeystore(final char[] candidateMasterPassword)
214 throws KeyStoreException, IOException, NoSuchAlgorithmException, CertificateException {
215 final KeyStore permanentKS = KeyStore.getInstance("JKS");

Comment by kumarjayanti [ 01/May/12 ]

KeyTool.java is dead code. Others that you have pointed out need to be looked at.

Thanks.

Comment by tecknobabble [ 01/May/12 ]

Thanks for assessing it so quickly.
The other point would be that you'd need a formal way of choosing the keystore type as part of the asadmin create-domain to avoid having to add the keystore.type to the jre/lib/security/java.security file, because if the JDK/JRE is shared then other applications might not work if the default was changed from JKS. This could then be overridden, for example, by specifying the keystore.Type=JCEKS amongst the other options that can be changed with the --domainproperties option.





[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-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-18993] RealmAdapter.createFailOveredPrincipal results in excepcion when LdapRealm is used Created: 11/Aug/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: 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.





[GLASSFISH-18996] More than maximum number of characters can be entered for create-file-user Created: 13/Aug/12  Updated: 24/Apr/14

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

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

Windows 7



 Description   

More than maximum number of characters can be entered in the UserID, Group List and Password for create-file-user on command or Admin console.

1.Open admin GUI. http://localhost:4848
2.Configurations > server-config > Security > Realms > file
3.Click Manage Users button.
4.In File Users, click New button.
5.Enter more than 255 characters in User ID, Group List and Password.
The description says "Name can be up to 255 characters, must contain only alphanumeric, underscore, dash, or dot characters."
6.Click OK button.
7.Check the new user. The user name is more than 255 characters.

Similarly, more than the maximum number of characters 255 can be entered for these parameters when create-file-user command is used.
1. asadmin> create-file-user
2. Enter the value for the username operand> Enter more than 255 characters
3. Enter the user password> Enter more than 255 characters
4. Check the new user.



 Comments   
Comment by tak09 [ 04/Jul/13 ]

maximum length for the group also needs checking.





[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-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-19349] Choosing SSL cipher suites in GlassFish admin GUI results in many "Unrecognized cipher" warnings in GlassFish log Created: 15/Nov/12  Updated: 24/Apr/14

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

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


 Description   

Using the web admin GUI I went into the configuration of http-listener-2 which has SSL enabled. I went to the SSL tab and clicked the "select all" button for all cipher suites EXCEPT the 40 bit and 56 bit ciphers, and then pressed save. My goal is to disable the 40 bit and 56 bit ciphers. I noticed the following in my GlassFish log. Note that I already have the unlimited strength JCE installed in my JDK:

INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.50 started in: 1ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_RC4_128_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_ECDSA_WITH_NULL_SHA
WARNING: WEB0309: Unrecognized cipher: TLS_ECDHE_RSA_WITH_NULL_SHA
INFO: Grizzly Framework 1.9.50 started in: 0ms - bound to [0.0.0.0:8181]
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_RC4_128_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDH_anon_WITH_AES_128_CBC_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_ECDSA_WITH_NULL_SHA].
WARNING: GRIZZLY0010: Unrecognized cipher [TLS_ECDHE_RSA_WITH_NULL_SHA].

Why did it offer cipher suites that are unrecognized in the first place? Which ones were actually used?






[GLASSFISH-19437] Open-source Az* implementations are incomplete - cannot get resource/action name Created: 13/Dec/12  Updated: 24/Apr/14

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

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


 Description   

The open-source implementations of the AzResource and AzAction interfaces simply extend AttributesImpl and thus provide no way to obtain the resource name or action name from the respective classes.

In fact, the interfaces themselves lack such methods.






[GLASSFISH-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-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-20336] ejb.security_preinvoke_exception for security devtests Created: 17/Apr/13  Updated: 24/Apr/14

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

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

security-devtests-trunk



 Description   

The security devtests mdb and timerStandalone have been disabled from the set of tests. These tests both fail for the same root cause:

java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

mdb test:

[2013-04-17T11:25:00.018-0700] [glassfish 4.0] [SEVERE] [ejb.security_preinvoke_exception] [javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1366223100018] [levelValue: 1000] [[
SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)
at org.glassfish.ejb.mdb.MessageBeanContainer.<init>(MessageBeanContainer.java:248)
at org.glassfish.ejb.mdb.MessageBeanContainerFactory.createContainer(MessageBeanContainerFactory.java:63)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

Comment by Craig Perez [ 17/Apr/13 ]

timeStandalone test:

[2013-04-17T11:29:06.808-0700] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=98 _ThreadName=Thread-3] [timeMillis: 1366223346808] [levelValue: 800] [[
In SfulEJB:hello()]]

[2013-04-17T11:29:06.819-0700] [glassfish 4.0] [SEVERE] [ejb.security_preinvoke_exception] [javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application] [tid: _ThreadID=98 _ThreadName=p: thread-pool-1; w: 2] [timeMillis: 1366223346819] [levelValue: 1000] [[
SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1628)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:456)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2516)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1906)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:204)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy267.hello(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
]]

Comment by bebbo [ 29/Jul/13 ]

suggested fix: add a null check and create an empty array if null.

if (groups == null)
  groups = new String[0];
return Collections.enumeration(Arrays.asList(groups));




[GLASSFISH-20337] security devtests jmac failure Created: 17/Apr/13  Updated: 24/Apr/14

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

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

security-devtests-trunk



 Description   

The security-jmac-httpservlet test in the jmac security devtests suite is failing and has been disabled.

The expected output includes an adjusted PrintWriter count that is not matching the golden files output.

Otherwise the general behavior and functional output looks correct.



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

From examining the test case, the MyHttpServletResponseWrapper.java only overrides the method write(char[] cbuf, int off, int len) and the test currently outputs a count of 0 vs 218 along with the blank lines that are not lining up 1-1 as previously.

Functionally the SAM is working but either the MyPrintWriter needs changes or the goldenfiles could be updated since the test will validate basic ServerAuthModule wrappering.

[webtest] Expected Output ****************************************
[webtest] Hello World from 196 HttpServlet AuthModule Test!
[webtest] <hr>
[webtest] Hello, shingwai123 from com.sun.s1asdev.security.jmac.httpservlet.HttpServletTestAuthModule
[webtest] PC = security-jmac-httpservlet-web/security-jmac-httpservlet-web
[webtest]
[webtest]
[webtest] <hr>
[webtest] Adjusted count: 218
[webtest]
[webtest] ********************************************************
[webtest] Actual Output ##########################################
[webtest] Hello World from 196 HttpServlet AuthModule Test!
[webtest] <hr>
[webtest] Hello, shingwai123 from com.sun.s1asdev.security.jmac.httpservlet.HttpServletTestAuthModule
[webtest] PC = security-jmac-httpservlet-web/security-jmac-httpservlet-web
[webtest]
[webtest] <hr>
[webtest]
[webtest] Adjusted count: 0





[GLASSFISH-20338] security devtests ciphertest failures Created: 17/Apr/13  Updated: 24/Apr/14

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

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

security-devtests-trunk



 Description   

Disabled tests for ciphers:

  • SSL_RSA_WITH_DES_CBC_SHA
  • SSL_RSA_EXPORT_WITH_RC4_40_MD5

Use of -Dsun.security.ssl.allowUnsafeRenegotiation=true no impact both server and client side






[GLASSFISH-20339] security devtests wss roles failures Created: 17/Apr/13  Updated: 24/Apr/14

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

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

security-devtests-trunk



 Description   

Disabled the roles tests for security devtests wss suite.

[exec] Apr 12, 2013 4:41:47 PM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[exec] WARNING: ACC013: The -password option is deprecated and will likely be removed in a future release. Please use -passwordfile or let the app client container prompt for the username and/or password if they are needed to access a remote resource.
[exec] com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: java.lang.Exception: Client not authorized for invocation of public java.lang.String com.sun.s1asdev.security.wss.roles.ejbws.HelloEjb.hello(java.lang.String) Please see the server log to find more detail regarding exact cause of the failure.



 Comments   
Comment by Craig Perez [ 17/Apr/13 ]

Additionally the roles2, ssl & sslclientcert where previously disabled

  • roles2 has same/similar test failure
  • ssl and sslclientcert have build failures on wsimport looking for WSDL at HTTPS URL




[GLASSFISH-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-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-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-20588] Principal Classes have serious problems Created: 29/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: Byron Nevins Assignee: Craig Perez
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Ref: Joshua Bloch, Effective Java, 2nd edition, item #8
Mr. Bloch does an excellent job of describing precisely the problem in these classes:
(all in common-util)
common/common-util/src/main/java/org/glassfish/security/common/Role.java
common/common-util/src/main/java/org/glassfish/security/common/Group.java
common/common-util/src/main/java/org/glassfish/security/common/Principal.java
3 problems:
(1) These problems are the only low level FindBugs issues in all of common-util.
(2) The equals/hash methods are a mess. Look at the FB results for common-utils. Especially look at the way the base class equals() method chedcks to see if the other object is a Group. Note how it doesn't check if it is a Role (why?). This is quite brittle. The base class ought to know nothing about subclasses!
(3) Even though all three classes implement the Principal interface, the outside calling code does NOT use it. Instead, it uses PrincipalImpl. Why bother with an interface if it isn't used ? Should either use them as a class hierarchy OR as references to interfaces.
I attempted to fix this using Bloch's recommendation which is to use composition instead of inheritance. I.e. I made all three implement the interface directly. Then Role and Group stopped being subclasses. This failed because outside code is looking for PrincipalImpl objects - not Principal objects.
PrincipalImpl pi = new PrincipalImpl("foo");
Group g = new Group("foo");
Role r = new Role("foo");
pi.equals(r) --> true
r.equals(pi) --> false






[GLASSFISH-20589] AzResource URI Path encoding problems Created: 29/May/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: Tim Quinn
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Nucleus



 Description   

The CommandSecurityChecker is creating AzResource URI by URL encoding the URI Path with the following logical operation:

new URI(ADMIN_RESOURCE_SCHEME, URLEncoder.encode(resourceName, RESOURCE_NAME_URL_ENCODING), null)

As an example, when using input resourceName as "/users/user/admin" this approach results in the following output from the constructed URI object:

URI.toString() 'admin:%252Fusers%252Fuser%252Fadmin'
URI.toASCIIString() 'admin:%252Fusers%252Fuser%252Fadmin'
uri.getAuthority() 'null'
uri.getPath() 'null'

thus yielding the AzResource based on the URI object unable to obtain proper the proper Path information.



 Comments   
Comment by Craig Perez [ 29/May/13 ]

Without URL encoding the following more expected output results:

URI.toString() 'admin:/users/user/admin'
URI.toASCIIString() 'admin:/users/user/admin'
uri.getAuthority() 'null'
uri.getPath() '/users/user/admin'





[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-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-21035] FileRealm.getGroupNames throws NPE when user does not exist. Created: 09/Apr/14  Updated: 24/Apr/14

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

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

JDK 1.6.0_45 on Windows and RHEL.



 Description   

Regarding com.sun.enterprise.security.auth.realm.file.FileRealm implementation.

The following code fragment will result in a NullPointerException being thrown from a servlet's service method when user "FOO" does not exist:

FileRealm realm = new FileRealm("keyfile");
realm.getGroupNames("FOO");

Method signature for getGroupNames indicates it throws NoSuchUserException but this is not the case.

The sequence:

FileRealm realm = new FileRealm("keyfile");
realm.getUser("FOO");

does throw NoSuchUserException.






[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-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-2864] Support InitialContext Security Credentials and Prinicpals Created: 18/Apr/07  Updated: 22/Nov/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 2,864

 Description   

Many users are used to provide login information for standalone clients this way
on other appservers (like JBoss):

Properties props = new Properties();
props.setProperty(InitialContext.SECURITY_PRINCIPAL, "x");
props.setProperty(InitialContext.SECURITY_CREDENTIALS, "y");
InitialContext ic = new InitialContext(props);

On GlassFish they have to use the proprietary ProgrammaticLogin class which
makes code non portable and causes questions on migrations to glassfish.

Therefore this RFE asks for support for InitialContext principal/credential
properties support like in the snippet above.



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

reassign

Comment by schaarsc [ 09/Jun/08 ]
      • Issue 2864 has been confirmed by votes. ***
Comment by barz26 [ 02/Sep/08 ]

Target version was wrong - changed to 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.

Comment by pmaloney [ 22/Nov/13 ]

Is anyone looking at this? If not, can someone point me in the right direction for coding this feature myself? Thanks, Patrick





[GLASSFISH-1577] JDBCRealm should allow for salting hashed passwords Created: 24/Nov/06  Updated: 28/Aug/13

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

Type: Improvement Priority: Major
Reporter: ananner 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,577

 Description   

The JDBCRealm allows for the hashing of passwords, but it does not currently
allow for the passwords to be salted before they are hashed. There should be a
mechanism that allows for salted, hashed passwords.

Weblogic 9.2 uses a hidden salt that is added to hashed passwords. I believe
that the JBoss mechanism is better: it uses a callback to a custom class (that
can be a custom class created by the user), and this custom callback is
responsible for adding a salt to the password before it is hashed.



 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.

Comment by tmpsa [ 28/Aug/13 ]

With the steady flow of stories about stolen password files (even at reputable service providers), this issue is becoming increasingly critical.

Salted password hashes has been standard tech for a very long time. Glassfish should provide this trivial functionality out-of-the-box.

Please upgrade the priority and assign a target version for this issue.





[GLASSFISH-17134] after update to 3.1.11 (?) jsf web app causes server shutdown Created: 29/Jul/11  Updated: 09/May/13

Status: In Progress
Project: glassfish
Component/s: security
Affects Version/s: 3.1.1
Fix Version/s: not determined

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

windows xp


Attachments: Text File Copy of server.txt    

 Description   

Launching GlassFish on Felix platform
Jul 29, 2011 11:48:52 AM com.sun.enterprise.server.logging.LogManagerService postConstruct
WARNING: Record begin marker is not a proper value so using default.
Jul 29, 2011 11:48:52 AM com.sun.enterprise.server.logging.LogManagerService postConstruct
WARNING: Record end marker is not a proper value so using default.
Jul 29, 2011 11:48:52 AM com.sun.enterprise.server.logging.LogManagerService postConstruct
WARNING: Log Format field separator is not a character so using default.
Jul 29, 2011 11:48:52 AM com.sun.enterprise.server.logging.LogManagerService postConstruct
WARNING: Date Format specified is wrong so using default.
INFO: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
INFO: The Admin Console is already installed, but not yet loaded.
INFO: Grizzly Framework 1.9.36 started in: 550ms - bound to [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.36 started in: 701ms - bound to [0.0.0.0:8080]
INFO: Grizzly Framework 1.9.36 started in: 540ms - bound to [0.0.0.0:4848]
INFO: Grizzly Framework 1.9.36 started in: 470ms - bound to [0.0.0.0:7676]
INFO: Grizzly Framework 1.9.36 started in: 500ms - bound to [0.0.0.0:3700]
INFO: SEC1002: Security Manager is OFF.
INFO: SEC1010: Entering Security Startup Service
INFO: SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
INFO: SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
INFO: SEC1011: Security Service(s) Started Successfully
INFO: WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:8080]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [admin-listener] on host/port [0.0.0.0:4848]
INFO: WEB0171: Created virtual server [server]
INFO: WEB0171: Created virtual server [__asadmin]
INFO: WEB0172: Virtual server [server] loaded default web module []
INFO: Hibernate Validator 4.1.0.Final
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
FINEST: Begin predeploying Persistence Unit WebWormSalesPU; session file:/K:/Java code/WebWormSales/build/web/WEB-INF/classes/_WebWormSalesPU; state Initial; factoryCount 0
FINEST: property=eclipselink.orm.throw.exceptions; default value=true
FINEST: property=eclipselink.weaving.changetracking; default value=true
FINEST: property=eclipselink.weaving.lazy; default value=true
FINEST: property=eclipselink.weaving.eager; default value=false
FINEST: property=eclipselink.weaving.fetchgroups; default value=true
FINEST: property=eclipselink.weaving.internal; default value=true
FINEST: property=eclipselink.multitenant.tenants-share-cache; default value=false
FINEST: property=eclipselink.metadata-source; default value=null
FINEST: property=eclipselink.jpa.uppercase-column-names; default value=false
FINER: Searching for default mapping file in file:/K:/Java%20code/WebWormSales/build/web/WEB-INF/classes/
FINER: Searching for default mapping file in file:/K:/Java%20code/WebWormSales/build/web/WEB-INF/classes/
CONFIG: The access type for the persistent class [class entity.Salesrecords] is set to [FIELD].
CONFIG: The access type for the persistent class [class entity.Wormgrowers] is set to [FIELD].
CONFIG: The access type for the persistent class [class entity.Message] is set to [FIELD].
CONFIG: The access type for the persistent class [class entity.Sequence] is set to [FIELD].
CONFIG: The access type for the persistent class [class entity.SalesrecordsPK] is set to [FIELD].
CONFIG: The alias name for the entity class [class entity.Salesrecords] is being defaulted to: Salesrecords.
CONFIG: The alias name for the entity class [class entity.Wormgrowers] is being defaulted to: Wormgrowers.
CONFIG: The alias name for the entity class [class entity.Message] is being defaulted to: Message.
CONFIG: The alias name for the entity class [class entity.Sequence] is being defaulted to: Sequence.
FINER: Class [entity.SalesrecordsPK] registered to be processed by weaver.
FINER: Class [entity.Salesrecords] registered to be processed by weaver.
FINER: Class [entity.Wormgrowers] registered to be processed by weaver.
FINER: Class [entity.Message] registered to be processed by weaver.
FINER: Class [entity.Sequence] registered to be processed by weaver.
FINEST: End predeploying Persistence Unit WebWormSalesPU; session file:/K:/Java code/WebWormSales/build/web/WEB-INF/classes/_WebWormSalesPU; state Predeployed; factoryCount 1
FINEST: Begin weaver class transformer processing class [entity/Salesrecords].
FINEST: Weaved persistence (PersistenceEntity) [entity/Salesrecords].
FINEST: Weaved change tracking (ChangeTracker) [entity/Salesrecords].
FINEST: Weaved fetch groups (FetchGroupTracker) [entity/Salesrecords].
FINEST: End weaver class transformer processing class [entity/Salesrecords].
INFO: Portable JNDI names for EJB SalesrecordsFacade : [java:global/WebWormSales/SalesrecordsFacade!session.SalesrecordsFacade, java:global/WebWormSales/SalesrecordsFacade]
FINEST: Begin weaver class transformer processing class [entity/Wormgrowers].
FINEST: Weaved persistence (PersistenceEntity) [entity/Wormgrowers].
FINEST: Weaved change tracking (ChangeTracker) [entity/Wormgrowers].
FINEST: Weaved fetch groups (FetchGroupTracker) [entity/Wormgrowers].
FINEST: End weaver class transformer processing class [entity/Wormgrowers].
INFO: Portable JNDI names for EJB WormgrowersFacade : [java:global/WebWormSales/WormgrowersFacade!session.WormgrowersFacade, java:global/WebWormSales/WormgrowersFacade]
FINEST: Begin weaver class transformer processing class [entity/Sequence].
FINEST: Weaved persistence (PersistenceEntity) [entity/Sequence].
FINEST: Weaved change tracking (ChangeTracker) [entity/Sequence].
FINEST: Weaved fetch groups (FetchGroupTracker) [entity/Sequence].
FINEST: End weaver class transformer processing class [entity/Sequence].
INFO: Portable JNDI names for EJB SequenceFacade : [java:global/WebWormSales/SequenceFacade, java:global/WebWormSales/SequenceFacade!session.SequenceFacade]
FINEST: Begin weaver class transformer processing class [entity/Message].
FINEST: Weaved persistence (PersistenceEntity) [entity/Message].
FINEST: Weaved change tracking (ChangeTracker) [entity/Message].
FINEST: Weaved fetch groups (FetchGroupTracker) [entity/Message].
FINEST: End weaver class transformer processing class [entity/Message].
INFO: Portable JNDI names for EJB MessageFacade : [java:global/WebWormSales/MessageFacade!session.MessageFacade, java:global/WebWormSales/MessageFacade]
INFO: Initializing Mojarra 2.1.3 (FCS b02) for context '/WebWormSales'
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: Monitoring jndi:/server/WebWormSales/WEB-INF/faces-config.xml for modifications
INFO: WEB0671: Loading application [WebWormSales] at [/WebWormSales]
INFO: CORE10010: Loading application WebWormSales done in 37,754 ms
INFO: Oracle GlassFish Server 3.1.1 (12) startup time : Felix (3,945ms), startup services(40,869ms), total(44,814ms)
INFO: JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://PSO-ecarter:8686/jndi/rmi://PSO-ecarter:8686/jmxrmi
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:8080]
INFO: Grizzly Framework 1.9.36 started in: 10ms - bound to [0.0.0.0:8080]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.36 started in: 10ms - bound to [0.0.0.0:8181]
INFO: ____________________________
Welcome to Apache Felix Gogo

INFO: g!
INFO: gosh: stopping framework
INFO: Stopping com.sun.enterprise.v3.server.AppServerStartup@e25f8a
FINEST: Begin undeploying Persistence Unit WebWormSalesPU; session file:/K:/Java code/WebWormSales/build/web/WEB-INF/classes/_WebWormSalesPU; state Predeployed; factoryCount 1
INFO: RAR7094: __ds_jdbc_ra shutdown successful.
FINEST: End undeploying Persistence Unit WebWormSalesPU; session file:/K:/Java code/WebWormSales/build/web/WEB-INF/classes/_WebWormSalesPU; state Undeployed; factoryCount 0
INFO: JMXStartupService: Stopped JMXConnectorServer: null
INFO: JMXStartupService and JMXConnectors have been shut down.
INFO: Shutdown procedure finished
INFO: [Thread[GlassFish Kernel Main Thread,5,main]] exiting
Completed shutdown of Log manager service
Error stopping framework: org.glassfish.embeddable.GlassFishException: org.osgi.framework.BundleException: Bundle org.apache.felix.framework [0] cannot be stopped since it is already stopping.
org.glassfish.embeddable.GlassFishException: org.osgi.framework.BundleException: Bundle org.apache.felix.framework [0] cannot be stopped since it is already stopping.
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.shutdown(OSGiGlassFishRuntime.java:81)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:203)
Caused by: org.osgi.framework.BundleException: Bundle org.apache.felix.framework [0] cannot be stopped since it is already stopping.
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2139)
at org.apache.felix.framework.Felix.stop(Felix.java:869)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.shutdown(OSGiGlassFishRuntime.java:76)
... 1 more



 Comments   
Comment by Ed Burns [ 19/Aug/11 ]

It seems your are running stock GlassFish 3.1:

Running GlassFish Version: Oracle GlassFish Server 3.1 (build 43)

with Mojarra 2.1:

Initializing Mojarra 2.1.0 (FCS 2.1.0-b11)

And later in the log file I see:

Oracle GlassFish Server 3.1.1 (build 12)

[...]

Initializing Mojarra 2.1.3 (FCS b02)

With GlassFish 3.1 I see the server shutdown being initiated soon after Mojarra initialized.

With GlassFish 3.1.1 I see several SEVERE errors from the Felix OSGi system soon after Mojarra is initialized.

It appears there are several more attempts to start the server, each of which has a shutdown soon after the Mojarra initialization.

The last such attempt fails with this exception log:

Caused by: java.lang.ClassNotFoundException: com/sun/enterprise/security/jmac/config/GFAuthConfigFactory
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:206)
... 24 more

#]

I see no evidence that JSF is the cause of these failures, while I do see evidence that looking into the OSGi bundles or the security problem may lead to a resolution of the problem.

Therefore, I am going to edit this issue to give it a specific component and let JIRA assign the issue to the component leader.

Comment by Ed Burns [ 19/Aug/11 ]

Assign to security component.





[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-6209] list-file-users should print the group info as well Created: 22/Sep/08  Updated: 27/Mar/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 6,209

 Description   

When a user executes the command list-file-users command it simply prints the
available users in the given file realm. But it doesn't say which group the user
belongs to. The only way the user can know is to directly look at the keyfile
and makeout which user belongs to which group, which is not a good way to know
the user group. So we should print the group name as well in the list-file-users
command output.



 Comments   
Comment by km [ 22/Sep/08 ]

Agree. Maybe it should list the users by auth-realm-name as well.

Comment by ne110415 [ 22/Sep/08 ]

Couple of comments:

1. We have some form of this reporting. See list-file-groups command for this
kind of reporting
Usage: list-file-groups [--terse=false] [--echo=false] [--interactive=true] [--
host localhost] [--port 4848|4849] [--secure | -s] [--user admin_user] [--
passwordfile file_name] [--name username] [--authrealmname authrealm_name]
[target(Default server)]

2. For prelude, plan is to continue v2 style for these CLIs. This is v2 output:

C:\work\publish\glassfish\bin>asadmin.bat create-file-user --port 4849 testuser1
Please enter the file user password>
Please enter the file user password again>
Command create-file-user executed successfully.

C:\work\publish\glassfish\bin>asadmin.bat create-file-user --port 4849 --groups
asadmin2 testuser2
Please enter the file user password>
Please enter the file user password again>
Command create-file-user executed successfully.

C:\work\publish\glassfish\bin>asadmin.bat create-file-user --port 4849 --groups
asadmin1 testuser1
Please enter the file user password>
Please enter the file user password again>
User testuser1 already exists.
CLI137 Command create-file-user failed.

C:\work\publish\glassfish\bin>asadmin.bat create-file-user --port 4849 --groups
asadmin3 testuser3
Please enter the file user password>
Please enter the file user password again>
Command create-file-user executed successfully.

C:\work\publish\glassfish\bin>asadmin.bat create-file-user --port 4849 --groups
asadmin3 testuser4
Please enter the file user password>
Please enter the file user password again>
Command create-file-user executed successfully.

C:\work\publish\glassfish\bin>asadmin.bat list-file-users --port 4849
testuser4
testuser3
testuser2
testuser1
Command list-file-users executed successfully.

Comment by Tom Mueller [ 19/Jan/11 ]

Please consider adding a -l option for the list-file-users command that would provide additional information for each user (auth realm, group) in columnar format. See the output formatting guidelines for how the output should be formatted:

http://wikis.sun.com/display/GlassFish/Asadmin+Command+Output+Guidelines

The output without -l could still be the same as v2 for compatibility.





[GLASSFISH-8051] enabling ssl2 for orb listener should fail Created: 28/Apr/09  Updated: 27/Mar/13

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

Type: Bug Priority: Minor
Reporter: sankarpn Assignee: sankarpn
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: 8,051

 Description   

asadmin set server.iiop-service.iiop-listener.SSL.ssl.ssl2_enabled=true
iiop-service.iiop-listener.SSL.ssl.ssl2-enabled=true

Command set executed successfully.

In V2.1 we disallow this and the command will fail with message "ssl2 cannot be
enabled for an iiop-listener"



 Comments   
Comment by km [ 23/Sep/09 ]

Since ssl element is shared, we need to put this additional validation in the
command implementation. Nachiappan knows about these commands.

Comment by sankarpn [ 28/Oct/09 ]

V2 behavior. I don't know what is behind the prohibition of enabling ssl2 in v2,
but it is not allowed.

So do the set command.

  1. ./asadmin create-ssl --type iiop-listener --certname s1as --ssl2enabled=true
    iiopls1
    ADMVAL1034: ssl2 cannot be enabled for an iiop-listener
    ADMVAL1070: Create of ssl is rejected.
    CLI137 Command create-ssl failed.
  1. ./asadmin set server.iiop-service.iiop-listener.iiopls1.ssl.ssl2-enabled=true
    ADMVAL1034: ssl2 cannot be enabled for an iiop-listener
    ADMVAL1070: Change of ssl is rejected.
    CLI137 Command set failed.

So if the user tries to set ssl2enabled flag to be true fail the set command.

Comment by psterk [ 29/Oct/09 ]

Taking a look at this bug. Contacting Nachiappan Veerappan for initial strategy.

Comment by nachi_glassfish [ 29/Oct/09 ]

Changing status to P4.

The bug description says that user should not be able to configure SSL2 for an
iiop-listener because ORB does not support SSL2 protocol.
The bug status is changed to P4, because even though we are able to configure
SSL2 for iiop-listener in V3 the runtime has nothing to do with that.
(i.e,) Though an entry is made in domain.xml (under iiop-listener) when the
asadmin set server.iiop-service.iiop-listener.SSL.ssl.ssl2_enabled=true
iiop-service.iiop-listener.SSL.ssl.ssl2-enabled=true is executed, the runtime is
not affected.

I am currently investigating the way to do bean validation to fix the bug.

Comment by Tom Mueller [ 14/Feb/11 ]

Please evaluate this issue as to whether it still applies?
Is SSL2 still not allowed for the IIOP listener in v3?

Comment by Ken Cavanaugh [ 14/Feb/11 ]

This is a security issue, not an ORB issue, because all of the CSIv2 implementation is
currently external to the ORB.

Comment by kumarjayanti [ 14/Feb/11 ]

Just tried the following on V3.1

./asadmin create-ssl --type iiop-listener --certname s1as --ssl2enabled=true orb-listener-1
Command create-ssl executed successfully.

and i see the following in domain.xml

<iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0" lazy-init="true">
<ssl ssl2-enabled="true" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"></ssl>
</iiop-listener>

Comment by kumarjayanti [ 14/Feb/11 ]

The supported protocols in JSSE are :
SSLv2Hello,
SSLv3,
TLSv1,

http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html

The JSSE implementation in the J2SDK 1.4 and later implements SSL 3.0 and TLS 1.0. It does not implement SSL 2.0.

So yes the validation code in create-ssl probably needs to be enabled/implemented in V3 as well. But this is not a security module bug since the security team does not own create-ssl command. Please reassign appropriately.





[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-16952] Provide copy realm function Created: 04/Jul/11  Updated: 27/Mar/13

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

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


 Description   

Did a typo when creating a JDBC realm, wanted to fix it... bug cannot after pressing OK!

Would be great if the GUI would allow to rename a realm, so I am not forced to type in all the complete config again. This is not very smart.



 Comments   
Comment by Anissa Lam [ 04/Jul/11 ]

The name of the realm is the id /primary key for this realm, just like any other element, like name of instance, name of cluster, listener, anything. Once it is created, the name cannot be changed.
There is no way to do that.
Maybe you can request the backend to provide a copy-realm function , then you can copy and delete the previous one.
I will change this to request a copy function and transfer to backend.
If this is implemented, then console can add in the UI.

Comment by mkarg [ 06/Jul/11 ]

I do not see how the backend could solve this. The information I want to keep at the renaming is the configuration of a jdbc-realm. Only GlassFish knows that information. The backend is out of scope and has no problem.

Comment by mkarg [ 06/Jul/11 ]

I do not see why it shall be impossible to implement the rename. You can just implement it as a copy-delete action:

  • Create new realm configuration as a copy of the old one, using the target name.
  • Remove the configuration of the old realm, using the source name.
  • Replace the old realm name by the new realm name wherever it is reference in the GlassFish configuration.
Comment by Anissa Lam [ 06/Jul/11 ]

When i say 'backend', i mean the GF admin or security team.
They can provide the copy-realm command so that all clients can benefit from it.

Comment by mkarg [ 07/Jul/11 ]

I see. I assumed that "backend" is the server, as typical in IT discussions.





[GLASSFISH-18101] Error message reported during upgrade of 2.1.1 Cluster to GF3.1.2 Created: 30/Dec/11  Updated: 27/Mar/13

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

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

Solaris 10 Sparc system. GF v2.1.1patch 12. GF3.1.2 build16. Firefox 3.6.2 browser. JDK1.6.0_26


Attachments: Text File server.log     Text File upgrade.log    

 Description   

The test scenario is a "side-by-side" upgrade scenario from GFv2.1.1patch12 to GF3.1.2 build16. The overall steps are:

  • Install GFv2.1.1patch12 (sges-2_1_1-p12-bin-b02-solaris-sparc-09_jun_2011.bin) in $HOME/SUNWappserver
  • Enter admin123 as the admin password. Start the server.
  • Create node agent, cluster and two instances.
  • Deploy hello.war on the cluster. Verify that it works.
  • Deploy clusterjsp.ear on the instance (DAS). Verify that it works
  • Deploy UpgradeTester-ear.ear (upgrade app created by bbissett). Verify that it works
  • Shutdown the server.
  • Install GF3.1.2 (ogs-3.1.2-b16-unix.sh) in $HOME/glassfish3. Use default values (port, no admin password)
  • Verify server is functional (check localhost:8080, localhost:4848)
  • Shutdown the server
  • Invoke asupgrade tool (cd $1AS_HOME/domains; asupgrade -c -s $HOME/SUNWappserver/domains/domain1 -t .)
    It's during the above step that the errors are displayed,

asadmin: INFO: Disabling application UpgradeTester-ear
Possible error encountered during upgrade. See server log after upgrade process
completes.
asadmin: java.lang.NullPointerException^M
asadmin: at com.sun.web.security.RealmAdapter.postConstruct(RealmAdapter.java:1746)
asadmin: at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
asadmin: at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
asadmin: at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
asadmin: at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
asadmin: at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
asadmin: at org.jvnet.hk2.component.Habitat.getByContract(Habitat.java:1050)
asadmin: at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1941)
asadmin: at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1661)
asadmin: at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
asadmin: at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
asadmin: at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
asadmin: at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
asadmin: at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
asadmin: at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
asadmin: at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:210)
asadmin: at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:108)
asadmin: |#]
asadmin: java.lang.Exception: java.lang.NullPointerException^M
asadmin: at com.sun.enterprise.web.WebApplication.start(WebApplication.java:138)
asadmin: at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
asadmin: at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
asadmin: at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
asadmin: at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
asadmin: at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
asadmin: at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:210)
asadmin: at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:108)
asadmin: |#]
asadmin: Completed shutdown of Log manager service
asadmin: java.io.InterruptedIOException
asadmin: at java.io.FileOutputStream.writeBytes(Native Method)
asadmin: at java.io.FileOutputStream.write(FileOutputStream.java:282)
asadmin: at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
asadmin: at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
asadmin: at com.sun.enterprise.server.logging.GFFileHandler$MeteredStream.flush(GFFileHandler.java:514)
asadmin: at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:278)
asadmin: at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
asadmin: at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
asadmin: at java.util.logging.StreamHandler.flush(StreamHandler.java:225)
asadmin: at com.sun.enterprise.server.logging.GFFileHandler.log(GFFileHandler.java:679)
asadmin: at com.sun.enterprise.server.logging.GFFileHandler$1.run(GFFileHandler.java:179)
asadmin: Completed shutdown of GlassFish runtime
asadmin: Command start-domain executed successfully.
asadmin: The DAS was stopped.
End asadmin local command output.
Upgrade completed.

In the server.log, one can see the error as a SEVERE message. This error has not been seen in previous upgrade tests from v.2.1.1 to 3.1.1.

Subsequently and after recreating the node, cluster and instances, the deployed apps all appear to work normal. Need further investigation.



 Comments   
Comment by Bobby Bissett [ 30/Dec/11 ]

Am moving to security team for a look.

Comment by Joe Di Pol [ 20/Jan/12 ]

Based on this e-mail update from Nithya I'm lowering the priority and removing 3_1_2-review:

"The issue was happening because when the application was getting deployed in v3, the network-config element was probably unavailable in the v3 instance for the first time. However on subsequent restart, the network configuration would have been made available in v3 and the scenario would work fine.
If the restart is part of the test case, then this is not a serious issue to be fixed urgently in 3.1.2."





[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-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-19202] JAX-RS and Servlet Constraint Overlap (Support for Multiple Auth Mechanisms) Created: 22/Oct/12  Updated: 19/Mar/13

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

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


 Description   

Currently, due to the JAX-RS reliance on the servlet container's authentication mechanism, it is possible to define a security constraint with an URL pattern that encompasses a JAX-RS endpoint as well as other servlets within the application.

When the configured authentication method within web.xml is FORM or any other method that ultimately assumes that there is a user and browser to interact with, the JAX-RS client is presented with a challenge for credentials that it is unable to deal with - such as form based login. Additionally, the URL pattern matching model does not include enough fidelity to differentiate between the underlying JAX-RS resources. JAX-RS was an unique requirement to want provide varying authentication mechanisms for the same URL based upon the nature of the client. Therefore, the URL pattern based constraints are not well suited for indicating resource level constraints.






[GLASSFISH-19203] Password Aliasing Created: 22/Oct/12  Updated: 19/Mar/13

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

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

Tags: ee7platspec

 Description   

Best practices and common enterprise security policies dictate that we not store any passwords in clear text on the filesystem. There are a number of places where passwords are required in configuration, annotations and possibly even application code.
Password aliasing or indirection is a mechanism for storing and referencing a moniker or token instead of an actual clear text password. Resolving the token into an actual password for use at runtime is protected and only available to trusted code.
In order to support this in a portable way, Java EE 7 is standardizing a number of aspects of the solution. At the same time, the standard will not dictate the runtime implementation details for this support.

See http://java.net/downloads/javaee-spec/password-aliasing-ee7-proposal.pdf






[GLASSFISH-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-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-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-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-19206] Improved Credential and SSL Configuration Created: 22/Oct/12  Updated: 14/Nov/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: