[VISUALVM-559] Need user feedback when determined that username/password may be sent via an insecure connection Created: 13/May/13  Updated: 19/Dec/13  Resolved: 25/Jun/13

Status: Resolved
Project: VisualVM
Component/s: plugins
Affects Version/s: 1.0, 1.0.1, 1.1, 1.1.1, 1.2, 1.2.1, 1.2.2, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5
Fix Version/s: 1.3.6

Type: Bug Priority: Major
Reporter: yardus Assignee: thurka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: security

 Description   

VisualVM should be updated so that the dialog box for connecting to a
remote RMI host-and-port gets a checkbox saying "connection must use SSL".

When true, VisualVM will use the following JMXServiceURL:

service:jmx:rmissl:///jndi/rmi://hostName:portNum/jmxrmi

When false (default value), VisualVM will use the following JMXServiceURL:

service:jmx:rmi:///jndi/rmi://hostName:portNum/jmxrmi

@ luis-miguel.alventosa@sun.com 2005-2-11 14:10:59 GMT

If SSL is checked, set a new property jmx.remote.x.check.stub to true for the
environment map when VisualVM connects to the target VM.



 Comments   
Comment by thurka [ 25/Jun/13 ]

We used similar fix to JConsole. VisualVM will check for SSL-protected RMI registry and warn user that username/password will be sent in plain text. Fixed in revision 3232.

Comment by rainerfrey [ 16/Dec/13 ]

The way this is fixed is very annoying. We use monitoring within a trusted network, and therefore don't use SSL. With 1.3.6, there is now a warning for every saved connection in VisualVM at startup (about 2 dozens in my case). Could this please be changed in a way more along the lines of the original report. that a connection can be marked to require a secure connection, and does not warn if it is not required.

Comment by jsedlacek [ 19/Dec/13 ]

Improved for the next VisualVM version in revision 3326.





[UPDATECENTER2-287] Add authentication support for proxy Created: 27/May/08  Updated: 19/Jun/08  Resolved: 19/Jun/08

Status: Resolved
Project: updatecenter2
Component/s: updatetool
Affects Version/s: current
Fix Version/s: 2.0-MS11

Type: Improvement Priority: Major
Reporter: Nazrul Assignee: mnsingh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File proxy-auth.JPG    
Issuezilla Id: 287
Tags: security

 Description   

Currently (GFv3 TP2 bundle), UC 2.0 does not have any support for proxy
authentication. Some of the enterprise customers require authentication for
their proxy. So, those customers will not be able to use UC.

Please add authentication support for proxy.



 Comments   
Comment by Nazrul [ 27/May/08 ]

Created an attachment (id=49)
UC 1.x preferences panel with proxy authentication fields

Comment by ckamps [ 17/Jun/08 ]

Appears to be a must have feature for 2.0 to achieve parity with UC 1.x.

Comment by mnsingh [ 18/Jun/08 ]

Need to figure out the security impact of proxy password storage.

Comment by mnsingh [ 19/Jun/08 ]

Implemented.





[SERVLET_SPEC-114] Standardize authentication modules in Servlet Created: 31/Oct/14  Updated: 31/Oct/14

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Tags: authentication, jaspic, jsr-196, security

 Description   

13.6.5 of the Servlet spec says that it's recommended that Servlet containers use the Servlet Container Profile of the Java Authentication SPI for Containers (aka JASPIC, i.e. JSR 196).

In order to facilitate portability and a steady base to build upon for the entire Java EE platform, I'd like to propose to change this from "recommended" to "mandated".



 Comments   
Comment by arjan tijms [ 31/Oct/14 ]

P.s, a change in section 15.3.3 is also needed.

This section now says that all Servlet containers must implement JASPIC in a Java EE product or a product that supports JASPIC.

For this section I'd like to propose removing the conditional so that the section simply holds for all Servlet containers.

The section in 15.3.3 now reads as follows:

In a Java EE product, or a product that includes support for The Java
Authentication SPI for Containers (JASPIC, i.e, JSR 196), all Servlet
containers MUST implement the Servlet Container Profile of the JASPIC
specification.

After the proposed change this would become:

All Servlet containers MUST implement the Servlet Container Profile of the JASPIC
specification.

For completeness, the section in 13.6.5 now reads:

To facilitate portable implementation and integration of additional container authentication
mechanisms, it is recommended that all Servlet containers implement the Servlet Container
Profile of The Java Authentication SPI for Containers

After the proposed change this would become:

To facilitate portable implementation and integration of additional container authentication
mechanisms, it is mandated that all Servlet containers implement the Servlet Container
Profile of The Java Authentication SPI for Containers





[SERVLET_SPEC-65] Add CORS (Cross-Origin Resource Sharing) support in web.xml Created: 05/Mar/13  Updated: 05/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Samuel Santos Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE, cors, security, servlet

 Description   

http://www.w3.org/TR/cors/ describes a mechanism to allow secure cross-origin resource sharing.
Please consider adding support for it in web.xml.






[SERVLET_SPEC-63] Consider adding an option to set Strict-Transport-Security header in web.xml Created: 21/Feb/13  Updated: 01/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Samuel Santos Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE, security, web-a

 Description   

Transparent redirection to HTTPS means that the vast majority of the time your users are on your site, they'll be using a secure connection. It does, however, leave a small window of opportunity for attack: the initial HTTP connection is wide open, vulnerable to SSL stripping and related attacks. Given that a man in the middle has complete access to the initial HTTP request, it can act as a proxy between you and the server, keeping you on an insecure HTTP connection regardless of the server's intentions.

You can mitigate the risk of this class of attack by asking the browser to enforce HTTP Strict Transport Security (HSTS). Sending the Strict-Transport-Security HTTP header instructs the browser to do the HTTP to HTTPS redirection client-side, without ever touching the network (this also happens to be great for performance; the best request is the one you don't have to make).

Please consider adding an option to set this header in web.xml.



 Comments   
Comment by markt_asf [ 21/Feb/13 ]

HSTS itself has a fairly large flaw in that the MITM can just remove the header before it ever reaches the client.

I'm not convinced of the usefulness of this mitigation. Sites that want to use it can always write a simple filter to add it.

Comment by Shing Wai Chan [ 22/Feb/13 ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-34] Auth constraint that requires a valid user, but does not require any particular role Created: 16/Mar/12  Updated: 01/Mar/13  Resolved: 01/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: elygre Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: security

 Description   

For many applications, the it is desirable to have authentication handled by the container, while authorization must be handled by the application login. In such scenarios, it would be useful to require the a user is logged on, without having to specify roles.

There is precendence for this kind of security from other environments:

Since the last one conflicts with the current spec, maybe something like this would work:

<auth-constraint anyAuthenticatedUserAllowed="true" />
@ServletSecurity(@HttpConstraint(anyAuthenticatedUserAllowed=true))
public class Example4 extends HttpServlet {
}


 Comments   
Comment by Shing Wai Chan [ 09/Jan/13 ]

According to JSR 115 MR2, "*" means all the roles defined for the web app.
It is not any users there.

Comment by elygre [ 09/Jan/13 ]

Shing Wai Chan Yes, that is correct. This issue is an enhancement request for a new auth-constraint that does not require roles, but instead just requires any valid user.

The use case is very common. As show above, the google app-engine deviates from the servlet spec and redefines this aspect of web.xml to support the use case. That should be a strong argument that there is a market requirement.

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

"*" is for any roles rather than users as defined in JSR 115.
We need to investigate a backward compatible solution.

One way to achieve this is to have the realm to add a universal role to any authenticated users. This is how GlassFish resolve this issue.
You can find more details in
https://blogs.oracle.com/swchan/entry/assign_groups

Comment by elygre [ 10/Jan/13 ]

I totally agree that we need a backward compatible solution. The jira issue does not suggest using the role name "*" at all, but clearly states that this "conflicts with the current spec", and suggests that something else is needed, "maybe the something like this would work":

<auth-constraint anyAuthenticatedUserAllowed="true" />

The GlassFish solutions is interesting. I would hope for a servlet-level solution (which would then be supported by all appservers), but at least it serves to further validate the requirement

Comment by Shing Wai Chan [ 01/Mar/13 ]

A special role "**" is added to achieve this in the spec.
Please see section 13.3 of the Servlet 3.1 PFD for details.

Comment by Shing Wai Chan [ 01/Mar/13 ]

See also section 13.4.1.3 in Servlet 3.1 PFD.





[OPENCODER-20] Encryption between web-face and judge Created: 01/Oct/12  Updated: 07/Oct/12  Resolved: 07/Oct/12

Status: Closed
Project: opencoder
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: rodiongork Assignee: rodiongork
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

PHP-prototype


Tags: security

 Description   

We want text responses between web-face and judge be:

  • padded with random data;
  • RLE-compressed;
  • encrypted with simple XOR-ing with static and/or generated key;
  • mime64-encoded.


 Comments   
Comment by rodiongork [ 06/Oct/12 ]

rev186 - implemented, though also checksum could be added later.

Comment by rodiongork [ 06/Oct/12 ]

Functionality should be ported to PHP sources from java.

Comment by rodiongork [ 07/Oct/12 ]

rev190 - sources are now encrypted when storing inside database, so judge receives them already encrypted.





[OPENCODER-14] Vaadin security for admin panel Created: 17/Jun/12  Updated: 17/Jun/12  Resolved: 17/Jun/12

Status: Closed
Project: opencoder
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: rodiongork Assignee: rodiongork
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: admin, security

 Description   

Admin panel should be protected at least with password.
Also, if possible, we should make its url configurable.



 Comments   
Comment by rodiongork [ 17/Jun/12 ]

rev125, simple login form which substitutes windows





[METRO-18] ClassCastException while using tubes Created: 08/May/12  Updated: 14/Dec/12  Resolved: 14/Dec/12

Status: Resolved
Project: metro
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aeai Assignee: Martin Grebac
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.1, Metro 2.3, Windows


Tags: incomplete, security

 Description   

We see some failures in security area with tube message handling. We use glassfish 3.1.1 and latest metro.

Exception:

[#|2012-05-07T10:10:28.829+0200|INFO|glassfish3.1.1|com.sun.xml.wss.jaxws.impl.SecurityClientTube|_ThreadID=66;_ThreadName=Thread-2;|Response exception processed in Tube [ com.sun.xml.wss.jaxws.impl.SecurityClientTube ] Instance [ 6 ] Engine [ Metro/2.3-SNAPSHOT (trunk-7036; 2012-03-08T14:22:01+0000) JAXWS-RI/2.2.7-promoted-b26 JAXWS/2.2 svn-revision#unknown: Stub for ] Thread [ Ejb-Async-Thread-9 ]:
javax.xml.ws.WebServiceException: java.lang.ClassCastException: com.sun.xml.ws.api.message.MessageWrapper cannot be cast to com.sun.xml.ws.security.message.stream.LazyStreamBasedMessage
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:365)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1073)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:978)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:949)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:824)
at com.sun.xml.ws.client.Stub.process(Stub.java:436)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:174)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:102)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:154)
at $Proxy337.queryActivationKeys(Unknown Source)
at com.test.SequenceNumberServiceAdapter.fetch(SequenceNumberServiceAdapter.java:39)
at com.test.RequestHandler.get(RequestHandler.java:26)
at com.test.SequenceNumberService.fetchAndSend(SequenceNumberService.java:37)
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 org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:57)
at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:101)
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)
Caused by: java.lang.ClassCastException: com.sun.xml.ws.api.message.MessageWrapper cannot be cast to com.sun.xml.ws.security.message.stream.LazyStreamBasedMessage
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.verifyInboundMessage(SecurityTubeBase.java:442)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientResponsePacket(SecurityClientTube.java:434)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:362)
... 46 more



 Comments   
Comment by Martin Grebac [ 09/May/12 ]

Please verify with latest metro 2.2.1 promoted builds - we're actively working on 2.2.1 codebase now, will get back to 2.3 later on.

Comment by Martin Grebac [ 09/May/12 ]

Also, please add a testcase if you still see the failures with recent builds.





Conferences (LJUG-39)

[LJUG-76] Securité basé rôle en J2EE Created: 15/Dec/12  Updated: 09/Dec/13  Due: 03/Jan/13  Resolved: 11/Jan/13

Status: Resolved
Project: ljug
Component/s: Students Projetcs
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: pascalfares Assignee: pascalfares
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: 7 hours, 30 minutes
Time Spent: 5 hours, 40 minutes
Original Estimate: Not Specified
Environment:

j2ee containers


Status Whiteboard:

Under active work

Tags: j2ee, security, tomcat

 Description   

Article et conférence présentant la sécurisation des applications (j2ee) par la méthode basé sur les rôles. EN utilisant le canevas standard j2ee

Un article : http://reseaux-systemes.cofares.net/cours-en-cours/j2ee-tutorial/controle-acces-base-roles

Une présentation :



 Comments   
Comment by pascalfares [ 15/Dec/12 ]

Cette tâche représentera un exemple que vous pourrez suivre

La présentation prévue sera d'environ 45mn

Comment by pascalfares [ 11/Jan/13 ]

Restait la présentation. Faite en cours





[JERSEY-2374] NullPointerException in OAuth1ClientFeature Created: 30/Jan/14  Updated: 11/Feb/14  Resolved: 04/Feb/14

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.5.1
Fix Version/s: 2.6

Type: Bug Priority: Major
Reporter: johanvos Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: oauth, oauth1, security

 Description   

OAuth1ClientFeature has a ServiceLocator instance that should be injected:

@Inject
private ServiceLocator config;

However, this config is not used in the class. Also, the injection fails and the config is null. This object is printed in the configure method:

public boolean configure(FeatureContext context) {
System.out.println(config);
...
}

In GlassFish, this causes a NullPointerException:
java.lang.NullPointerException
at com.sun.common.util.logging.LoggingOutputStream$LoggingPrintStream.println(LoggingOutputStream.java:230)
at org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.println(ThreadPrintStream.java:208)
at org.glassfish.jersey.client.oauth1.OAuth1ClientFeature.configure(OAuth1ClientFeature.java:100)

LoggingOutputStream will try to print config.toString().

Solution: since the config field is not used, it should be removed at all. I propose the following patch:

diff --git a/security/oauth1-client/src/main/java/org/glassfish/jersey/client/oauth1/OAuth1ClientFeature.java b/security/oauth1-client/src/main/java/org/glassfish/jersey/client/oauth1/OAut
index c219e90..a45f8de 100644
--- a/security/oauth1-client/src/main/java/org/glassfish/jersey/client/oauth1/OAuth1ClientFeature.java
+++ b/security/oauth1-client/src/main/java/org/glassfish/jersey/client/oauth1/OAuth1ClientFeature.java
@@ -81,9 +81,6 @@ final class OAuth1ClientFeature implements Feature {
     private final OAuth1Parameters parameters;
     private final OAuth1Secrets secrets;
 
-    @Inject
-    private ServiceLocator config;
-
     /**
      * Create a new feature.
      *
@@ -97,7 +94,6 @@ final class OAuth1ClientFeature implements Feature {
 
     @Override
     public boolean configure(FeatureContext context) {
-        System.out.println(config);
 
         context.register(OAuth1SignatureFeature.class);
         context.register(OAuth1ClientFilter.class);





[JERSEY-2342] Introduce an intuitive way to set explicit state from an OAuth2 flow Created: 17/Jan/14  Updated: 03/Feb/14

Status: Open
Project: jersey
Component/s: security
Affects Version/s: 2.5.1
Fix Version/s: backlog

Type: Improvement Priority: Trivial
Reporter: ingenious Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Tags: oauth, oauth2, security

 Description   

See also http://stackoverflow.com/questions/21101748/explicit-state-parameter-in-jerseys-oauth2codegrantflow/
There would be nice to have a more straight forward way to set the state parameter.

My use case: I've got a client app and a backend. I try to keep the app as minimalistic as possible and to handle as much logic on the backend as I can. So my app tries to access a resource on the backend API, which ultimately gets the resource from somewhere else. When running the flow for the first time there is no authorization code/access token so the backend redirects the app to an authorization entry point. Then the app gets the access token and uploads it in the backend. And here I need to have a state, to be able to map this token to the original query.






[JERSEY-2061] Client can be forced to connect to a resource with a different set of credentials if previously accessed via HttpURLConnection Created: 22/Aug/13  Updated: 14/Jan/14  Resolved: 14/Jan/14

Status: Resolved
Project: jersey
Component/s: security
Affects Version/s: 1.17, 2.4.1
Fix Version/s: 2.6

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

JDK 7u17, Linux


Attachments: Java Source File AuthenticatorClientTest.java    
Tags: client, security

 Description   

The Java authenticator framework use by URL, HttpURLConnection and the like for user interface reasons will remember the credentials used to access a particular URI over the life of the VM until such time as this set of credentials return a 401 response.

Unfortunately this can mean that the default handler for the Client will inherit this pre-cached information. In this example the expected output should be:

username="authenticator",
username="jersey",

but instead when you run this code you see:

username="authenticator",
username="authenticator",

Here is the code that exercises the bug, if you modify the code to use Basic rather than Digest then it will pass; but that is because of JERSEY-2050.

package authenticatorissue;

import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.client.filter.HTTPDigestAuthFilter;
import com.sun.jersey.api.container.httpserver.HttpServerFactory;
import com.sun.jersey.api.core.ClassNamesResourceConfig;
import com.sun.net.httpserver.HttpServer;

import java.io.DataInputStream;

import java.net.Authenticator;
import java.net.PasswordAuthentication;
import java.net.URL;

import javax.ws.rs.GET;
import javax.ws.rs.HeaderParam;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

public class VerifyIssue {
    public static void main(String[] args) throws Exception {

        // Publish the REST endpoint

        HttpServer server =
            HttpServerFactory.create("http://localhost:8080/rest",
                                     new ClassNamesResourceConfig(GetResourceBasic.class));

        try {
            server.start();

            // Replace the VM default authenticator with one that just returns authenticator/authenticator

            Authenticator.setDefault(new Authenticator() {

                @Override
                protected PasswordAuthentication getPasswordAuthentication() {
                    return new PasswordAuthentication("authenticator", "authenticator".toCharArray());
                }
            });

            // Get that resource using just URL

            URL resource = new URL("http://localhost:8080/rest/get-basic");
            try (DataInputStream dis = new DataInputStream(resource.openStream())) {

                byte buffer[] = new byte[1024];
                int length = dis.read(buffer);
                System.out.println(new String(buffer, 0, length));

            }

            // Now get that resourece using a Jersey client

            Client client = Client.create();
            client.addFilter(new HTTPDigestAuthFilter("jersey", "jersey"));

            WebResource webResource = client.resource(resource.toURI());

            System.out.println(webResource.get(String.class));


            //

        } finally {
            server.stop(0);

        }

    }


    @Path("/get-basic")
    public static class GetResourceBasic {

        @GET
        public Response get(@HeaderParam("authorization") String authenticate) {

            if (authenticate != null) {
                // Dump out the user name
                return Response.ok(authenticate.split(" ")[1].split(", ")[0]).build();

            } else {
                return Response.status(Response.Status.UNAUTHORIZED).header("WWW-Authenticate",
                                                                            "Digest realm=\"example\", qop=\"auth,auth-int\", nonce=\"dcd98b7102dd2f0e8b11d0f600bfb0c093\", opaque=\"5ccc069c403ebaf9f0171e9517f40e41\"").build();
            }
        }
    }

}


 Comments   
Comment by Michal Gajdos [ 05/Dec/13 ]

Targeting for 2.6 although I don't thing this has a solution. When authentication mechanism is being negotiated (401 from server + WWW-Authenticate header) the HttpUrlConnection will send authorization header itself (since it has an instance of Authenticator set) without delegating into digest filter. Based on the code ([1]) I don't see a way how to override it.

[1] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/protocol/http/HttpURLConnection.java

Comment by Michal Gajdos [ 05/Dec/13 ]

Test-Case attached.

Comment by Marek Potociar [ 14/Jan/14 ]

There does not seem to be a viable solution for the issue. Closing as won't fix.





[JERSEY-1714] Jersey web services are vulnerable to XXE (entity expansions vector) Created: 07/Feb/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

Status: Resolved
Project: jersey
Component/s: security
Affects Version/s: 1.17, 2.0-m12, 2.0
Fix Version/s: 2.0-rc2, 2.0

Type: Bug Priority: Critical
Reporter: h3xstream Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 10 hours
Original Estimate: 6 hours

Tags: denial-of-service, security, xml, xxe

 Description   

Jersey is vulnerable to entity expansion (http://clawslab.nds.rub.de/wiki/index.php/XML_Generic_Entity_Expansion)

===

For the given resource, a single request could cause memory exhaustion (java.lang.OutOfMemoryError).

@Path( "/ping" )
public class PingService {

	@POST
	public String ping( PingRequest req ) {
		return req.getInput();
	}

	@XmlRootElement( name = "ping" )
	@XmlAccessorType( value = XmlAccessType.FIELD )
	public static class PingRequest {

		@XmlElement
		private String input;

		public String getInput() {
			return input;
		}

		public void setInput( String input ) {
			this.input = input;
		}
	}
}

Request exemple:

POST /ping HTTP/1.1
Host: attack.me
Accept: application/xml
Content-Type: application/xml
Content-Length: 1338

<!DOCTYPE lolz [
  <!ENTITY lol "lollollollollollollol[...]">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
]>
<ping><input>&lol6;</input></ping>

The xerces parser has by default a limit of 100,000 entity expansions. Nevertheless, it is enough to generate enormous strings.



 Comments   
Comment by Marek Potociar [ 27/Feb/13 ]

When working on the fix, check http://jaxp.java.net/1.4/JAXP-Compatibility.html#JAXP_security .

Comment by Miroslav Fuksa [ 04/Apr/13 ]

It would be nice if jersey would have a configuration which would allow the entity expansion limit to be changed. Unfortunately, there is no solution using clean JAXP how to configure the limit for one specific sax parser which is exactly what we would need in our message body readers. The only possible way is to define the system property with the limit:

System.setProperty("entityExpansionLimit", "10");

... or define property using command line arguments or environment properties.

Please note, that the system property will be used for all sax parsers on the JVM and not only in jersey message body readers (so it will for example influence all sax/dom parsers used in the server in which Jersey is running).

You can also use a property "elementAttributeLimit" to limit maximum number of attributes in elements.

Also please note that in order to use the secure parsing in jersey the following property must NOT be configured:

org.glassfish.jersey.message.MessageProperties.XML_SECURITY_DISABLE

... the property would disable secure parsing and limits would be ignored.

Comment by Miroslav Fuksa [ 09/Apr/13 ]

I am closing the issue.

Cannot be implemented as jaxp does not allow possibility to control entity expansion limits for specific parsers. The solution is to use the system property (and influence all sax parsers). The tests were added to jersey that verifies that a configuration by system properties work. See comments of this issue for for details.

Comment by Miroslav Fuksa [ 18/Apr/13 ]

This bug was Closed but should be Resolved.





[JERSEY-1160] Initialize SecurityContext for client-authenticated SSL connection Created: 16/May/12  Updated: 21/Aug/12  Resolved: 21/Aug/12

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 1.12
Fix Version/s: 2.0-m07

Type: Improvement Priority: Major
Reporter: CLarrieu Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JERSEY-1282 SecurityContext injection does not work Resolved
Tags: container, grizzly, jax-rs, jersey, jersey-grizzly2, security, ssl

 Description   

Please modify GrizzlyContainer to initialize the ContainerRequest's SecurityContext with client identity from the SSL layer if available before handing it off to the WebApplication.

I am using jersey-grizzly2 to implement a RESTful interface for my service. Having configured the Grizzly layer to require client authentication, I find there's no straight-forward (or even round-about) way to access that information at the Jersey level.

Here's an example solution implemented in GrizzlyContainer._service():

            final ContainerRequest cRequest = new ContainerRequest(_application,
                    request.getMethod().getMethodString(), baseUri, requestUri,
                    getHeaders(request), request.getInputStream());
            
// === begin new code ===
            SSLEngine ssl = SSLUtils.getSSLEngine(request.getContext().getConnection());
            if (ssl != null) {
            	try {
            		final Principal p = ssl.getSession().getPeerPrincipal();
            		cRequest.setSecurityContext(new SecurityContext() {
            			@Override
            			public Principal getUserPrincipal() {
            				return p;
            			}
            			@Override
            			public boolean isUserInRole(String role) {
            				return false;
            			}
            			@Override
            			public boolean isSecure() {
            				return true;
            			}
            			@Override
            			public String getAuthenticationScheme() {
            				return SecurityContext.CLIENT_CERT_AUTH;
            			}
            		});
            	} 
            	catch(SSLPeerUnverifiedException ex) {
            		// no client certs
            	}
            }
// === end new code ===
 
            _application.handleRequest(cRequest, new Writer(response));


 Comments   
Comment by Pavel Bucek [ 02/Jul/12 ]

there should be a workaround (not tested):

you should be able to inject (into @Context annotated method param for example) Grizzly request and basically do what you are doing in proposed patch.

Comment by CLarrieu [ 02/Jul/12 ]

I developed a work-around that depends upon a single thread of execution from Grizzly filter chain up through the jersey level. Here's how I describe it in my code:

/**

  • This is part of a nasty hack that is needed to propagate the SSL-provided client
  • identity up from the Grizzly layer to the Jersey level.
  • The client identity is extracted from the Grizzly Request object and stored in a thread-local
  • variable for retrieval when filter() is run after the Jersey ContainerRequest has been
  • created but before the resource method has been invoked.
  • The only guarantee that both tasks will occur in the same thread is that the source code
  • for the current version (1.12) operates this way.
  • Hopefully the jersey-grizzly2 project will accept my patch (http://java.net/jira/browse/JERSEY-1160)
  • to make this hack unnecessary.
  • @author larrieu
    *
    */
Comment by Pavel Bucek [ 21/Aug/12 ]

already fixed in Jersey 2.x.





[JERSEY-1055] Fix vulnerable sample of code in documentation Created: 30/Mar/12  Updated: 03/Apr/12  Resolved: 03/Apr/12

Status: Resolved
Project: jersey
Component/s: docs
Affects Version/s: 1.12
Fix Version/s: 1.13

Type: Task Priority: Minor
Reporter: h3xstream Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: documentation, security

 Description   

http://jersey.java.net/nonav/documentation/latest/jax-rs.html#d4e324

The previous sample of code provided in the documentation should sanitize the parameter image before being pass to the File constructor.

... or the section could be rename "Filesystem backdoor"






[JAWR-334] Path traversal vulnerability Created: 13/May/15  Updated: 24/May/15  Resolved: 14/May/15

Status: Closed
Project: jawr
Component/s: Jawr Core
Affects Version/s: 3.6
Fix Version/s: 3.7

Type: Bug Priority: Critical
Reporter: farethewell Assignee: icefox
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: security

 Description   

Having run IBM Security AppScan against our app that uses Jawr for Javascript bundling, I found that Jawr is vulnerable to path traversal attack (aka dot-dot-slash).

Sample URL would something like this:
http://localhost/app/jsBundle/af811dd1f2fccc430c07136ae317e30b/%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc/passwd

Jawr lets the attacker download passwd file with no issues if he gets the number of '../' right.

More on this type of attack:
https://www.owasp.org/index.php/Path_Traversal

To fix this you could look at:
https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/firewall/DefaultHttpFirewall.java



 Comments   
Comment by icefox [ 14/May/15 ]

Hi

Thanks for reporting this issue and providing the way to handle it.
It has been fixed in the master branch

Cheers,
icefox

Comment by icefox [ 24/May/15 ]

This issue is fixed in the version 3.7 which has been released the 24rd May 2015.





[JAVASERVERFACES-3206] FacesServlet URL-pattern mapping neglects web.xml security configuration Created: 18/Mar/14  Updated: 27/Aug/14  Resolved: 07/Jul/14

Status: Closed
Project: javaserverfaces
Component/s: configuration
Affects Version/s: 2.2.0
Fix Version/s: 2.2.8

Type: Bug Priority: Trivial
Reporter: k0l0ssus Assignee: Manfred Riem
Resolution: Incomplete Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish V4


Tags: facesservlet, security, url-pattern

 Description   

Ref: http://stackoverflow.com/questions/22434622/facesservlet-url-patterns/22441493

OP noticed that using the URL mapping configuration for FacesServlet (in combination with a web.xml <security-constraint> configuration that also contained the "/faces/") allows a user to access restricted resources by adding an extra "/faces/" to page URL in the browser address bar. While OP hasn't stated his exact environment, I can confirm this is the case on my Glassfish v4, Mojarra 2.2, servlet v3.1

To reproduce:

1. In a basic JSF webapp, define FacesServlet mapping with /faces/*
2. Define a restricted web resource collection per standard JEE security configuration. This web resource should contain the "/faces/" string in the URL. For example

<security-constraint>
<display-name>TEST_SECURITY</display-name>
<web-resource-collection>
<web-resource-name>All_of_it</web-resource-name>
<description/>
<url-pattern>/faces/index.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint>
<description>roles</description>
<role-name>CLUBBER_LANG</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description/>
<role-name>CLUBBER_LANG</role-name>
</security-role>

3. Attempt to access the restricted resource with an extra "/faces/" (or any number of extra "/faces/, it doesn't make a difference) in the address bar, i.e. http://localhost/testapp/faces/faces/index.html. The restricted resource is accessible without any login prompting.



 Comments   
Comment by Manfred Riem [ 18/Mar/14 ]

Please verify if this is still the case in 2.2.6. Thanks!

Comment by DrankUpon [ 18/Mar/14 ]

Hello,

I am the OP of the issue that k0l0ssus was referring to. I have since downloladed the latest javax.faces-2.2.6.jar and added the dependency.

I can verify this issue still does exist.

Here is my current web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>faces/index.xhtml</welcome-file>
</welcome-file-list>
<security-constraint>
<display-name>ADMIN</display-name>
<web-resource-collection>
<web-resource-name>Admin Section</web-resource-name>
<description/>
<url-pattern>/faces/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<description/>
<role-name>ADMIN</role-name>
</auth-constraint>
<user-data-constraint>
<description/>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>jsfTest</realm-name>
</login-config>
<security-role>
<description/>
<role-name>ADMIN</role-name>
</security-role>
</web-app>

going to: http://localhost:8080/JSFtest/faces/admin/index.xhtml
result: Prompted for login and cannot access without validation

going to: http://localhost:8080/JSFtest/faces/faces/admin/index.xhtml
result: No login prompt and I am able to view the page.

Environment:

Javax-Faces: 2.2.6
JSF API: 2.2.0
Server: GlassFish Server Open Source Edition 4.0 (build 89)

Thank you
Vincent

Comment by Manfred Riem [ 26/Mar/14 ]

I am not sure by reading so I just want to make sure. Did you replace the javax.faces.jar in the GF 4 modules directory? If not can you please verify it that way? Thanks!

Comment by Manfred Riem [ 11/Apr/14 ]

Can you please send a reproducer in a zip file. Thanks!

Comment by Manfred Riem [ 14/May/14 ]

Lowering priority because of no response

Comment by Manfred Riem [ 11/Jun/14 ]

Lowering priority because of no response

Comment by Manfred Riem [ 07/Jul/14 ]

Closing issue out because of no response





[JAVASERVERFACES-2126] Flash scope cookie enables data exploits Created: 23/Jun/11  Updated: 28/Jun/13  Resolved: 26/Jun/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.1.24, 2.2.1

Type: Bug Priority: Critical
Reporter: arjan tijms Assignee: Ed Burns
Resolution: Fixed Votes: 12
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 12 hours, 40 minutes
Original Estimate: Not Specified

Attachments: Text File 20130620-1647-0500-i_moj_2126.patch     Text File 20130621-2335-0500-i_moj_2126.patch     Text File diffs.patch    
Issue Links:
Related
is related to JAVASERVERFACES-1449 Modify flash to support clustering Closed
is related to JAVASERVERFACES-2911 For JSF 2.2 and beyond, do setHttpOnl... Closed
is related to JAVASERVERFACES-2898 Sessionless flash implementation Closed
Tags: security

 Description   

The implementation of the flash scope in Mojarra 2.x is based on a cookie that contains an index into an application scoped map. This index is a simple integer. New values are obtained by the implementation by incrementing an AtomicInteger:

ELFlash.java
private long getNewSequenceNumber() {
    long result = sequenceNumber.incrementAndGet();

    if (0 == result % numberOfFlashesBetweenFlashReapings) {
        reapFlashes();
    }

    if (result == Long.MAX_VALUE) {
        result = 1;
        sequenceNumber.set(1);
    }

    return result;
}

This algorithm makes the index very predictable. Since the map that contains all flash data is application scoped, an attacker only needs to known an index in order to access data from random other users. As mentioned this index is very easy to guess. One scheme would be to observe the index being handed out for a particular request (say 1500), then take a slightly higher number (say 2000) and continuously poll the server using this cookie. Eventually this number will be generated server side and it's possible the attacker's request will reach the server before that of the legitimate user.

This exploit is even more severe since all current Mojarra implementations (2.0.x and 2.1.x) contain other bugs that prevent the flash scope from being immediately expired (see http://java.net/jira/browse/JAVASERVERFACES-1751). The user has to do a couple of post backs before this expiration actually happens. This means in the current situation there's a very wide window where the attacker can access data with a guessed index.

Since the Flash scope can contain any kind of data (like e.g. personal information, credit card details, messages, etc) this seems be a rather severe problem.

One solution would be to use a GUID instead of a sequential number. Another solution could be to (optionally) store flash data in the HTTP session and thus piggyback on the security of the JSESSIONID.



 Comments   
Comment by frederickkaempfer [ 02/Nov/11 ]

This bug is definitely exploitable, because ELFlash.java uses the unfiltered sequence number from the cookie csfcfc to retrieve the "session"'s flash map. The danger of data theft using flash cookies is very high so the Flash scope should NOT be used in production with sensitive data until this is resolved.

ELFlash does not use any session related information to generate the cookie's key nor when retrieving it. So there is basically no real security check and additionally the sequence numbers are very predictable.

– By the way the spec also mentions that the flash values should never leave context of the user session:

The Flash provides a way to pass temporary objects between the user views generated by the faces lifecycle. Anything
one places in the flash will be exposed to the next view encountered by the same user session and then cleared out.

To test create a simple managed bean that accesses the Flash scope:

@ManagedBean
@RequestScoped
public class FlashBean {

    public String getValue() {
        // put the current session id in the context to verify that
        // this value leaks between browser sessions
        Flash flash = FacesContext.getCurrentInstance().getExternalContext().getFlash();

        String sessionId = (String) flash.get("sessionId");

        return sessionId;
    }

    public void createFlash() {
        Flash flash = FacesContext.getCurrentInstance().getExternalContext().getFlash();
        HttpSession session = (HttpSession) FacesContext.getCurrentInstance().getExternalContext().getSession(true);

        String sessionId = session.getId();
        flash.put("sessionId", sessionId);
    }
}

Use this form on a facelet page:

<h:form>
            <h:outputText value="#{flashBean.value}"/>
            <h:commandButton value="Create flash" action="#{flashBean.createFlash()}">
                <f:ajax render="@form"/>
            </h:commandButton>
        </h:form>

Now play around with the cookie values in two separate browsers. For example use the csfcfc value sent to one browser when clicking the button. With firebug you should be able to retrieve one browser's session session id in another browser with a different user session.

So as arjan tijms stated, either use GUIDs or encode the current session id in the inner flash map's key.

Comment by frederickkaempfer [ 02/Nov/11 ]

Note that the demo probably only yields results on Mojarra versions up to 2.1.3 because of the recent fixes to http://java.net/jira/browse/JAVASERVERFACES-1751. However you could still retrieve the value if you issue a request at the right moment (for example by frequently polling for a specific higher sequence number) or if the flash is set to keep the value for more than one request. The fundamental problem lies in the application scoped map.

Comment by arjan tijms [ 16/Feb/12 ]

Another solution could be to (optionally) store flash data in the HTTP session and thus piggyback on the security of the JSESSIONID.

I just noticed the same thing was proposed as a solution for JAVASERVERFACES-1449, but as it appears some users are strongly against ever using the session for flash data:

I just contacted my user advocate at Garmin corporation, who advocated for a
"never use the session" option for the flash. I'll try to get a quote from them to
sway the EG.

Comment by frederickkaempfer [ 12/Apr/12 ]

A fix would be greatly appreciated, since this security issue currently prevents us from using the Flash scope.

One solution would be to use a GUID instead of a sequential number. Another solution could be to (optionally) store flash data in the HTTP session and thus piggyback on the security of the JSESSIONID.

Instead of replacing the sequence number with GUIDs completely, a GUID could also be added to the cookies value (by adding another separator char (X)) and saved in ELFlash's innerMap (either as part of the key or the value) or an additional Map.

The GUID the clients sends to the server then only needs to be verified by comparing it with the value stored in the map.

EDIT: I also wonder if the cookie could be set to HttpOnly and perhaps Secure (if sent over SSL)?

Another idea for a simple fix: Encrypt and decrypt the flash data similar to the view state using an instance of the ByteArrayGuard class.

Comment by Darious3 [ 06/Jan/13 ]

>Another idea for a simple fix: Encrypt and decrypt the flash data similar to the view state using an instance of the ByteArrayGuard class.

I hope this will get at least a simple fix like the above suggestion soon. For such a serious security issue this has been open for much too long.

Comment by Manfred Riem [ 08/Mar/13 ]

Can you verify if the latest 2.1 release is also affected?

Comment by frederickkaempfer [ 08/Mar/13 ]

Yes it is.

I have created a reproducer, where should I send it to?

Comment by Manfred Riem [ 08/Mar/13 ]

Please send it to issues@javaserverfaces.java.net. Please also let me know which specific version you tested. Thanks a bunch!

Comment by frederickkaempfer [ 08/Mar/13 ]

Done. Thanks for looking in to this. As a recap here is what needs to be done

1. Make the numeric values in the csfcfc cookie sufficiently random so they are not guessable (like UUIDs or session ids)
2. Make the cookie HttpOnly. There is no need for it to be modifiable in Javascript and it prevents XSS.
3. Make the cookie Secure if the connection is running over HTTPS.

I have tested with 2.1.20.

Comment by aschwart [ 23/May/13 ]

I sent some comments along the following lines in response to Manfred's email to the Mojarra dev list, but not sure whether everyone here is on that list, so pasting them here as well:

I wanted to suggest that we strongly consider re-parenting the Flash implementation on top of the HttpSession instead of re-inventing session-like functionality on top of Application.

We've discussed this on the expert group more than once, though I could only locate this thread in the archives:

https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-04/message/37

Arjan mentioned this above as well, along with some words of caution:

> arjan tijms added a comment - 16/Feb/12 12:35 PM
>> Another solution could be to (optionally) store flash data in the HTTP session and thus piggyback on the security of the JSESSIONID.
>
>
> I just noticed the same thing was proposed as a solution for JAVASERVERFACES-1449, but as it appears some users are strongly against ever using the session for flash data:
>
>> I just contacted my user advocate at Garmin corporation, who advocated for a
>> "never use the session" option for the flash. I'll try to get a quote from them to
>> sway the EG.

I don't remember seeing the follow up from this.

The case for avoiding HttpSession use would have be extremely compelling given that doing so means re-implementing much of the functionality provided by HttpSession at the JSF layer. JSF should be leveraging the underlying platform rather than replacing bits of it.

(Unfortunately I don't have much time to engage in further discussion on this until mid-next week, but wanted to at least share my thoughts before the implementation work gets going.)

Comment by kithouna [ 23/May/13 ]

The case for avoiding HttpSession use would have be extremely compelling

If the HTTP session is used, the use case for a "You have been logged-out" message on the page where a user is redirected to after a logout would not work anymore.

Comment by aschwart [ 24/May/13 ]

@kithouna - Can you provide more details about your use case? It sounds like you are saying that you required some user-specific state in order to display the logged-out message after invalidating the session. Is that right? What state do you need to display this message?

Comment by kithouna [ 24/May/13 ]

aschwart, it's not that special; in a backing bean I call request.logout and invalidate the session, then I set a faces message, and redirect to the home page. The home page will then say: "You have been logged-out".

This is a very minor, but still important use case. Yes, I could redirect with a ?logout=true request parameter, then have a bean at the index monitor that, and if it's there set the message. But that's just not as nice, and maybe sometimes you want the name of the user in there: "User Peter has been logged-out".

Another use case is much more fundamental; for a web application that's completely stateless and doesn't use sessions at all. Since JSF 2.2 this is now possible and maybe someone already build such a thing before JSF 2.2 and doesn't use forms but only h:links and such. For such apps flash is convenient to store some data that should not be bookmarked between pages.

Comment by aschwart [ 30/May/13 ]

Hi kithouna - sorry about taking so long to follow up. I was offline for a little vacation. Thanks for sharing your use cases.

For the "completely stateless" case, one thing that I am trying to wrap my head around is why storing Flash data at the Application level instead of in the HttpSession is a win. In either case, the app is stateful - ie. the app holds onto the same state across requests regardless of where this state is stored. Does the desire to avoid the HttpSession have to do with the fact that the session itself will stick around for some period after the Flash scope is cleared out? Would using a short session timeout be sufficient to alleviate this? Or is the concern that there is some other overhead that would be present when using the session that Mojarra currently avoids by implementing session-like functionality at the application level?

For the post-logout message/state case, there are some solutions/workarounds available (eg. use a request parameter), but, yeah, these do require doing more work at the app level.

My concern about re-implementing HttpSession-like functionality is that we are missing out on features that are implicitly provided by the app server, eg. Flash scope does not work well with clustering. In the completely stateless case (no HttpSession usage), we are not able to leverage session affinity, and thus might not be able to get back to the correct server (the server which has the current user's Flash data) when running behind a load balancer. Also, it seems like the Flash implementation would need to provide some alternative to the session timeout interval, or else run the risk of leaking Flash state (eg. in the event that no subsequent request ever arrives after storing some state in Flash scope).

My feeling is that Mojarra should provide a Flash implementation that works well with clustering/load balancing out of the box, without requiring any JSF-specific configuration, which I believe means using the HttpSession for storage of Flash data.

I'll leave it up to the Mojarra team to decide whether they think that this is reasonable requirement, and if so whether they want to address it here or via a separate issue.

Comment by kithouna [ 03/Jun/13 ]

Aschwart, I understand your case. Indeed, it's not that black/white.

You pose a very good question; if we go stateless, why keep some state in app scope? The reason is that one item in app scope is more fine grained. If you create a session it sticks around as long as the client keeps doing requests to the app.

Putting a single item in app scope is a one time thing; it is reaped when the client has consumed the item.

Maybe if we create a session (in case there's none) exactly when the Flash item is created, and kill the session when that Flash item is consumed, we would have roughly the same effect. But since session scope is shared by multiple windows it's more difficult.

Having essentially mini scopes (yes stateful) for every single flash item is more manageable I think, but I''m not the big expert on this topic. I agree that clustering is an issue here!

Comment by Ed Burns [ 10/Jun/13 ]

I think it would help to separate out the discussion on this issue into
two parts.

1. The original intent of the issues: making the Flash more secure

2. Whether or not flash depends on the session.

related issue:

https://java.net/jira/browse/JAVASERVERFACES-1449

Is it safe to separate these? If so, I can create a new issue for part
2.

If I don't hear anything in a few days, that's what I'll do.

Comment by Ed Burns [ 13/Jun/13 ]

LU> In my opinion, a random number generator like the one used in Apache
LU> Trinidad for its pageFlowScope is enough. The idea here is just make
LU> very difficult to guess the next number in the sequence.

I agree.

Comment by Ed Burns [ 21/Jun/13 ]

I just committed r12013 to the 2.1.x branch. I want to wait for it to clear and I will then forward port it to 2.2.x branch.

Then I'll go back and migrate the remaining flash tests to the new harness.

Also, I am ready to go to have a hudson job that runs the clustering tests. Manfred, how do you want to work that? Should we tack it onto existing jobs, or have new ones?

Ed

Comment by Ed Burns [ 22/Jun/13 ]

in progress. Encrypted value is unnecessary long.

Comment by Ed Burns [ 25/Jun/13 ]

checkpoint

Comment by Ed Burns [ 26/Jun/13 ]

Commit forward port when <http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_2_1X_ROLLING_DEPLOY/115/> and <http://slc03qna.us.oracle.com:7070/hudson/view/Mojarra%202.1/job/2_1_x-test-gf-3_1_2_2/261/> are clean.

Comment by Ed Burns [ 26/Jun/13 ]

Looks like forward port went in clean.

Comment by frederickkaempfer [ 27/Jun/13 ]

Hello Ed Burns,

great news that this bug is fixed! However one thing that is still missing is Cookie security:

  • If the request is secure (running over SSL) the Cookie should be set to secure. (Or else cookies from an https-only application will also be sent with every http request).
  • The cookie should be set to http only (because there is no reason it needs to be available to javascript, thus it prevents some XSS attacks).

This would just be a simple change in PreviousNextFlashInfoManager#encode and would bring the cookie security on par with the jsessionid cookie.

Thanks!





[JAVASERVERFACES-2112] sanity check function is not performed in Mojarra Created: 13/Jun/11  Updated: 26/Jun/12  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.0
Fix Version/s: 2.1.5, 2.2.0-m01

Type: Bug Priority: Major
Reporter: xj Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-2112.txt     Zip Archive TP004_003.zip    
Tags: licbug, security

 Description   

This is reported against Mojarra-2.1.0.

JSF specification does not clearly describe sanity check on request
and response data though it provides such mechanism through some tags,
e.g. the attribute escape of <h:outputtext>. The following phenomena
show that sanity check is not performed on current RI.

(a) Making an application that sets user's input data via EL on the
attribute contentType of <f:view>.

e.g.
<f:view contentType="#

{test.contentType}

">

If the input data from client side contains 2 linefeed code and
script, the script sent back to brower from HTTP response header can
be executed.

(b) In such an application that sets user's input data via EL on the
attribute of <?xml-stylesheet> in Facelets(xhtml page), script can be
executed if the input data from client contains script.

(c) One application that sets user's input data into comment "<!--
-->" in Facelets. Script can be executed if the input data from client
contains script.

This phenomenon can also be reproduced on JSP.

(d) We think the same issue also occur on the attribute "value" of
<h:outputLink> in Facelets. But we can not reproduce that yet since
data is encoded with URL encoding.



 Comments   
Comment by xj [ 04/Jul/11 ]

attached a test program.

Comment by xj [ 08/Aug/11 ]

Could you someone evaluate this issue?
Is it a defect?

Comment by xj [ 20/Sep/11 ]

It can be reproduced on Mojarra 2.1.2.

Comment by rogerk [ 14/Nov/11 ]

Changes. Thanks to Hitachi for the patch.

Comment by rogerk [ 14/Nov/11 ]

Fix versions

Comment by rogerk [ 14/Nov/11 ]

Tests fun fine with the patch.
I could not reproduce (could not get the script to execute) for the content type and link test
(I believe the pages were test_a.xhtml and test_d.xhtml). Same result for those with or without the patch. test_b.xhtml and test_d.xhtml work fine now.

Comment by rogerk [ 14/Nov/11 ]

Committed to MOJARRA_@_1X_ROLLING branch:
Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/el/ELText.java
Sending jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/HtmlResponseWriter.java
Sending jsf-ri/src/main/java/com/sun/faces/util/HtmlUtils.java
Adding jsf-test/JAVASERVERFACES-2112
Adding jsf-test/JAVASERVERFACES-2112/build.xml
Adding jsf-test/JAVASERVERFACES-2112/htmlunit
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com/sun/faces/systest/Issue2112TestCase.java
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/pom.xml
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun/faces/test
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun/faces/test/i_jsf_2112
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun/faces/test/i_jsf_2112/TestBean.java
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/test_b.xhtml
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/test_c.xhtml
Transmitting file data .............
Committed revision 9454.

Sending jsf-test/build.xml
Transmitting file data .
Committed revision 9455.

Comment by rogerk [ 14/Nov/11 ]

Will also commit to trunk

Comment by rogerk [ 17/Nov/11 ]

Checked into trunk:
Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/el/ELText.java
Sending jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/HtmlResponseWriter.java
Sending jsf-ri/src/main/java/com/sun/faces/util/HtmlUtils.java
Adding jsf-test/JAVASERVERFACES-2112
Adding jsf-test/JAVASERVERFACES-2112/build.xml
Adding jsf-test/JAVASERVERFACES-2112/htmlunit
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com/sun/faces/systest
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/java/com/sun/faces/systest/Issue2112TestCase.java
Adding jsf-test/JAVASERVERFACES-2112/htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/pom.xml
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun/faces/test
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun/faces/test/i_jsf_2112
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/java/com/sun/faces/test/i_jsf_2112/TestBean.java
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/test_b.xhtml
Adding jsf-test/JAVASERVERFACES-2112/i_jsf_2112/src/main/webapp/test_c.xhtml
Sending jsf-test/build.xml
Transmitting file data ..............
Committed revision 9457.

Comment by Multanis [ 06/Dec/11 ]

I've a undesired behavior (at least to me) using version 2.1.5 due to this fix:

If I've something like:

<script type="text/javascript">
<!--
alert("Hello world");
//-->
</script>

in my jspx/xhtml file, it is now rendered as:

<script type="text/javascript">
<!--
alert("Hello world");
//-->
</script>

which of course will not work. Same issue with something like:

<Unable to render embedded object: File (--[if lt IE 9]><div class="ie"><) not found.[endif]-->

To fix this I can wrap those kind of content with <f:verbatim> or with CDATA but I wanted to know if this is expected behavior or this is a bug ?

Thanks !

Comment by Multanis [ 06/Dec/11 ]

I cannot edit my comment but of course in my jspx/xhtml file, it is now rendered as:

 
<script type="text/javascript">
<!--
alert(&quot;Hello world&quot;);
//-->
</script>
Comment by rogerk [ 06/Dec/11 ]

This fix was put in to prevent malicious script execution in comments (for example).

Comment by arjan tijms [ 06/Dec/11 ]

I'm far from an expert here, but I would say that it's good if there's a protection for variables inside comments. As example C demonstrated this should be escaped:

<!-- #{test.comment}  -->

But if the page designer explicitly puts the following on the page, I don't think there should be any escaping:

<script type="text/javascript">
<!--
alert("Hello world");
//-->
</script>
Comment by rogerk [ 06/Dec/11 ]

Perhaps (in a later release) we could look at adding a configuration parameters to turn this on.

Comment by Multanis [ 06/Dec/11 ]

Ok, thanks for those precisions. Waiting for this config parameter I will wrap this kind of code into CDATA.





[JAVAEE_SPEC-22] Add JASPIC (Servlet Container Profile) to Web Profile Created: 02/Apr/13  Updated: 02/Apr/13

Status: Open
Project: javaee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: ldemichiel
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: authentication, portability, security

 Description   

From Java EE 6 on the JASPIC SPI describes how to integrate portable authentication modules into a Java EE server. Unfortunately JASPIC is not a part of the increasingly popular Java EE Web Profile, which greatly limits the true portability of those authentication modules.

Adding the Servlet Container Profile of JASPIC will not add any real new functionality to the Web Profile; Web Profile implementations are already mandated to implement authentication in some way following the requirements of mainly the Servlet specification. Instead, JASPIC will mainly standardize the way in which Web Profile implementations perform authentication and will make sure server authentication modules (SAMs) can be shared between Full- and Web Profile Java EE servers.

In order to increase portability and have a more consistent security model for the Java EE platform, I'd like to propose that the Servlet Container Profile of JASPIC be added to the Java EE Web Profile.






[JAVAEE_SECURITY_SPEC-19] Better integration between Servlet's auth-method, JASPIC's auth modules and realms/JAAS login modules/simple security providers Created: 11/Apr/14  Updated: 16/Mar/15

Status: Open
Project: javaee-security-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: alex.kosowski
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: authentication, security

 Description   

Via the Servlet spec, Java EE defines a number of pre-defined authentication mechanisms ("auth-methods"). An auth-method stands for a specific way that the server interacts with the user (via HTTP/HTML). The default auth-methods are: BASIC, FORM, CLIENT-CERT and DIGEST. For containers that support the Web Profile of JASPIC there's another option available where the user essentially provides a custom auth-method in the form of a JASPIC auth module.

Unfortunately the default Servlet auth-methods and the JASPIC custom one are not integrated or aligned in any way. This makes using these technologies needlessly confusing.

Specifically, using what is essentially a custom auth-method via JASPIC is done in either a server proprietary way, or programmatically in a rather non-obvious way. In both cases the presence of a custom JASPIC auth module will cause the auth-method declared in web.xml to be ignored. This is non-optimal.

A first step to make this all more clear and integrate the custom auth module with the existing pre-defined auth-methods could be to define a new auth-method "CUSTOM" and a corresponding element "auth-module-class", e.g.:

web.xml
<login-config>
    <auth-method>CUSTOM</auth-method>
    <auth-module-class>com.example.MyAuthModule</auth-method>
</login-config>

This in analogy to how e.g. the FORM auth-method is currently declared:

web.xml
<login-config>
    <auth-method>FORM</auth-method>
    <realm-name>file</realm-name>
    <form-login-config>
        <form-login-page>/login.xhtml</form-login-page>
        <form-error-page>/error.xhtml</form-error-page>
    </form-login-config>
</login-config>

(see http://docs.oracle.com/javaee/7/tutorial/doc/security-webtier002.htm)

Note that section 13.6.5 of the Servlet spec already recommends JASPIC to be implemented as the additional authentication mechanism, but neither mandates this nor gives any advise on how to integrate it with the enumeration of pre-defined mechanisms.

A second step could be to mandate that the pre-defined auth-methods are implemented and made available as JASPIC auth modules with a standardized class name, and that the container actually uses these to satisfy the requirements for the corresponding auth-methods. This solves a large number of issues with the Java EE security system, some of which implicit:

  • The standard auth modules can be stacked with custom auth modules (note there's no syntax to declare stacking in Java EE, but this can be done programmatically)
  • The standard auth modules can be extended by the user (like can be done in JSF with a number of standardized artifacts)
  • A large(r) number of JASPIC features have to be actually implemented in order to make the standard auth modules work (this in an implicit benefit, a TCK could also solve this)
  • JASPIC would be actually used in practice and not "just sit there" as a parallel and mostly unused mechanism (an implicit benefit that gives JASPIC implementations more practical test coverage)

Furthermore both the Servlet's auth-method and the JASPIC auth module (can) delegate the actual authentication to a "repository" that maintains the collection of users, their passwords and optionally their groups/roles. JASPIC defines a bridge profile where JAAS login modules are used for this. The Servlet spec however only has a rather weak definition of a concept that's alternatively called "realm" and "security policy domain"; an opaque name that is specified in the login-config element in web.xml and that may allow the user to somehow and in a proprietary way refer to the above mentioned user repository. Note that JAVAEE_SPEC-28 asks to standardize a number of these repositories.

Here too the Servlet's auth-method and the JASPIC auth module are not at all aligned. There's no standard way to let JASPIC auth modules use any of the available repositories (realms/security policy domains/security providers/...) offered by the container and there's no standard way to let a pre-defined Servlet auth-method make use of a JAAS login module in the way as specified by the JASPIC bridge profile.

As a third step to integration I would like to propose standardizing the above mentioned repositories using a modern Java EE centered API (e.g. not JAAS) and clearly defining how both the Servlet auth-methods and JASPIC auth modules delegate to these. If Servlet auth-methods and JASPIC auth modules are unified this is of course easier. This third step has strong ties with JAVAEE_SPEC-25 and JAVAEE_SPEC-28. E.g. xml based:

web.xml
<login-config>
    <auth-method>CUSTOM</auth-method>
    <auth-module-class>com.example.MyAuthModule</auth-method>
    <security-provider-class>com.example.MySecurityProvider</auth-method>
</login-config>

or annotation based:

@AuthModule
public class MyAuthModule implements ServerAuthModule {}
@SecurityProvider
public class MySecurityProvider {}


 Comments   
Comment by atrajano [ 10/Oct/14 ]

I sort of disagree with this approach as it blends authentication/authorization semantics into the application. In fact I would rather JASPIC APIs know what AUTH-METHOD is used (i.e. basic, form, etc and render accordingly.

Comment by arjan tijms [ 10/Oct/14 ]

I sort of disagree with this approach as it blends authentication/authorization semantics into the application.

I don't really get this. JASPIC auth modules can already be used in the application, and having authentication/authorization semantics into the application is not necessarily a bad thing. Spring Security and Shiro among others work at the application level.

But this proposal does not specifically ask to exclusively blend authentication/authorization semantics into the application at all. When the existing AUTH-METHODS are specified and implemented via the JASPIC SPI they can still be deployed container side, like all JASPIC auth modules can. In fact, since these modules are intended to ship with a container implementation they would have to be deployed container side by default.

In fact I would rather JASPIC APIs know what AUTH-METHOD is used (i.e. basic, form, etc and render accordingly.

Maybe there's some confusion here. A JASPIC SAM is not a rendering artifact like a JSF backing bean or so, but a module that takes care of the authentication itself, either container side or as option embedded into the application (the primary focus is on being installed at the container side). As such it makes little sense for JASPIC to only know the AUTH-METHOD, instead it has to implement it.

Comment by atrajano [ 10/Oct/14 ]

Actually I don't think Shiro and Spring are not really a good idea myself. Using Shiro I already hit a limit in that I have to manage the sessions across clusters myself rather than relying on the container. http://shiro.apache.org/session-management.html#SessionManagement-SessionClustering

However, I do agree there may be times when you'd want to specify the authentication system much like we do now (form based, basic, certificate). At the moment I haven't seen anywhere in the specs how to do this even programatically on an application level (the specs have it on the system level via AuthConfigFactory.getFactory() which returns the system factory the specs do not explicitly state that the factory is application specific so changing it there may imply changing it for all applications deployed on the server.

The "auth-method" should not be "CUSTOM" though. The name should be something more like "PROVIDER" and in addition to your suggestion, it should have the capability of setting properties as well that would map to the options of the ServerAuthModule.

Though there needs to be some declarative approach as well so aside from the class name it should provide an option to specify it by reference that can be overridden by container specific deployment descriptors.

Comment by arjan tijms [ 10/Oct/14 ]

... (form based, basic, certificate). At the moment I haven't seen anywhere in the specs how to do this even programatically on an application level

If you mean there's no way to set any of the standard auth methods/types programmatically, then this is indeed true. It's another inconsistency that would go away if the API was unified. As mentioned in the issue description, the standardized auth methods can only be set in web.xml while a custom method can only be set via JASPIC. You'd ideally want them all to be set via both methods.

the specs have it on the system level via AuthConfigFactory.getFactory() which returns the system factory the specs do not explicitly state that the factory is application specific so changing it there may imply changing it for all applications deployed on the server

Well, the factory is definitely not application specific, but for the entire server. If you register a SAM (via an AuthConfigProvider) and pass in a null as the third parameter of registerConfigProvider, then that SAM is registered for the entire server. It's extremely unlikely that a single application wants to do this, but that's the way the API/SPI is defined. However if you pass in the virtual server name (see http://arjan-tijms.omnifaces.org/2013/04/whats-new-in-java-ee-7s-authentication.html) then the SAM is only registered for that application.

Using a security manager you can prevent apps from doing this, but activating a security manager has severe performance implications for the entire application server.

The "auth-method" should not be "CUSTOM" though. The name should be something more like "PROVIDER" and in addition to your suggestion, it should have the capability of setting properties as well that would map to the options of the ServerAuthModule.

The name can be "PROVIDER" or anything else indeed. Most of the example code I post should be considered pseudo code which only serves to somewhat illustrate the proposal. It's of course not the exact way things should look like. And indeed, of course there should be options, and something to specify the request and response policies. Perhaps a better example would be the proprietary XML formats used by servers today to configure SAMs at the container side. (but note that most of them also include syntax for module stacking, which is not asked for in this issue)

Though there needs to be some declarative approach as well so aside from the class name it should provide an option to specify it by reference that can be overridden by container specific deployment descriptors.

Could be an option indeed. The approach that we're using in OmniFaces for component types is defaulting it to the class name. Meaning that in this case the element in the example above could be called e.g. auth-module-type, where you can then put the name com.example.MyAuthModule. If this name is not explicitly mapped at the container side it maps by default to a class with that name, otherwise to the class to which the name is mapped.





[JAVAEE_SECURITY_SPEC-10] Simplify and standardize authentication & role mapping Created: 27/May/12  Updated: 07/Jan/15

Status: Open
Project: javaee-security-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: alex.kosowski
Resolution: Unresolved Votes: 12
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: authentication, authorization, ease-of-use, jaspic, rolesallowed, security

 Description   

In Java EE declaring security constraints via e.g. @RolesAllowed, programmatically checking them via e.g. HttpServletRequest#isUserInRole and triggering a container login via HttpServletRequest#login is all relatively straightforward.

Unfortunately, providing the logic for the actual authentication and role mapping/retrieval remains a cumbersome exercise. This is especially painful for simple applications which don't need elaborate security abstractions. JASPI/JASPIC (JSR 196) did provide a means to make authentication modules portable in Java EE 6, but actually using those remains a fairly tedious and vendor specific process.

For instance, JBoss AS 7 requires the following steps:

  1. Create a named security domain outside the application in a vendor specific way, that's tied to a specific AS instance.
  2. Connect the JASPI authentication module to this security domain in a vendor specific way.
  3. Declare in web.xml that JASPI is the realm.
  4. Link the (web) application itself to the global security domain using a vendor specific descriptor.
  5. In the vendor specific descriptor, specify an internal vendor specific class name that's internally needed to activate JASPI.

(See https://community.jboss.org/wiki/JBossAS7EnablingJASPIAuthenticationForWebApplications)

GlassFish requires the user to take different, but similar steps including interacting with a graphical UI (see http://www-02.imixs.com/roller/ralphsjavablog/entry/openid_serverauthmodule_jsr_196_with)

Not only are these steps anti ease-of-use, they are also notoriously non-portable despite JASPI's promise of portability. Furthermore, having the authentication logic outside the application itself prohibits the developer to easily make use of application domain models and code for the authentication process (which is typical for applications that manage their users internally and don't need to integrate with an overall user directory system of e.g. an enterprise).

I therefor would like to propose standardizing how JASPI authentication modules can be embedded in (simple) applications in a portable way, and additionally address the use case that for small/test applications even a JASPI module is too much and something even simpler is needed. This is especially true when the application already makes use of a custom mechanism (typically a Servlet Filter) in combination with HttpServletRequest#login.

Example of simplified authentication/role mapping:

@AppLoginModule
public class MyAuthenticator implements PasswordLoginModule {

    private User user;

    @Inject
    private UserService userService;

    public void authenticate(String name, String password) {
        user = userService.getByNameAndPassword(name, password);
        if (user == null) {
            throw new FailedLoginException();
        }
    }

    public String getUserName() {
        return user.getName();
    }

    public List<String> getApplicationRoles() {
        return user.getRoles();
    }
}

Following the presence of such simplified login module in the application, the following should hold:

  • The application is considered to be in a default security realm.
  • The application will make use of this security realm (no explicit mention in web.xml required).
  • Whenever a container login is triggered, MyAuthenticator is used for authentication (only username/password supported of course)
  • If authentication succeeds, the String returned by getUserName will be what HttpServletRequest#getUserPrincipal.getName() and corresponding methods in EJB etc return.
  • For each String inside the list returned by getApplicationRoles, methods like HttpServletRequest#isUserInRole will return true, and annotations like @RolesAllowed referencing those will be considered satisfied.
  • No upfront declaration of roles in any descriptor is required.
  • The roles returned by getApplicationRoles should be directly useable in the application. Specifically, things as (vendor specific) group to role mappings (such as what happens in GlassFish) should not be required.

Example of standardized installation of a JASPI authentication module in application.xml or web.xml:

<server-auth-module>
    <class-name>my.example.HTTPBasicServerAuthModule</class-name>
    <property>
        <name>usersProperties</name>
        <value>somepath/users.properties</value>
     </property>
</server-auth-module>

Alternatively, the presence of a JASPI authentication module inside the application annotated with a special annotation (perhaps the same one as used for the simplified login module), can have the same effect of having the module automatically installed.

Like the simplified login module, when such a JASPI authentication module is declared in an application, no further configuration, role mapping or role declarations should be required, other than those that are specific for the authentication module itself.



 Comments   
Comment by perissf [ 21/Aug/12 ]

Arjan, I support your feature request, and would like to add my point of view. When developing a "Remember me" feature, the application needs to authenticate the user in the absence of a password. The same application, wants to authenticate with username & password on the first login attempt, and wants to have a container-managed authentication through HttpServletRequest#login. This is clearly not possible in the "Remember me" situation, unless the application stores the password somewhere in clear text. Or unless developing a custom authentication module. Please correct me if I am wrong.

Comment by rmonzillo [ 30/Aug/12 ]

common configuration of SAM's in compatible Servlet containers is something that JASPIC facilitates, but we need to give better guidance on how to accomplish that (by registering a common AuthConfigProvider at the target platform). The Glassfish RI includes the JAASServletAuthConfigProvider as one such AuthConfigProvider. We are creating examples of the portable use the JASPIC methodology under the Nobis Project see:
http://java.net/projects/nobis/sources/git/show/Nobis/authentication

I am still considering your proposal above, and I intend to comment further. Generally speaking I think that most of the pieces are in place to support the authentication aspects of your use case; but that we should consider how we might provide applications with interfaces to create application users and/or to assign them privileges (i.e., to roles). As part of our work on the Java Identity API interfaces we would like to make such interfaces available to java apps (although at the current time, our focus is mostly on lookup style interactions).

I also added a comment on the thread in the JBOSS forum see:
https://community.jboss.org/wiki/JBossAS7EnablingJASPIAuthenticationForWebApplications#comment-10581

regarding support for "remember me", we might consider adding a control flag to HttpServletRequest.login. However it would likely be sufficient to collect this control information as part of the authentication dialog with the user, and apply it in the underlying authentication mechanism. Moreover to facilitate that for FBL, we might consider defining a corresponding optional parameter to accompany j_username and j_password. Where we are using a jsr 196 sam for container authentication, the extraction of the indicated remember me effect from the HttpServletRequest messages could be handled by the pluggable auth module.

Comment by arjan tijms [ 10/Nov/12 ]

Ron, I've created a blog post about this very topic at: http://arjan-tijms.blogspot.com/2012/11/implementing-container-authentication.html

There I tried to programmatically register an example SAM on 4 different servers in a portable way. One of the major problems I run into is with the appContext. The spec certainly provides a definition for this for the Servlet Profile, but it's still not clear what an application doing registration should provide here. Different application server implementations also seem to want different things here. Most want "server [application context path]", but JBoss AS/EAP wants ["ServletRequest#getLocalName" [application context path]" here.

The other major problem is that every application server still insists on the user providing a proprietary deployment descriptor, mostly for things like role mapping and the specification of a domain/realm.

Above I asked that the roles returned by the proposed @AppLoginModule would be accepted without requiring to be mapped, but maybe we can go a step further and demand that the roles a JASPIC SAM puts into the JAAS Subject are useable without any required vendor specific mapping?

I think the ideal is that without any vendor specific deployment descriptor present (like WEB-INF/sun-web.xml), roles would be directly accepted. Then if there is such a deployment descriptor present, it can be used to optionally map some or all of the roles. Of course, it's at the vendor's discretion if further options are provided to e.g. completely turn off mapping or to mandate mapping for all roles, etc. This is fine, as long as those options are never the default for any application server.

The ultimate goal is to have basic security working without the need of any kind of vendor specific configuration, deployment descriptors, or whatever. Currently users having such requirements often just completely ignore Java EE security and implement their own solution based on ServletFilters and objects in the HTTP session. When the app grows to a point that it does need the more advanced things that Java EE security offers, it's a pain to replace the homegrown system.

That's why I think Java EE security (as a broad term), should also support the most simple and basic use case.

Comment by arjan tijms [ 06/Apr/13 ]

In the meantime I've prototyped a server auth module that approximately does what this issue asks at: http://code.google.com/p/omnisecurity/source/browse/src/org/omnifaces/security/jaspic/OmniServerAuthModule.java

Slightly abbreviated this will allow an application to define a class like the following that handles both the initial name/password authentication and the "remember me":

@SessionScoped
public class KickoffAuthenticator implements UsernamePasswordAuthenticator, TokenAuthenticator {

    @EJB
    private UserService userService;

    private User user;

    @Override
    public void authenticate(String name, String password) {
        user = userService.getUserByCredentials(name, password);
    }
    
    @Override
    public void authenticate(String loginToken) {
        user = userService.getUserByLoginToken(loginToken);
    }

    @Override
    public String generateLoginToken() {
        return userService.generateLoginToken(user.getEmail());
    }
    
    @Override
    public void removeLoginToken() {
        userService.removeLoginToken(user.getEmail());
    }    

    @Override
    public String getUserName() {
        return user.getEmail();
    }

    @Override
    public List<String> getApplicationRoles() {
        return user.getRoles();
    }

    @Produces @Named("activeUser")
    public User getUser() {
        return user;
    }
}

In broad lines it follows the approach outlined by Ron above, but instead of j_username, j_password and a new optional parameter, it works with a programmatic HttpServletRequest#authenticate call that passes there parameters via request attributes. This approach works better for a JSF environment, but for JSP/HTML & Servlet apps an additional parameter next to j_username, j_password for the standard FORM based authentication would surely be needed as well.

The SAM I prototyped assumes the user has a service available to retrieve the credentials from by name/password (as in the original proposal), as well as (optionally) a service that can do the same thing for "tokens" that are used for the "remember me".

As of the major problems mentioned above, the appContext issue has been solved by Ron in JASPIC MR2 via JASPIC_SPEC-1.

I've created JAVAEE_SPEC-20 to address the most problematic aspect of the required proprietary deployment descriptor.

A very practical problem I encountered when prototyping the above solution is that CDI and the JNDI component namespaces (java:comp etc) are not setup when a JSR 196 SAM is called before a resource invocation. For this I've created JASPIC_SPEC-14.

Comment by alex.kosowski [ 13/Aug/14 ]

Hi Arjan,

For EE 8, we are adding a new JSR focusing on making the Security API simpler and more portable.

We are trying to determined whether we should standardize something like the simple authenticator UsernamePasswordAuthenticator you suggested. A question that came up was: Would a "typical" app developer using "simple" authentication really want to implement the authenticate method? It seems username/password or token authentication would be a service that an app developer would want the server to handle. How would an application domain model change the typical username/password verification?

Is the real driver behind a simple authenticator API the ability to have an app manage its own users, groups, and roles dynamically? What if we added portable APIs for user, group, and role management? Would that eliminate the "typical" need for an app developer to implement an authenticator?

That said, there are obviously special authentication mechanisms beyond username/password that an application may want portable access to. Perhaps improvements to JASPIC to fix the portability problems would be the way to address the broader authentication API.

But, for the "simple" case, would adding the following APIs address the need for a simple authenticator?

1. Standardized User Service API, with:

  • CRUD operations on Users
  • CRUD operations on Groups (of Users)
  • Ability to declare (annotation, DD) that a User Service instance is to be used by the server for authentication within the application
    2. Standardized Role (Authority) Service API, with
  • Ability to assign Users or Groups to roles
  • Conditional assignment, of Users or Groups to roles, based on Boolean EL expressions
  • Ability to declare one-to-one Group to Role mapping
  • Ability to declare (annotation, DD) that a Role Service instance is to be used by the server for authorization within the application

No surprises here, as this is reflecting suggestions made in this and other JIRAs. But does the ability to manage users, groups, roles achieve the goal desired by implementing "KickoffAuthenticator"? It seems the value of this authenticator is in the KickoffAuthenticator.getApplicationRoles(). It seems KickoffAuthenticator.authenticate() would be boiler-plate code.

A concern with requiring applications to implement UsernamePasswordAuthenticator.authenticate() is it provides an opportunity for insecure code and vulnerabilities.

Please respond with your thoughts.

Thanks,
Alex

Comment by arjan tijms [ 13/Aug/14 ]

For EE 8, we are adding a new JSR focusing on making the Security API simpler and more portable.

This by itself is really good news

Would a "typical" app developer using "simple" authentication really want to implement the authenticate method?

I think the answer to this would be "yes" when looking at how often I've seen developers do this. Because Java EE doesn't offer anything to help them with this, I'd mostly see them avoiding Java EE security completely and just implementing something using Servlet Filters.

It seems username/password or token authentication would be a service that an app developer would want the server to handle.

The problem with this is that those usernames and passwords for simple applications are not in the server, and that the way the server handles this is different for each and every server. This makes it incredibly hard to explain how one should do this task in "Java EE". Instead, one has to explain that one part is done using Java EE code, and the other part is done using JBoss code. But then the user happens to be using Hitachi Cosminexus, and who knows how proprietary login modules are configured for Hitachi Cosminexus?

There's a similar problem with doing cloud deployments, where often everything has to come from the war (or ear) and there's no option to configure anything at the side of the server.

How would an application domain model change the typical username/password verification?

An application often has a number of domain entities. E.g. for an online advertising application there could be an Advertisement which is owned by an Advertiser. Such an Advertisement can be put on a Website owned by a Publisher.

In such application, Advertiser is a user who can register with the system and then login. Same goes for Publisher.

It's thus an impediment if authenticating can only be done via users that are somehow magically present inside some store managed by the application server, since those users are primarily entities that exist within the application. They register with the application via a webpage that's integrated with the main application.

Application server vendors have long recognized this particular use case, since many of them come with "DatabaseLoginModules". This often boils down to pointing such login module with vendor specific configuration to the same database that happens to store the above mentioned users, and then fabricate a (SQL) query via which a username and (hashed) password can be extracted from the table(s) that store those users.

This often means that the data source has to be defined twice, and there has to be separate logic, often even separate from the application code, that has to have internal knowledge of how the user is mapped to the database tables. If the application changes the user layout, this query will break.

That said, there are obviously special authentication mechanisms beyond username/password that an application may want portable access to.

Absolutely, hence the idea to have a couple of interfaces for a small and finite number of well known use cases. If the application's need can not be met by using once of those, then there's always full blown JASPIC which by virtue of its immensely generic API could theoretically do "anything".

Perhaps improvements to JASPIC to fix the portability problems would be the way to address the broader authentication API.

For sure, and maybe even up to the point that having the simplified authenticator might be less needed.

Basically, having a SAM registrable via a simple annotation instead of having to go through 4 factories, having CDI and Java EE component namespaces available in it, and providing a convenience base class and methods (see JASPIC_SPEC-17 , HttpMsgContext and HttpServerAuthModule) could come a long way.

  • CRUD operations on Users
  • CRUD operations on Groups (of Users)

If you mean low level CRUD operations, then I'm not so sure about this. There's JPA and EJB for that after all. If you're talking about a specific API for CRUD operations on whatever "user repository" that is used by a SAM or LoginModule, then this may be an interesting feature to look at. However, I think not all repositories are able to support CRUD operations easily. In-memory, .properties, database and LDAP probably can, but OAuth (Facebook, Twitter etc) probably can't.

I'm afraid it also still wouldn't solve the case where the user that's logging in is primarily an application entity. If I understand what you mean with "CRUD operations" correctly, then an application would always have to call two APIs. E.g. when creating a user it would have to call both JPA and this new API, just so the authentication system also knows about the new user. In such case transactions are critical, but this will probably make the entire thing way more complicated, both for implementors of the spec as for users of the spec.

Ability to declare (annotation, DD) that a User Service instance is to be used by the server for authentication within the application

What would the interface of such User Service look like? Wouldn't this basically be the same as the interface proposed here and in JAVAEE_SPEC-25? E.g. a service where you call a method and pass in a username and password, and get back a "user" represented by a name and set of roles. Essentially it's a simpler and more modern version of the JAAS LoginModule.

Ability to assign Users or Groups to roles

This is like the CRUD operations on Users, right? There may be some merit here for some applications and some "repositories", but I don't think this will solve the general case. I think the general case is that the application has already stored users and role associations in some format using whatever existing API (JDBC, JPA, etc). In that case it doesn't need a new API to store anything, but just a way to return a name + roles to Java EE.

What I think you are proposing (correct me if I'm wrong) is another persistence API (next to JDBC and JPA among others) specifically tailored for storing Users, Groups and associations between these two. While it could indeed be handy to have a universal API for these things for say LDAP when there's an LDAP login module configured, or to an XML file when there's some XML file based login module configured, I think it's solving a different (and rather complex) problem.

A concern with requiring applications to implement UsernamePasswordAuthenticator.authenticate() is it provides an opportunity for insecure code and vulnerabilities.

But isn't that the same opportunity that's there now when applications implement a full blown JASPIC SAM? And simple applications will now most of the times implement something much worse in a Servlet Filter.

The idea is that simple applications could start with implementing something like UsernamePasswordAuthenticator.authenticate(), and could then later on fairly transparently swap it out for a more secure implementation (of which the Java EE standard could provide a number of default ones like proposed by JAVAEE_SPEC-28).

All in all I think it might be a good idea to get all the separate ideas together once this new security JSR has really started in a kind of big picture issue, e.g.

  • JASPIC SAM as the clear overall authentication module that takes care of the user interaction/message dialog (among others JAVAEE_SPEC-22)
  • Existing authentication methods implemented as JASPIC SAMs (see also JAVAEE_SPEC-37)
  • Several simplifications / easy of use improvements for SAMs (among others JASPIC_SPEC-17)
  • Simplified interface for just bare authentication that a standard SAM can call in addition to the existing JAAS LoginModule (this issue and JAVAEE_SPEC-25, see also JASPIC bridge profile)
  • Several default implementations of this simplified interface for the most common cases (JAVAEE_SPEC-28)
  • Standardized group to role mapping (JAVAEE_SPEC-20)
Comment by alex.kosowski [ 18/Aug/14 ]

Hi Arjan,

Thanks for your prompt response.

Let me explain the UserService and RoleService a bit.

UserService is an application-scoped service for an application to manage its own users. User data would be supplied by a UserSource, which may point to an application-supplied persistence store or the server user store. This user collection may be completely independent from the server users, or may be the same, depending on configuration. The components may look something like this:

UserInfo <-> UserService <-> UserSource <-> {some user source}

UserInfo properties:
+ Username
+ Password
+ AccountExpired
+ AccountLocked
+ PasswordExpired
+ Enabled
+ Attributes

UserService operations:
+ UserInfo:loadUserByUsername(username)
+ changePassword
+ createUser
+ deleteUser
+ updateUser
+ userExists
+ createGroup
+ addUserToGroup
+ removeUserFromGroup
+ isUserInGroup

Standardized UserSource types:
LdapUserSource: Points to an application supplied LDAP server
ServerUserSource: Bridges to the server users
Jsr351UserSource: Bridges to the JSR 351 Identity API
DataSourceUserSource: Points to an application supplied DataSource
MemoryUserSource: Code-embedded users, or read from file (JSON, XML, or Properties)
CustomUserSource: Application definable

Usage:

@LdapUserSourceDefinition(name=“java:app/prodUserSource”, ldapUrl=“ldap://blah”, ldapUser=“ElDap”, ldapPassword=“#{ALIAS_LDAP}”)

public class MyAuthenticator {	
  @Resource(lookup=“java:app/prodUserSource”)	
  private UserService userService;	
  private boolean isAccountEnabled(String username) {		
    return userService.loadUserByUsername(username).isEnabled();	
  } …
}

The UserSource would be defined as a resource. The UserService would be a persistence API for storing Users, Groups, and associations, however the underlying repository may be application supplied. The users supplied by the UserService would be local to the application, however multiple applications could access the same user repository to share users.

We could have a read-only and read-write version of UserService, or otherwise determine the capability of a UserService. That is, some repositories are read-only. Also, we may split out the Password into a separate service/repository.

The UserSourceDefinition annotation would be the default, overridable via standard deployment descriptor, and programmatically via standard APIs.

=======

RoleService would have a similar architecture as the UserService. RoleService would also be a resource, and defines role mappings local to an application, but may be configured to use the server role mapper. The components may look something like this:

RoleService <-> RoleMapper <-> {some role mapper}

RoleService operations:
+ grantRoleToUser(username, role)
+ revokeRoleFromUser(username, role)
+ hasRoleForUser(username, role, includeGroups)
+ getRolesForUser(username, includeGroups)
+ getUsersWithRole(role, includeGroups)
+ grantRoleToGroup(group, role)
+ revokeRoleFromGroup(group, role)
+ hasRoleForGroup(group, role)
+ getRolesForGroup(group)
+ getGroupsWithRole(role)

Standardized RoleMapper types:
LdapRoleMapper: Points to an application supplied LDAP server
ServerRoleMapper: Bridges to the server role mapper
MemoryRoleMapper: Code-embedded role mappings, or read from file (JSON, XML, or Properties)
DataSourceRoleMapper: Points to an application supplied DataSource
CustomRoleMapper: Application definable
GroupIsRoleMapper: Role is one-to-one mapping to user group

Usage:

@MemoryRoleMapperDefinition(
  name=“java:app/devRoleMapper”,	
  users={
    @RoleMap(user=“foo”,roles=“admin”),		
    @RoleMap(group=“admin”,roles={“admin”,”staff”})
  } 
)
public class MyServlet {
  @Resource(lookup=“java:app/devRoleMapper”)
  private RoleService roleService;
  private List<String> getRoles(String username) {
    return roleService.getRolesForUser(username,true);
  }
  …
}

The RoleMapperDefinition annotation would be the default, overridable via standard deployment descriptor, and programmatically via standard APIs.

=======

Finally, the application server discovers which UserSource and RoleMapper to use for an application by processing the Authenticator annotation:

@Authenticator(userSourceName=“java:app/prodUserSource”,roleMapperName=“java:app/OneToOneRoleMapper”)

The Authenticator annotation would apply to the application scope, be overridable via standard deployment descriptor, and be overridable programmatically via standard APIs.

=======

The UserService and RoleService attempt to provide simple and portable user and role management to applications.

Regarding:

It's thus an impediment if authenticating can only be done via users that are somehow magically present inside some store managed by the application server, since those users are primarily entities that exist within the application.

Applications would be able to bind their own user repositories into a server's authentication process for that application. The "simple" authenticator API could just be the @Authenticator annotation. More advanced/custom authentication mechanisms could use JASPIC, which as you mentioned, needs some work.

Regarding:

I think the general case is that the application has already stored users and role associations in some format using whatever existing API (JDBC, JPA, etc). In that case it doesn't need a new API to store anything, but just a way to return a name + roles to Java EE.

The UserService, Role Service, and binding Authenticator could be a way to do that.

Please respond with your thoughts.

Thanks,
Alex

Comment by arjan tijms [ 18/Aug/14 ]

Thanks a lot for the thorough explanation. There are a lot of interesting ideas there.

I do think it's especially important to establish some terminology and to take a look at how all individual ideas come together as a whole.

Specifically there are two concepts that often come up and actually exist, but haven't got real clear distinguishing names:

  • The (user) interaction method via which credentials are obtained (form, basic, etc)
  • The store where users/callers and optionally the group/role data resides.

The first item is what's more or less called "auth-method" in the Servlet spec, and "auth module" in the JASPIC spec. The second item is very indirectly called "realm" in the Servlet spec, but you'll often see the terms "repository" and "store" as well. JASPIC (optionally) delegates this functionality to a JAAS "LoginModule". JAVAEE_SPEC-28 calls these "security providers".

The reason I'm bringing this up here is that if I understood correctly this second item corresponds to what you call a "UserSource" and a "UserService" (and in the running text refer to using "repository")

A second issue, directly related to the above is that I'm wondering what the difference is between a UserSource and a UserService. In the example code they seem to be the same thing. There, a variable of type UserService is injected with a UserSource:

@Resource(lookup=“java:app/prodUserSource”)
private UserService userService;

One thing I'm missing in the examples and API is a way to retrieve the groups/roles. This information is not in your UserInfo and the LdapUserSourceDefinition doesn't show any attribute used to hold the groups/roles query.

In practice, there are often two queries defined for repositories. Eg for both SQL/DB and LDAP repositories you define one query to obtain just the user and another one to obtain the roles associated with a user. Some repositories, like a file based one, have their own internal format to store both users and their roles and no separate queries are needed. Yet other repositories, such as the increasingly popular OAuth based ones (Facebook, Twitter, ...) don't return roles at all (the app typically stores roles locally instead).

As for the RoleMapper examples, here too I wonder what the difference is between the RoleMapper and RoleService; they seem to be the same thing as a RoleService variable is injected with a RoleMapper.

I also wonder if LDAP can actually be used for (local) role mapping. It's sure used for role retrieval, but is it really used for local application role mapping? I don't think I've ever seen that.

Finally, we may consider if the terms "group" and "role" are really needed. As you of course know, there's a third level of role mapping possible between the global application level roles and the roles of a single Java EE component (EJB bean or web module). There both source and target keeps using the term "role". I recognise that "group to role mapping" is an existing and reasonably well known term, but going forward with simplifying security it might be worth it to reconsider if those two terms are really needed.

The problem I'm seeing is that in practice people dream up all kinds of fancy semantics related to the terms "group" and "role", thinking group is really like a group in normal English, while a role is more akin to a right, and what have you. Never ever have I seen anyone who intuitively understood that "group" is the "thing" returned by the auth module/login module and "role" is the "thing" after the mapping as required by some servers.

With standardised role mapping one thing in favour of keeping the group / role terms though is that people could now start using it as the names intuitively imply; coarse grained / fine grained permissions.

Well, just something to think about

As for the authenticator example as given below:

@Authenticator(userSourceName=“java:app/prodUserSource”,roleMapperName=“java:app/OneToOneRoleMapper” )

I think there are a few things to remark here.

Given the above mentioned distinction between the auth "method" and the "repository", I think the first one should be put here too. The method is after all not an alternative to the repository but a higher layer in a way; the method may decide not to call into a repository, but a repository always needs to be called by a method.

A small cosmetic thing is that in JNDI it's a kind of de facto standard that "name" is an overloaded mess that both sets a name when a resource is defined and injects a name into the ENC (if any) when referenced. For referencing an existing name "lookup" seems to be more common.

Another thing is that while for the example OneToOneRoleMapper is great, in practice I think this could better be the default for this kind of ease of use facility.

Finally, I wonder if the API for this annotation would not be better off using CDI names and/or qualifyers instead of or in addition to JNDI.

Anyway, keeping JNDI and the default role mapper it would then be something like this:

@Authenticator(
authMethodLookup="java:app/prodAuthMethod",
userSourceLookup=“java:app/prodUserSource”,
roleMapperLookup=“java:app/OneToOneRoleMapper” )

In this example java:app/prodAuthMethod would refer to a configuration of a JASPIC module or one of the standard auth methods (like FORM). Bonus points for if there would not be a difference between those two and FORM was just a standardised JASPIC module.

We now have the method which uses eg a form to get a username and password from the actual user, we have a userSource that retrieves the user (and presumably the roles) and we tell the server to use the roles directly.

There's now just one thing missing (apart from the role retrieval mentioned above); what code is responsible for comparing the submitted password against the actual password? This has to be custom code too, as in general the server cannot assume any specific format or hash method/salt etc of the password (or any other type of credential).

Comment by alex.kosowski [ 09/Sep/14 ]

I'm wondering what the difference is between a UserSource and a UserService

The UserSource would be an adapter between the repository and the UserService. We would standardize UserSource implementations for various repository types (LDAP, DataSource, etc). The UserService would provide user operations, delegating repository access to the UserSource. I suppose we could simplify and merge UserSource and UserService, perhaps standardize some service helper methods.

One thing I'm missing in the examples and API is a way to retrieve the groups/roles.

Sorry, missed that in the reply. Groups are just groups of users, with no authorization semantics without RoleService. To get groups from UserService:
boolean isUserInGroup(String username, String group);
List<String> getUserGroups(String username);

Roles provide authority. To get role from RoleService:
boolean hasRoleForUser(String username, String role, boolean includeGroups);
List<String> getRolesForUser(String username, boolean includeGroups);
List<String> getUsersWithRole(String role, boolean includeGroups);
boolean hasRoleForGroup(String group, String role);
List<String> getRolesForGroup(String group);
List<String> getGroupsWithRole(String role);

Note that the GroupIsRoleMapper would represent groups as roles.

there are often two queries defined for repositories

I would expect the standardized LDAPUserSource, DataSourceUserSource, etc, would be configurable for apps to declare queries for specific required operations.

Yet other repositories, such as the increasingly popular OAuth based ones (Facebook, Twitter, ...) don't return roles at all (the app typically stores roles locally instead).

UserService would be meant for applications to manage users. For OpenID Connect user repositories, I would expect a JASPIC SAM to cover that.

I wonder what the difference is between the RoleMapper and RoleService

Yup, perhaps we should simplify this terminology and just have RoleService implementations.

I also wonder if LDAP can actually be used for (local) role mapping. It's sure used for role retrieval, but is it really used for local application role mapping? I don't think I've ever seen that.

I was not sure if that was actually used, although I think it is possible. No need to standardize an uncommon use case.

One idea we were considering was having role mapping be rule based. We could have the role mapping rules be based on EL, incorporating managed beans. We could store the rules inline or externally in file or LDAP. The rules would be evaluated before authorization decisions.

I recognise that "group to role mapping" is an existing and reasonably well known term, but going forward with simplifying security it might be worth it to reconsider if those two terms are really needed.

Group to role mapping arguably is needed for deployments where the enterprise is using applications developed by a third party. The mapping allows application authorization roles to be assigned from enterprise users. The one to one role mapper would provide a simplification for applications not requiring the mapping. I am not sure how to get away from role mapping and still accommodate the common Java EE security use cases.

Another thing is that while for the example OneToOneRoleMapper is great, in practice I think this could better be the default for this kind of ease of use facility.

Agreed

I wonder if the API for this annotation would not be better off using CDI names and/or qualifyers instead of or in addition to JNDI.

I think using JNDI is the current standard for referring to resources. Although CDI seems like the "hammer for everyone's nail", I could not find any standards for using CDI names to refer to resources.

@Authenticator(
authMethodLookup="java:app/prodAuthMethod",
userSourceLookup=“java:app/prodUserSource”,
roleMapperLookup=“java:app/OneToOneRoleMapper” )

I agree with this. authMethodLookup would make sense if JASPIC were updated to be configurable with standardized SAMs. The absence of authMethodLookup infers the currently determined authmethod (e.g., via web.xml) would use the specified UserSource and RoleMapper for authentication within the application.

what code is responsible for comparing the submitted password against the actual password? This has to be custom code too, as in general the server cannot assume any specific format or hash method/salt etc of the password (or any other type of credential).

Since the UserService internally hashes/encrypts the password, I think the UserService should encapsulate that decision. For example, we could remove the Password attribute from UserInfo and add a UserService operation which would encapsulate the password check, like:
boolean isValid( username, password )

That said, we are also considering separating Password into a separate service: PasswordService or CredentialService. This would facilitate having a separate, more secure credential repository.

Comment by arjan tijms [ 06/Oct/14 ]

UserService would be meant for applications to manage users. For OpenID Connect user repositories, I would expect a JASPIC SAM to cover that.

Hmmm, hopefully it will be possible to come to an abstraction where there will be no need for one group of authentication methods to have a different API/SPI.

Group to role mapping arguably is needed for deployments where the enterprise is using applications developed by a third party.

Yes, of course. But that wasn't what I meant Group to role mapping is a key requirement for the above use case and definitely shouldn't be done away with. What I meant is that the term group may not be necessary and could just be called role as well.

E.g. we now have:

Term Meaning
Group Organization wide role
Role Application wide role
Role ref Component wide role

The term group specifically is a source of confusion. People dream up all kinds of meanings for it, EXCEPT the meaning "organization wide role". I wasted so many hours trying to explain to different developers and in the end I think they still felt that group meant something else than it actually means.

group is also not entirely consistently used. JASPIC recognizes the term and uses it in its API/SPI but JACC does not.

Role ref is a problematic term too, but in practice not a big issue since it defaults to Role anyway and I think in practice people don't really use it (correct me if I'm wrong).

Although longer, I feel calling the process something like "organization role to application role mapping" or somewhat shorter "organization to application role mapping" is quite a bit clearer. Alternatively, "global" could be used instead of "organization" as well, and "application" could be abbreviated leading to: "global to app role mapping". The new role hierarchy (wrt terminology) could then become:

Term Meaning
Global role Organization wide role
Application Role Application wide role
Component Role Component wide role

I could not find any standards for using CDI names to refer to resources.

CDI beans can be explicitly named (@Named annotation in user code, or the getName method in the Bean type for extensions).
More common would however be the usage of bean types (i.e. Java interfaces) and/or qualifiers, which is a type safe approach.

I think the UserService should encapsulate that decision.

Should applications always subclass the UserService then, or do you envision a configurable choice of some well known standard hash/encrypt methods and a subclass or plug-in type if the algorithm the user uses is not among the standard choices?

Comment by yosshi2008 [ 27/Nov/14 ]

In order to create the application with more strong user authentication,
we would like to insert the password as SSHA(Salted SHA).
And there was no way to implement it as standard.
(It depends on the Application Server.)

Thus could you also consider to implement the API which support the SSHA ?
I assume that It may be influence following API.

UserInfo properties:

+ Password

+ Attributes

UserService operations:

+ UserInfo:loadUserByUsername(username)

+ changePassword

+ createUser

+ updateUser

+ addUserToGroup






[JAVAEE_SECURITY_SPEC-8] Standardize group to role mapping Created: 13/Feb/13  Updated: 07/Jan/15

Status: Open
Project: javaee-security-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: alex.kosowski
Resolution: Unresolved Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: deployment, descriptors, ease-of-use, ease_of_development, portability, security

 Description   

Many Java EE implementations (but not all), require a process that's often called "group to role mapping". The idea here is that authentication/login modules (either proprietary or the standardized JASPIC SAMs) never return "roles", but return "groups". A deployer then maps the roles that the application uses to the groups that the authentication module returns.

This mechanism is useful for when a single authentication module is used to provide security for a number of different applications that each use different names for the same logical role. The way this group to role mapping is done is almost the same for every Java EE implementation, but uses incompatible syntax in proprietary deployment descriptors.

For instance, mapping a single role for GlassFish, WebLogic, WebSphere and Geronimo looks as follows:

GlassFish 3.1.2.2
WEB-INF/sun-web.xml 

<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" 
    "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
<sun-web-app>
 
    <security-role-mapping>
        <role-name>architect</role-name>
        <group-name>architect</group-name>
    </security-role-mapping>
 
</sun-web-app>
WebLogic 12c (12.1.1)
WEB-INF/weblogic.xml 

<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app.xsd"
    xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
 
    <security-role-assignment>
        <role-name>architect</role-name>
        <principal-name>architect</principal-name>
    </security-role-assignment>
 
</weblogic-web-app>
WebSphere 8.5
[EAR]/META-INF/ibm-application-bnd.xml 

<application-bnd xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-application-bnd_1_1.xsd"
    xmlns="http://websphere.ibm.com/xml/ns/javaee"
    version="1.1">
 
    <security-role name="architect"> 
        <group name="architect" />
    </security-role>
     
</application-bnd>
Geronimo v3.0
WEB-INF/geronimo-web.xml 

<web:web-app
    xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0"
>
 
    <sec:security>
        <sec:role-mappings>
            <sec:role role-name="architect">
                <sec:principal
                    class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
                    name="architect"
                />
            </sec:role>
        </sec:role-mappings>
    </sec:security>
     
</web:web-app>

Having a different syntax for basically the same thing hurts portability and makes it unnecessarily difficult for a Java EE developer to transfer his or her skills to a different Java EE implementation.

Further more, although role mapping can be an essential feature for some use cases, it can be totally unnecessary for others. If there's nothing to map, then requiring the developer to provide a group to role mapping anyway isn't exactly following the ease-of-use theme that Java EE 5 started.

I would therefor like to propose the introduction of a standardized syntax for group to role mapping with the special case of a standard way to declare that no such mapping should be done.

Standardized group to role mapping can possibly take advantage of the existing security-role-ref in deployers such as web.xml.

E.g.: when the full double indirection is used:

<security-role-ref>
    <!-- Role name as set/returned by Authentication Module -->
    <role-group>Management</role-group>

    <!-- Role name for mapping -->
    <role-name>MGR</role-name>
    
    <!-- Role name used in code -->
    <role-link>manager</role-link>
</security-role-ref>

When single indirection is used:

<security-role-ref>
    <!-- Role name as set/returned by Authentication Module -->
    <role-group>Management</role-group>

    <!-- Role name used in code -->
    <role-name>MGR</role-name>
</security-role-ref>

When no indirection is used:

<security-role-ref groupToRoleMapping="false" />

The last fragment could become the default to be more consistent with the situation when no role-link is used (e.g. a developer also doesn't have to explicitly specify that a "roleToLink" mapping should not be done).

Optionally the two steps of role mapping could be separated as follows:

<security-role-ref>
    <!-- Role name as set/returned by Authentication Module -->
    <role-group>Management</role-group>

    <!-- Role name for mapping -->
    <role-name>MGR</role-name>
</security-role-ref>

<security-role-ref>
    <!-- Role name for mapping -->
    <role-name>MGR</role-name>
    
    <!-- Role name used in code -->
    <role-link>manager</role-link>
</security-role-ref>

An additional benefit of standardized group to role mapping could be that it can automatically take advantage of the configuration efforts done in Java EE 8 (see also JAVAEE_SPEC-19).



 Comments   
Comment by arjan tijms [ 20/Feb/13 ]

Note that in the security-role-ref samples above I accidentally switched role-name and role-link (unfortunately it's not possible to edit your own issue's description).

The assumption was also that the security-role-ref element would be re-used outside the servlet element, but on second thought that's perhaps not really clear and it would be better to introduce a new element.

The given syntax at any length is of course just an example, the key requirement is that role mapping is standardized (in whatever way) and there's the option to turn role mapping completely off (in whatever way).

Comment by arjan tijms [ 04/May/13 ]

Example of people running into this issue: http://stackoverflow.com/questions/2230717/dynamic-roles-on-a-java-ee-server

For the particular use case described in that link it's not only important that an application can indicate there's no mapping required, but also that roles don't need to be declared upfront. Indeed, if the main reason for declaring roles upfront is to the make the job of the person who does role mapping easier, then this too will not be needed if there's no role mapping at all.

Comment by alex.kosowski [ 13/Jun/14 ]

I understand the point that group-to-role mapping should not be required for simple cases where groups and roles map one-to-one.

However, regarding "dynamic" roles:

1. Are you referring to applications being able to change roles of users during runtime? Would a Java EE API allowing applications to create users and change roles assigned satisfy this?

OR

2. Are you referring to consuming dynamic roles in the authorization checking? That is, not requiring all roles declared upfront (via web.xml or @DeclareRoles) and conditioning the authorization on the result of a calculation using an arbitrary role name?
For example:
The application assigns roles like <Customer>_ADMIN or "ACME_ADMIN" and the authorization logic is like this pseudocode:
if ( isAuthorized( subject.getRole().contains( "_ADMIN" ) ) )

{ // Do privileged stuff }

Is this a common use case? Would you please provide a use case for this?

Thanks,
Alex

Comment by arjan tijms [ 14/Jun/14 ]

Are you referring to applications being able to change roles of users during runtime? Would a Java EE API allowing applications to create users and change roles assigned satisfy this?

Although that wasn't what I meant with the above, that functionality is most definitely needed as well. I created a separate issue some time ago for that: JASPIC_SPEC-22

That is, not requiring all roles declared upfront (via web.xml or @DeclareRoles) and conditioning the authorization on the result of a calculation using an arbitrary role name?

Yes, that's it

Would you please provide a use case for this?

There are actually two use cases for this.

The first is about convenience and simplifications. The problem here is that "registering things in XML" is a kind of universal pain that Java EE users have had to endure, and I'm convinced it's one of the things that gave Java EE a bad name. JSF users had to register components, converters, validators and what have you in XML before they could be used. Early EJB users had to do a similar thing. An ongoing effort to make Java EE simpler is to omit these registrations or make them optional, especially if they don't really serve a purpose from the point of view of the end-user.

Role registration in Java EE is just like that. Suppose a SAM sets the authenticated result to consist of a user "Pete" with roles "foo" and "bar". Then having to register "foo" and "bar" in some XML file is just a nuisance to the user. It's hard to explain to them why the registration is needed. Older explanations used to say in very formal language about the 'deployer' being able to 'obtain a security view of the application' and then be able to 'map it to the runtime environment'.

Many users I'm afraid would just stare at that for a moment, shrug, and then just don't use Java EE security.

If no role mapping is used, then there's no security view for a deployer needed for mapping the roles, hence declaration would not be needed. While at the topic of security view for a deployer. I haven't really seen this happening in practice. Deploys are mostly automated via something like Jenkins these days. There's no actual person that during deployment uses some tooling that gives a list back of all roles in the app, then at the spot goes on mapping names on this list to roles in the environment. While theoretically maybe useful in practice to deploy unknown externally obtained apps, I don't think this is how modern software development cycles work in practice.

So requiring roles to be declared makes what I think is a minor use case possible, while causing much pain for a larger amount of people.

The other use case concerns systems where pages are added dynamically and external users register with the system (e.g. a typical public Wordpress or Wiki scenario). In such systems it might be wanted to create roles dynamically at run-time and then access them to users dynamically at run-time (note that it's not required for this mechanism to let users get those roles while logged-in; a log-out/log-in would be okay here). Examples of such roles might be "ACCESS_COMPUTERS_PAGE" or "EDIT_COMPUTERS_PAGE", etc.

Of course there are plenty of other mechanisms to realize the above, but I've seen people who wanted to do stuff like that.

There's one big complication to the dynamic role mapping, and that complication is called JACC.

From my article on this:

Typically JACC providers will create the total list of WebRoleRefPermission instances when an application is deployed and then return a sub-selection based on the Principals that we (indirectly) passed in our call to Policy#getPermissions. This however requires that all roles are statically and upfront declared. But a JASPIC auth module can dynamically return any amount of roles to the container and via HttpServletRequest#isUserInRole() an application can dynamically query for any such role without anything needing to be declared. Unfortunately such dynamic role usage typically doesn't work when JACC is used (the Java EE specification also forbids this, but on servers like JBoss it works anyway).

See: http://arjan-tijms.blogspot.com/2014/03/implementing-container-authorization-in.html

The most important purpose of this issue remains the standardized role mapping itself (which incidentally can also be used then to plug a major hole in JACC) with the special case of no role mapping.

Not having to declare roles is a nice bonus that makes things a lot easier to many users, but may things difficult for JACC. While I think JACC isn't used that much by users, servers like GlassFish use it internally.





[GLASSFISH-21309] pgk list cannot be executed on Ubuntu 14.04 x64 Created: 21/Feb/15  Updated: 21/Feb/15

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

Type: Bug Priority: Major
Reporter: nabizamani Assignee: Snjezana Sevo-Zenzerovic
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   

"pgk list" cannot be executed on Ubuntu 14.04 x64. Below you cen find the commands I tried. That means, I have no chance to upgrade Glassfish 4.1 with pkg if installed on an Ubuntu 14.04 x64 system. That's very sad, not to say a catastrophe...
As requested by the command line tool I have tried to install ia32-libs, but it is not available in 14.04. I have tried some alternatives found via google, but non of them work:
#sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0
#sudo apt-get install lib32stdc++6
#sudo apt-get install libjpeg62:i386

Please update the documentation - it should contain exactly what to do. The pkg command line tool is essential. I believe it is a good idea to have a more platform transparent implementation of pkg.

#######################################

  1. 1. try to run ./pkg list
    #######################################
    me@ubuntu:/home/glassfish/bin$ ./pkg list

The software needed for this command (pkg) is not installed.

When this tool interacts with package repositories, some system information
such as your system's IP address and operating system type and version
is sent to the repository server. For more information please see:

http://wikis.oracle.com/display/updatecenter/UsageMetricsUC2

Once installation is complete you may re-run this command.

Would you like to install this software now (y/n): y

Proxy: Using system proxy settings.
Install image: /home/glassfish
Installing pkg packages.
Downloading 3 packages.
Downloading pkg-toolkit-incorporation (2 files, 71,742 bytes).
File 2/2
Downloading pkg (511 files, 6,237,953 bytes).
File 511/511
Downloading python2.4-minimal (304 files, 6,873,977 bytes).
File 304/304
Executing 936 install actions.
Initialization complete.

Software successfully installed. You may now re-run this command (pkg).
me@ubuntu:/home/glassfish/bin$

#######################################

  1. 2. Ok, let's do what is requested
    #######################################
    me@ubuntu:/home/glassfish/bin$ ./pkg list
    ./pkg: 228: ./pkg: /home/glassfish/pkg/bin/../python2.4-minimal/bin/python: not found
    ---------------------------------------------------------------
    There was an error running

/home/glassfish/pkg/bin/../python2.4-minimal/bin/python

You are running on a 64 bit Linux distribution and the 32 bit Linux
compatibility libraries do not appear to be installed. In order to use
the Update Center tools you must install the 32 bit compatibility libraries.

On Ubuntu (and possibly other Debian based systems) please install the
ia32-libs package. On RedHat 4 (and other RPM based systems), you may
need to add multiple 'compat' runtime library packages. Please see the
Update Center Release Notes for more information
---------------------------------------------------------------
me@ubuntu:/home/glassfish/bin$

#######################################

  1. 3. Ok, let's do again what is requested
    #######################################
    me@ubuntu:/home/glassfish/bin$ sudo apt-get update
    me@ubuntu:/home/glassfish/bin$ sudo apt-get upgrade
    me@ubuntu:/home/glassfish/bin$ sudo apt-get install ia32-libs
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    Package ia32-libs is not available, but is referred to by another package.
    This may mean that the package is missing, has been obsoleted, or
    is only available from another source
    However the following packages replace it:
    lib32z1 lib32ncurses5 lib32bz2-1.0

E: Package 'ia32-libs' has no installation candidate
me@ubuntu:/home/glassfish/bin$






[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-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-21044] GlassFish module can't use Javac API with security manager / JavaSE8 Created: 18/Apr/14  Updated: 19/Sep/14  Resolved: 23/Apr/14

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

Type: Bug Priority: Critical
Reporter: Romain Grécourt Assignee: Nithya Ramakrishnan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JavaSE 8


Issue Links:
Related
is related to GLASSFISH-21012 JDK 8: Can't compile JSPs when defaul... Resolved
Tags: java8, javac, security

 Description   

This happens for instance when deploying an app using JSP or CMP, while running GlassFish with JavaSE8 and security manager turned on.
Here is what can be seen in the server.log

[2014-04-15T13:06:45.438+0200] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core.security] [tid: _ThreadID=44 _ThreadName=admin-listener(4)] [timeMillis: 1397560005438] [levelValue: 800] [[
  JACC Policy Provider: Failed Permission Check, context(null)- permission(("java.lang.reflect.ReflectPermission" "suppressAccessChecks"))]]

[2014-04-15T13:06:45.446+0200] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=44 _ThreadName=Thread-9] [timeMillis: 1397560005446] [levelValue: 1000] [[
  An exception has occurred in the compiler (1.8.0-internal). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Tha
nk you.]]

Note that if one adds the mentioned permission under a grant for unknown code, it works.



 Comments   
Comment by JeffTancill [ 23/Apr/14 ]

Closed as duplicate of https://java.net/jira/browse/GLASSFISH-21012





[GLASSFISH-21011] QuickLook fails with security manager ON / jdk7u60 / remote ejb Created: 19/Mar/14  Updated: 19/Sep/14  Resolved: 25/Mar/14

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

Type: Bug Priority: Critical
Reporter: Romain Grécourt Assignee: Nithya Ramakrishnan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdk1.7.0_60-ea


Tags: 4_0_1-review, glassfish, security

 Description   

deploy-v3-impl:
[echo] deploying remoteview.jar

deploy-v3-impl-unix:
[exec] Command deploy failed.
[exec] remote failure: Error occurred during deployment: Exception while loading the app : javax.ejb.CreateException: Initialization failed for Singleton SingletonBean. Please see server.log for more details.
[exec] Result: 1

See a snippet of Server.log below.
I've tried adding 'permission java.io.SerializablePermission "enableSubclassImplementation";' to glassfish/domains/domain1/config/server.policy, and it worked.

[2014-03-19T09:41:52.085-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1395247312085] [levelValue: 1000] [[
  Exception during lifecycle processing
javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton SingletonBean
	at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:649)
	at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:389)
	at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219)
	at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180)
	at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158)
	at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:166)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
	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:539)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
	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:534)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:406)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:350)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:106)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:259)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:363)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
	at java.lang.Thread.run(Thread.java:744)
Caused by: javax.ejb.CreateException: Initialization failed for Singleton SingletonBean
	at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:476)
	at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:74)
	at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:647)
	... 69 more
Caused by: java.lang.IllegalStateException: Exception attempting to inject Remote ejb-ref name=remoteview.SingletonBean/helloHome,Remote 2.x home =remoteview.HelloHome,Remote 2.x component interface=remoteview.HelloRemote resolved to intra-app EJB HelloBean in module remoteview,ejb-link=HelloBean,lookup=,mappedName=,jndi-name=HH,refType=Session into class remoteview.SingletonBean: Lookup failed for 'java:comp/env/remoteview.SingletonBean/helloHome' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
	at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:153)
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:91)
	at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:257)
	at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1748)
	at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:436)
	... 71 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Remote ejb-ref name=remoteview.SingletonBean/helloHome,Remote 2.x home =remoteview.HelloHome,Remote 2.x component interface=remoteview.HelloRemote resolved to intra-app EJB HelloBean in module remoteview,ejb-link=HelloBean,lookup=,mappedName=,jndi-name=HH,refType=Session into class remoteview.SingletonBean: Lookup failed for 'java:comp/env/remoteview.SingletonBean/helloHome' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:740)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:507)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:170)
	at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:145)
	... 77 more
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/env/remoteview.SingletonBean/helloHome' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Exception resolving Ejb for 'Remote ejb-ref name=remoteview.SingletonBean/helloHome,Remote 2.x home =remoteview.HelloHome,Remote 2.x component interface=remoteview.HelloRemote resolved to intra-app EJB HelloBean in module remoteview,ejb-link=HelloBean,lookup=,mappedName=,jndi-name=HH,refType=Session' .  Actual (possibly internal) Remote JNDI name used for lookup is 'HH' [Root exception is javax.naming.CommunicationException: Communication exception for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is java.rmi.RemoteException: ; nested exception is: 
	java.security.AccessControlException: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")]]]
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:636)
	... 80 more
Caused by: javax.naming.NamingException: Exception resolving Ejb for 'Remote ejb-ref name=remoteview.SingletonBean/helloHome,Remote 2.x home =remoteview.HelloHome,Remote 2.x component interface=remoteview.HelloRemote resolved to intra-app EJB HelloBean in module remoteview,ejb-link=HelloBean,lookup=,mappedName=,jndi-name=HH,refType=Session' .  Actual (possibly internal) Remote JNDI name used for lookup is 'HH' [Root exception is javax.naming.CommunicationException: Communication exception for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is java.rmi.RemoteException: ; nested exception is: 
	java.security.AccessControlException: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")]]
	at com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:188)
	at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$EjbReferenceProxy.create(ComponentEnvManagerImpl.java:1012)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:745)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
	at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:159)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
	... 84 more
Caused by: javax.naming.CommunicationException: Communication exception for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is java.rmi.RemoteException: ; nested exception is: 
	java.security.AccessControlException: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")]
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:513)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:183)
	... 89 more
Caused by: java.rmi.RemoteException: ; nested exception is: 
	java.security.AccessControlException: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")
	at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:142)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:478)
	... 93 more
Caused by: java.security.AccessControlException: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
	at java.security.AccessController.checkPermission(AccessController.java:559)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at org.omg.CORBA_2_3.portable.InputStream.checkPermission(InputStream.java:67)
	at org.omg.CORBA_2_3.portable.InputStream.<init>(InputStream.java:84)
	at com.sun.corba.ee.impl.encoding.CDRInputObject.<init>(CDRInputObject.java:147)
	at com.sun.corba.ee.impl.encoding.EncapsInputStream.<init>(EncapsInputStream.java:82)
	at com.sun.corba.ee.impl.encoding.EncapsOutputStream$EncapsInputStreamFactory.createInputObject(EncapsOutputStream.java:111)
	at com.sun.corba.ee.impl.encoding.CDROutputObject.createInputObject(CDROutputObject.java:355)
	at com.sun.corba.ee.impl.encoding.EncapsOutputStream.create_input_stream(EncapsOutputStream.java:105)
	at com.sun.corba.ee.impl.corba.AnyImpl.create_input_stream(AnyImpl.java:547)
	at org.omg.CosTransactions.OTSPolicyValueHelper.extract(OTSPolicyValueHelper.java:25)
	at com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:253)
	at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:290)
	at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:378)
	at com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.beginRequest(ClientRequestDispatcherImpl.java:323)
	at com.sun.corba.ee.impl.protocol.ClientDelegateImpl.request(ClientDelegateImpl.java:220)
	at com.sun.corba.ee.impl.protocol.ClientDelegateImpl.is_a(ClientDelegateImpl.java:378)
	at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:130)
	at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
	at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:490)
	at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:541)
	at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:519)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at com.sun.enterprise.naming.util.IIOPObjectFactory.getObjectInstance(IIOPObjectFactory.java:71)
	at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
	at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:133)
	... 94 more
]]


 Comments   
Comment by Romain Grécourt [ 20/Mar/14 ]

Jeff, could you please let me know if the described fix is okay ?

Comment by JeffTancill [ 20/Mar/14 ]

Looks fine.

Comment by JeffTancill [ 24/Mar/14 ]

Do you want us to do the submit?

Comment by Romain Grécourt [ 24/Mar/14 ]

Here is the exact change I tried:

svn diff
Index: nucleus/security/core/src/main/resources/config/server.policy
===================================================================
--- nucleus/security/core/src/main/resources/config/server.policy	(revision 63170)
+++ nucleus/security/core/src/main/resources/config/server.policy	(working copy)
@@ -101,6 +101,9 @@
     permission java.net.SocketPermission    "*", "connect";
     permission java.io.FilePermission       "<<ALL FILES>>", "read,write";
 
+    // GLASSFISH-21011
+    permission java.io.SerializablePermission "enableSubclassImplementation";
+
         // 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";

I can commit that as is with your approval, otherwise might be better if someone from your team makes the change.

Thanks,
Romain

Comment by JeffTancill [ 24/Mar/14 ]

Nithya, please submit this change to server.policy, thanks.

Comment by Nithya Ramakrishnan [ 25/Mar/14 ]

Since the invocation involves a few reflection classes outside the GF/modules directory, the explicit grant of the permission is required (AllPermission is applied only for classes within the modules directory).
Added the grant mentioned.
Also removed the redundant jruby related permission grant in the server.policy

Sending appserver/security/core-ee/src/test/resources/com/sun/enterprise/security/perms/server.policy
Sending nucleus/admin/template/src/main/resources/config/server.policy
Sending nucleus/security/core/src/main/resources/config/server.policy
Transmitting file data ...
Committed revision 63171.





[GLASSFISH-20882] Unable to Authenticate using PAM Realm Created: 05/Nov/13  Updated: 25/Aug/14  Resolved: 07/Apr/14

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: heffel Assignee: Nithya Ramakrishnan
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Mint 15 Olivia


Tags: pamrealm, realm, security

 Description   

Unable to authenticate using PAM Realm as described at https://blogs.oracle.com/nithya/entry/pamrealm_in_glassfish_3_1

The first time I tried, I got the following stack trace (partial):

com.sun.enterprise.security.auth.login.common.LoginException: Login failed: java.lang.UnsatisfiedLinkError: Unable to load library 'pam': libpam.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:164)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:237)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:372)
at com.sun.jna.Native.loadLibrary(Native.java:357)
at org.jvnet.libpam.impl.PAMLibrary.<clinit>(PAMLibrary.java:132)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:140)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1057)
at java.lang.reflect.Field.getFieldAccessor(Field.java:1038)
at java.lang.reflect.Field.get(Field.java:379)

After some googling, stumbled upon https://issues.jenkins-ci.org/browse/JENKINS-9486 which describes a similar issue for Jenkins. Following some comments on that page, I created a symlink as described there: "ln -s /lib/x86_64-linux-gnu/libpam.so.0 /lib/x86_64-linux-gnu/libpam.so"

I now get a different exception:

[2013-11-04T19:23:12.182-0500] [glassfish 4.0] [WARNING] [web.login.failed] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=29 _ThreadName=http-listener-2(5)] [timeMillis: 1383610992182] [levelValue: 900] [[
WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: java.lang.NoClassDefFoundError: Could not initialize class org.jvnet.libpam.impl.PAMLibrary
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:140)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:949)
at java.lang.reflect.Field.getFieldAccessor(Field.java:930)
at java.lang.reflect.Field.get(Field.java:372)
at com.sun.jna.Native.loadLibraryInstance(Native.java:396)
at com.sun.jna.Native.getStructureAlignment(Native.java:505)
at com.sun.jna.Structure.setAlignType(Structure.java:189)
at com.sun.jna.Structure.<init>(Structure.java:147)
at com.sun.jna.Structure.<init>(Structure.java:143)
at com.sun.jna.Structure.<init>(Structure.java:139)
at com.sun.jna.Structure.<init>(Structure.java:130)
at org.jvnet.libpam.impl.PAMLibrary$pam_conv.<init>(PAMLibrary.java:107)
at org.jvnet.libpam.PAM.<init>(PAM.java:73)
at com.sun.enterprise.security.ee.auth.login.PamLoginModule.authenticate(PamLoginModule.java:114)
at com.sun.enterprise.security.ee.auth.login.PamLoginModule.authenticateUser(PamLoginModule.java:65)
at com.sun.enterprise.security.BasePasswordLoginModule.login(BasePasswordLoginModule.java:146)
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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
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:383)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:241)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:154)
at com.sun.web.security.RealmAdapter.authenticate(RealmAdapter.java:695)
at com.sun.web.security.RealmAdapter.authenticate(RealmAdapter.java:636)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:279)
at org.apache.catalina.authenticator.AuthenticatorBase.processSecurityCheck(AuthenticatorBase.java:991)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:580)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:702)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
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)
]]



 Comments   
Comment by Nithya Ramakrishnan [ 16/Feb/14 ]

Hi,

Could you pls confirm if the issue is reproducible in any other Unix environment? We wanted to check if it is local to this OS

Thanks
Nithya

Comment by Nithya Ramakrishnan [ 17/Feb/14 ]

We were able to configure PamRealm and authenticate to a webapp using the realm on a OEL server using GF 4. This issue seems to be local to the OS.
Request you to try out PamRealm on any other OS like OEL and let us know in case of issues

Comment by Nithya Ramakrishnan [ 07/Apr/14 ]

Since we are unable to reproduce this issue in OEL with the latest GF, we are closing this issue.
Please reopen this if you are still facing problems with any other flavor/version of Unix .

Comment by luyee2010 [ 25/Aug/14 ]

it same appears in Jenkins ver. 1.514

like this
Could not initialize class org.jvnet.libpam.impl.PAMLibrary$pam_conv
Caused by:

java.lang.NoClassDefFoundError: Could not initialize class org.jvnet.libpam.impl.PAMLibrary$pam_conv
at org.jvnet.libpam.PAM.<init>(PAM.java:73)
at hudson.security.PAMSecurityRealm.authenticate(PAMSecurityRealm.java:73)
at hudson.security.AbstractPasswordBasedSecurityRealm$Authenticator.retrieveUser(AbstractPasswordBasedSecurityRealm.java:136)
at org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:122)
at org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:200)
at org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:47)
at org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:74)
at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:64)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:447)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:138)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:540)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1070)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:376)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1004)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:258)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:449)
at org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:252)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:266)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:240)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:589)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:520)
at java.lang.Thread.run(Thread.java:722)





[GLASSFISH-20874] Support application scoped auth-realms Created: 25/Oct/13  Updated: 25/Oct/13

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

Type: New Feature Priority: Major
Reporter: emailnbw Assignee: michael.y.chen
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: deployment, security

 Description   

Much the same way you can create application scoped jdbc-resource / jdbc-connection pools using glassfish-resources.xml I would like to be able to create application scoped auth-realms. This will simplify deployments by allowing the auth-realm configuration to be packaged with the app in the WAR file instead of being created by hand through asadmin.






[GLASSFISH-20809] Request parameters lost after realm form authentication to access a protected page Created: 11/Sep/13  Updated: 07/Apr/14  Resolved: 07/Apr/14

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Hildeberto Mendonça Assignee: Nithya Ramakrishnan
Resolution: Cannot Reproduce Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 13.04, Java 1.7.0_25, Glassfish 4 b89, JSF 2.2


Tags: login, parameter, realm, request, security

 Description   

Request parameters in a link to a protected page are ignored. For instance: page index.xhtml, which is public, contains a link to the page protected.xhtml, which is protected, with the parameter ?id=737373. Before accessing the page protected.xhtml?id=737373 the login page appears to the user. The correct user name and password are informed and then the page protected.xhtml?id=737373 appears, however the parameter id is lost the the page doesn't print its value.

if the user is already authenticated and he tries to access the protected page through the index.xhtml page, then he will see the id value normally. In this case, it worked because there wasn't any authentication page between them.

It works on Glassfish 3.1.x.



 Comments   
Comment by Hildeberto Mendonça [ 11/Sep/13 ]

I have a small application that reproduces the problem. How can I attach it here?

Comment by kaoru_yamamoto [ 18/Nov/13 ]

A problem occurs when my application includes CDI Bean.
However, the problem does not occur if there is not CDI Bean by the same application either.
The only difference is whether @Named and @RequestScoped annotation exists.
Does your application include CDI Bean?

Above-mentioned CDI Bean is not referred to from anywhere, and the problem is not solved even if I change @RequestScoped to @SessionScoped.
This problem also occurs in the class that implements the Servlet interface or class that extends GenericServlet or HttpServlet.

I think that a problem occurs because CDI Bean exists.
When CDI Bean exists, will the authentication process is change?

Comment by Nithya Ramakrishnan [ 02/Apr/14 ]

Hildeberto, It would help if you can attach the sample application to the bug.
You can use the Attach file option in the side panel to attach the zipped version of the application.

Comment by Nithya Ramakrishnan [ 07/Apr/14 ]

The code currently makes sure that the request parameters are passed over after login to the originally requested page.
Tried to reproduce this with the sample app . The request parameter passed is obtained correctly in protected.html after succesful form authentication





[GLASSFISH-20038] Revise the XML parser for the permissions.xml file Created: 25/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

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

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

Tags: security

 Description   

This bug is to track the further work to fix the XML parser for the permissions.xml to enforce schema check.

This is further work after revision 60776.



 Comments   
Comment by spei [ 02/Apr/13 ]

Use the parser in Glassfish deployment mechanism to parse the permissions.xml file packaged in an application/module. The parsing will be able to enforce the schema check.

Committed revision 61113





[GLASSFISH-19809] usage of internal proprietary API in nucleus/security/core Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build, maven, proprietary-api, security, warning

 Description   
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[53,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java:[63,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[70,24] ContentInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[71,24] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[72,24] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[73,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[74,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[252,30] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[504,18] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[504,42] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,33] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java:[686,66] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java:[286,46] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUPName.java:[45,27] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[56,29] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[58,37] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/common/iiop/security/GSSUtilsContract.java:[60,11] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[213,12] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[213,30] PKCS7 is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[214,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[214,38] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[215,24] ContentInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[217,24] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[217,41] SignerInfo is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[218,25] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[220,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/ssl/JarSigner.java:[221,24] AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[368,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java:[368,32] X500Name is internal proprietary API and may be removed in a future release





[GLASSFISH-19805] usage of internal proprietary API in appserver/security/webintegration Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build, maven, proprietary-api, security, warning

 Description   
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[75,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[596,16] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java:[596,37] X500Name is internal proprietary API and may be removed in a future release





[GLASSFISH-19802] usage of internal proprietary API in appserver/ejb/ejb.security Created: 08/Mar/13  Updated: 08/Mar/13

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

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: michael.y.chen
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, ejb, maven, proprietary-api, security, warning

 Description   
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[81,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[67,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[68,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[48,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[65,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[66,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[68,24] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[45,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[46,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[47,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[81,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[67,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[68,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[48,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[65,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[66,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[68,24] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[45,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[46,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[47,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[81,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[67,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[68,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[48,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[65,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[66,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[68,24] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[69,24] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[45,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[46,24] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[47,24] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[950,39] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[951,35] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[1533,16] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[1533,37] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecurityMechanismSelector.java:[1536,31] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[187,8] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[187,34] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[188,8] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[193,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[195,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[195,33] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[207,25] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecClientRequestInterceptor.java:[209,32] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[62,29] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[66,37] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtilsService.java:[70,11] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[265,12] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[265,33] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[271,26] X500Name is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[289,12] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[289,37] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[295,12] DerValue is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[297,28] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecServerRequestInterceptor.java:[308,35] X509CertImpl is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[69,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[71,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[76,24] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[83,8] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[89,20] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[98,20] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[107,20] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[152,36] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[181,8] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[209,40] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[239,8] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[263,44] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[305,32] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[312,1] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[312,27] DerOutputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[331,19] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[334,9] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[334,34] DerInputStream is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[335,9] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[361,44] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[397,38] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[431,41] ObjectIdentifier is internal proprietary API and may be removed in a future release
[WARNING]  appserver/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/GSSUtils.java:[459,8] ObjectIdentifier is internal proprietary API and may be removed in a future release





[GLASSFISH-19800] usage of internal proprietary API in appserver/security/inmemory.jacc.provider Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Tags: build, maven, proprietary-api, security, warning

 Description   
[WARNING] appserver/security/inmemory.jacc.provider/src/main/java/com/sun/enterprise/security/jacc/provider/SimplePolicyProvider.java:[86,50] PolicyFile is internal proprietary API and may be removed in a future release





[GLASSFISH-19799] usage of internal proprietary API in appserver/security/appclient.security Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: appclient, build, proprietary-api, security, warning

 Description   
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[59,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[174,28] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] main/appserver/security/appclient.security/src/main/java/com/sun/enterprise/security/appclient/ConfigXMLParser.java:[177,38] PropertyExpander is internal proprietary API and may be removed in a future release


 Comments   
Comment by Romain Grécourt [ 08/Mar/13 ]

update affect version





[GLASSFISH-19798] usage of internal proprietary API in appserver/security/core-ee Created: 08/Mar/13  Updated: 08/Mar/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags: build, proprietary-api, security, warning

 Description   
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[53,24] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[54,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[55,24] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[54,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[105,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[48,18] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[49,24] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[50,24] Password is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[68,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[69,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[69,24] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[116,25] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[116,39] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[127,8] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[133,8] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[138,12] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[233,32] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[264,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[299,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[372,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[385,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[435,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[443,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[462,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[505,5] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[529,11] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[543,20] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[557,11] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[568,23] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[607,10] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[621,39] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[671,23] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[742,11] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[746,13] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[824,7] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[827,29] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[995,33] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[1222,3] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyParser.java:[1230,44] ResourcesMgr is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyConfigurationImpl.java:[798,37] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyConfigurationImpl.java:[870,17] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[158,56] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[561,20] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[569,26] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[599,25] PropertyExpander is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java:[615,25] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[433,20] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[433,45] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[434,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[435,20] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[435,45] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/callback/BaseContainerCallbackHandler.java:[436,24] DerValue is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyWrapper.java:[75,56] PolicyFile is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[77,12] ParseUtil is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[94,2] Debug is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/provider/PolicyUtil.java:[146,35] Password is internal proprietary API and may be removed in a future release
[WARNING] security/core-ee/src/main/java/com/sun/enterprise/security/jmac/config/ConfigDomainParser.java:[213,4] PropertyExpander is internal proprietary API and may be removed in a future release


 Comments   
Comment by Romain Grécourt [ 08/Mar/13 ]

change fix version





[GLASSFISH-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-18528] RuntimeException thown in a JASPIC swallowed and empty page returned Created: 18/Mar/12  Updated: 19/Sep/14  Resolved: 16/May/14

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

Type: Bug Priority: Major
Reporter: bjb Assignee: Nithya Ramakrishnan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2008, 64bits


Tags: 4_0_1-approved, debug, empty, jaspic, maze, page, security

 Description   

Any RuntimeException thrown in the JASPIC implementation will result in a empty page in GF (a valid HTML page but with no content and with host encoding as meta) and no log at all (GF security logger set to finest).

IMHO, there should be an isolation so that a RuntimeEx thrown in JASPIC should be intercepted by GF's JASPIC container and :

  • if mandatory : result in a 403
  • if not mandatory : catch & log it appropriately in the security logger and go on with the next implementation configured (as per the spec)

I do not have seen anything about RuntimeEx behavior in the JSR, but this is something that should realy be handled.

FYI, the only solution is to dig with the debugger and it result into a massive loss of time, plus an cloudy situation toward the security : a page was return without clue where it came from.

Rgs,
JB



 Comments   
Comment by Nithya Ramakrishnan [ 16/May/14 ]

A 500 Server error page would now be displayed when a Runtime exception is thrown from the SAM.

Quoting from the JASPIC spec : (Sec 3.8)

"If the request is dispatched to the resource and the resource invocation throws an exception to the
runtime, the runtime must set, within the response, an HTTP status code which satisfies any applicable
requirements defined within the servlet specification. In this case, the runtime should complete the
processing of the request without calling secureResponse"

Sending webintegration/src/main/java/com/sun/web/security/RealmAdapter.java
Transmitting file data .
Committed revision 63277.





[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-17748] Weld / JSF Is Not Working Without java.lang.reflect.ReflectPermission suppressAccessChecks Created: 16/Nov/11  Updated: 12/Dec/11  Resolved: 12/Dec/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: abien Assignee: Sivakumar Thyagarajan
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: Zip Archive 17748-reproducer.zip     File 17748_screenshot.tiff     File server.policy    
Issue Links:
Duplicate
is duplicated by GLASSFISH-15078 jpa cdi AccessControlException when s... Resolved
Tags: security

 Description   

Withdrawal of the permissions for JRuby:
//JRuby security permissions
grant codeBase "file:$

{com.sun.aas.installRoot}

/jruby/lib/-"{
permission java.io.FilePermission "<<ALL FILES>>", "read";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
permission java.util.PropertyPermission "jruby.*", "read";
permission java.lang.RuntimePermission "accessClassInPackage.*";
permission java.lang.RuntimePermission "createClassLoader";
permission java.lang.RuntimePermission "defineClassInPackage.*";
permission java.lang.RuntimePermission "getClassLoader";
permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.lang.RuntimePermission "getenv.*";
};

breaks JSF and Weld:
javax.el.ELException: /index.xhtml @11,62 value="#

{index.location}

": java.lang.RuntimeException: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:114)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
at javax.faces.component.UIOutput.getValue(UIOutput.java:169)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:355)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:164)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:312)
at com.sun.faces.renderkit.html_basic.GridRenderer.renderRow(GridRenderer.java:185)
at com.sun.faces.renderkit.html_basic.GridRenderer.encodeChildren(GridRenderer.java:129)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1756)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1756)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:401)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
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 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:323)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:321)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:356)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:212)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1532)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
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:680)
Caused by: java.lang.RuntimeException: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)

Expected behavior:

In case reflection is needed for JSF EL and Weld (and it is), it should be added to the server.policy just granting the permission to the internal set of libraries. Right now it is not possible to remove this permission without breaking JSF + Weld.



 Comments   
Comment by Nithya Ramakrishnan [ 18/Nov/11 ]

Could you please attach a test case with which you hit this error? We shall analyze the policy with that.

Thanks
Nithya

Comment by abien [ 27/Nov/11 ]

Reproducer project (invoke with: localhost:8080/17748-reproducer/) and the server.policy WITHOUT the jruby settings attached

Comment by Nithya Ramakrishnan [ 02/Dec/11 ]

The error occurs even if the permission is present. Since the grant is only for jruby/lib/ which is non-existent in 3.1.2 (and it shall be removed), this error is independent of the grant that is specified in the issue (viz)

grant codeBase "file:$

{com.sun.aas.installRoot}

/jruby/lib/-"

{ permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }

;

The actual stack trace is as follows: The solution is to have the Weld code provide a PriviledAction for setAccessible() :

at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:125)
at org.jboss.weld.util.reflection.SecureReflections$14.work(SecureReflections.java:287)

Transferring to the JSF team.

java.lang.RuntimeException: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:65)
at org.jboss.weld.util.reflection.SecureReflections.ensureAccessible(SecureReflections.java:282)
at org.jboss.weld.introspector.jlr.WeldConstructorImpl.newInstance(WeldConstructorImpl.java:204)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:117)
at org.jboss.weld.bean.ManagedBean.createInstance(ManagedBean.java:323)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.java:195)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:284)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:89)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
at com.abien.gf.reproducer.Index$Proxy$$$_WeldClientProxy.getMessage(Index$Proxy$$$_WeldClientProxy.java)
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:616)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:116)
at com.sun.el.parser.AstValue.getValue(AstValue.java:163)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:219)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:227)
at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:150)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)
at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
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:616)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:323)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:321)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:356)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:212)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1535)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
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:331)
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:833)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:730)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1031)
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:636)
Caused by: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:125)
at org.jboss.weld.util.reflection.SecureReflections$14.work(SecureReflections.java:287)
at org.jboss.weld.util.reflection.SecureReflections$14.work(SecureReflections.java:282)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63)

Comment by rogerk [ 02/Dec/11 ]

Assign to Weld team for investigation.

Comment by Sivakumar Thyagarajan [ 12/Dec/11 ]

This is related to the issue described at http://java.net/jira/browse/GLASSFISH-15078 and also release noted for 3.1 at http://docs.oracle.com/cd/E18930_01/html/821-2434/ggrvi.html#gkxca

The issue can be fixed with the following workaround: Add a grant for the application alone as shown below, in server.policy:

grant codebase "file:$

{com.sun.aas.instanceRoot}

/applications/17748-reproducer-1.0-SNAPSHOT/-"

{ permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }

;

Having this grant, and accessing the application at http://localhost:8080/17748-reproducer-1.0-SNAPSHOT/ gave me the following output:
"It seems to work!"

Marking this issue as invalid, as it is a known issue with workaround. Until a fix for WELD-32 comes, unfortunately the above workaround has to be release-noted.





[GLASSFISH-17747] Weld / JSF Is Not Working Without java.lang.reflect.ReflectPermission suppressAccessChecks Created: 16/Nov/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2

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

All


Tags: security

 Description   

J2EESecurityManager has an implicit permission which is not specified in the server.policy:

"class java.net.SocketPermission => java.net.SocketPermissionCollection@2b4b8486 (
("java.net.SocketPermission" "localhost:1024-" "listen,resolve")
)
"

Is is impossible (how to remove the permission above?) to prevent Java EE applications from opening sockets:

SecurityManager security = System.getSecurityManager();
security.checkListen(4242);
or
ServerSocket serverSocket = new ServerSocket(4242);

can be executed without an explicit permission in server.policy.



 Comments   
Comment by abien [ 16/Nov/11 ]

I'm neither able to edit, nor delete this issue. Please remove it

Comment by Nithya Ramakrishnan [ 18/Nov/11 ]

Closing, as per the user's last comment, since this is not an issue





[GLASSFISH-17547] Implicit / Not-Configurable SocketPermission listen,resolve Created: 01/Nov/11  Updated: 05/Dec/11  Resolved: 05/Dec/11

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2

Type: Bug Priority: Major
Reporter: abien Assignee: kumarjayanti
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: security

 Description   

J2EESecurityManager has an implicit permission which is not specified in the server.policy:

"class java.net.SocketPermission => java.net.SocketPermissionCollection@2b4b8486 (
("java.net.SocketPermission" "localhost:1024-" "listen,resolve")
)
"

Is is impossible (how to remove the permission above?) to prevent Java EE applications from opening sockets:

SecurityManager security = System.getSecurityManager();
security.checkListen(4242);
or
ServerSocket serverSocket = new ServerSocket(4242);

can be executed without an explicit permission in server.policy.



 Comments   
Comment by Nithya Ramakrishnan [ 05/Dec/11 ]

This is not due to the J2EESecurityManager. The permission for this is provided in java.policy:

// allows anyone to listen on un-privileged ports
permission java.net.SocketPermission "localhost:1024-", "listen";

If this is removed, then an AccessDenied exception would be thrown for all ports above 1024 as well, when SM is on.

Comment by Nithya Ramakrishnan [ 05/Dec/11 ]

You can find java.policy in JRE/lib/security/java.policy





[GLASSFISH-17529] doPasswordLogin fails LoginException: Security Exception Created: 29/Oct/11  Updated: 31/Oct/11  Resolved: 31/Oct/11

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: fishsticks87 Assignee: kumarjayanti
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, JSF 2.1, Servlet 3.0


Attachments: JPEG File jdbc realm screen.jpg     Text File trace.txt    
Tags: authentication, realm, security

 Description   

My application uses form based authentication with the HttpServletRequest.login(username,password) method in my JSF backing bean. The user I am testing against my database for is

Username: admin
Password: admin (SHA-256 Hex encoded as "24891c48cb386a28dfc33a558d9d0c6f38169a889e1a6edfc45d294e61fe7142")

The exception leads me to believe there is a problem with the username or password. I tried storing the password in the database in a variety of different encodings but I always get the same error (see trace.txt).

In web.xml:
<security-constraint>
<display-name>UserConstraints</display-name>
<web-resource-collection>
<web-resource-name>Pages</web-resource-name>
<description/>
<url-pattern>/home.jsf</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>USER</role-name>
<role-name>ADMINISTRATOR</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<display-name>AdminConstraints</display-name>
<web-resource-collection>
<web-resource-name>Pages</web-resource-name>
<description/>
<url-pattern>/home.jsf</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>ADMINISTRATOR</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>PerProUserAuth</realm-name>
<form-login-config>
<form-login-page>/index.jsf</form-login-page>
<form-error-page>/index.jsf</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description/>
<role-name>USER</role-name>
</security-role>
<security-role>
<description/>
<role-name>ADMINISTRATOR</role-name>
</security-role>

In glassfish-web.xml:

<security-role-mapping>
<role-name>ADMINISTRATOR</role-name>
<group-name>Internal</group-name>
<group-name>External</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>USER</role-name>
<group-name>Internal</group-name>
<group-name>External</group-name>
</security-role-mapping>

I turned on FINE logging for javax.enterprise.system.core.security and I've attached a stack trace (trace.txt). I also tried asking the community at SO with no luck: http://stackoverflow.com/questions/7941713/loginexception-login-failed-security-exception

GLASSFISH-16189 is similar to this issue but I already tested changing the JNDI property to something different and that didn't help.



 Comments   
Comment by fishsticks87 [ 30/Oct/11 ]

It looks like the issue was configuration related. Using Apache Commons Codec DigestUtils.sha256Hex(password); and making sure Hex encoding is set in the admin console solved the issue. The odd thing is, that method outputs the same string I got when I computed the digest manually using the Java API. In any case, you can close this issue. Sorry for the trouble.

Comment by kumarjayanti [ 31/Oct/11 ]

Closing the issue as requested by the issue reporter.

Comment by kumarjayanti [ 31/Oct/11 ]

closing issue





[GLASSFISH-17287] [UB]General Vulnerability Assessment -> NonIntrusive -> Web Server Created: 12/Sep/11  Updated: 15/Mar/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

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

Solaris 10, SPARC and X86


Tags: Assessment, General, Glassfish, Security, Vulnerability

 Description   

The following security flaw has been identidfied:

http://www.mcafee.com/us/resources/release-notes/foundstone/fsl_05_11_2011.pdf11907 - Oracle Sun Products Suite Glassfish Denial Of Service

Category: General Vulnerability Assessment -> NonIntrusive -> Web Server

Risk Level: High

CVE: CVE-2011-0807

DISA IAVA: 2011-A-0054

Description

A denial of service vulnerability is present in some versions of Oracle Sun GlassFish Enterprise Server and Sun Java System

Application Server.

Observation

A denial of service vulnerability is present in some versions of Oracle Sun GlassFish Enterprise Server and Sun Java System

Application Server.

Oracle Sun GlassFish Enterprise Server 2.1, 2.1.1, and 3.0.1, and Sun Java System Application Server 9.1 are prone to a

unspecified vulnerability related to Administration. Successful exploitation could allow an attacker to cause a denial of service

This may be already fixed, but is not evident in the latest release notes:

Glassfish 3.1 release note: http://java.net/jira/secure/ReleaseNote.jspa?projectId=10231&version=10968

Glassfish 3.1.1 release note: http://glassfish.java.net/docs/3.1/release-notes.pdf



 Comments   
Comment by Shing Wai Chan [ 12/Sep/11 ]

From http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0807 , we have

Unspecified vulnerability in Oracle Sun GlassFish Enterprise Server 2.1, 2.1.1, and 3.0.1, and Sun Java System Application Server 9.1, allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Administration.

I have confirmed from admin team that this has been fixed in 3.1 and 3.1.1.

Comment by fraggie [ 13/Sep/11 ]

Hi Shing Wai Chan,

Thank you for that and the prompt reply, much appreciated.

One last thing, would it be possible for you to highlight where is states in the release notes that this has been fixed?

(Just for our records).

Regards,
Dónal

Comment by Bhakti Mehta [ 14/Oct/11 ]

Assigning to Shingwai for more input on the submitter's question

Comment by Anissa Lam [ 18/Oct/11 ]

As stated above, the bug exists in
Oracle Sun GlassFish Enterprise Server 2.1, 2.1.1, and 3.0.1, and Sun Java System Application Server 9.1
but not in v3.1 and 3.1.1.

3.1 and 3.1.1 ships before the bug was discovered/reported, thus the release notes of those release doesn't mention about that.

I am transferring this to doc. If they think this should be mentioned in the release note of next release, they can add that in.

Comment by Rebecca Parks [ 12/Dec/11 ]

It sounds to me like it's the Release Notes for 3.1/3.1.1 that need to be fixed. It's too bad I didn't look at this bug sooner, I just updated the 3.1/3.1.1 Release Notes. I think I can get this added for the next patch, scheduled for 1/13/12.

If it's added to the 3.1/3.1.1 Release Notes, it seems to me that it doesn't need to be in the 3.1.2 Release Notes as well, but I'd like to hear other opinions.

Comment by Rebecca Parks [ 04/Jan/12 ]

I checked with the doc team, and it is unfixed bugs that appear in the Release Notes, not fixed ones. So this would go in the SGES 2.1.1, SGCS 2.0, and OGS 3.0.1 Release Notes. I am currently updating the 2.1.1/2.0 Release Notes, so I will retarget this bug to 3.0.1.

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Rebecca Parks [ 06/Mar/12 ]

Changed the fix version back to 3.0.1. This needs to be added to the 3.0.1 Release Notes at the next patch update.

Comment by Tom Mueller [ 07/Mar/12 ]

Bulk update to set Fix Version to "not determined" for issues that had it set to a version that has already been released.

Comment by Rebecca Parks [ 07/Mar/12 ]

Please don't make me do this AGAIN.

Comment by Mike Fitch [ 16/Feb/13 ]

As this applies to unbundled documentation, moving to 4.0.1

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 3.0.1 as per Rebecca's comment of 06/Mar/12 10:41 PM:

Changed the fix version back to 3.0.1. This needs to be added to the 3.0.1 Release Notes at the next patch update.





[GLASSFISH-17169] EJBContext#isCallerInRole(String) should not throw IllegalStateException when passed bad role Created: 09/Aug/11  Updated: 11/Aug/11  Resolved: 11/Aug/11

Status: Resolved
Project: glassfish
Component/s: ejb_container, security
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: ljnelson Assignee: marina vatkina
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: community, ejb, security

 Description   

EJBContext#isCallerInRole(String) is documented to be allowed to throw an IllegalStateException when the caller is not in a state to be allowed to call the method (i.e. if the method is called outside of a security context).

Glassfish's implementation uses this vague wording to mean that isCallerInRole() should also throw an IllegalStateException when it is handed a role name that Glassfish doesn't know anything about.

I've filed this as an enhancement since I don't really know whether strictly speaking this is a specification violation or not. But to my eyes if I call someEjbContext.isCallerInRole("fred") I should get true or false, without the danger of an IllegalStateException (provided of course I'm actually calling this method from within an EJB business method).



 Comments   
Comment by Cheng Fang [ 11/Aug/11 ]

See another related issue: http://java.net/jira/browse/GLASSFISH-10779

EJBContext javadocs says:
roleName - The name of the security role. The role must be one of the security roles that is defined in the deployment descriptor.

Throws:
IllegalStateException - The Container throws the exception if the instance is not allowed to call this method.

-------
The current implementation is compliant. If false is returned in this case, the user can't tell whether the caller is in a valid role, or the role does not exist.





[GLASSFISH-17162] JSR-250 not fully implemented--incomplete list of discoverable security roles Created: 08/Aug/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ljnelson Assignee: kumarjayanti
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: community, jacc, jsr250, security

 Description   

Ron Monzillo's standards-compliant recipe for getting a list of Java EE roles does not return the full set of roles that one would expect.

Specifically, in the absence of deployment descriptors of any kind, if an ear-contained EJB is marked only with a @RolesAllowed(

{ "superusers" }) annotation and not also with a @DeclareRoles({ "superusers" }

) annotation, "superusers" is not returned as one of the application's roles.

More specifically, in such a case an EJBRoleRefPermission for "superusers" is not made available to the JACC policy provider as it should be.

I think this is either a violation of JSR-250 or of the JACC specification. I am not sure which.



 Comments   
Comment by Nithya Ramakrishnan [ 24/Oct/11 ]

Is there a reproducible test case for this issue? Does isUserInRole() work for superusers as expected?

Comment by Nithya Ramakrishnan [ 15/Nov/11 ]

Since we havent got a response about the specific use case, from the description, the situation is as per design.





[GLASSFISH-17154] Unable to access role-protected remote bean using maven-embedded-glassfish-plugin Created: 05/Aug/11  Updated: 08/Mar/12

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1
Fix Version/s: None

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

Attachments: Zip Archive remote-authentication.zip    
Tags: 3_1_2-exclude, community, embedded, security

 Description   

I'm using the maven-embedded-glassfish-plugin to do some integration testing.

I have an .ear file with an ejb.jar file in it. The ejb.jar file contains a single, remote, role-protected EJB in it. This .ear file deploys fine to embedded Glassfish v3.1.1.

Prior to deployment, I use the plugin to set up a user named "scott" with a password "tiger" and assign him to the group "superuser". I get the password in there by using the (recently added, as of Glassfish embedded 3.1.1) --passwordfile option (see http://java.net/jira/browse/GLASSFISH-16277). It is my understanding from looking at the domain.xml that ships as part of embedded-all that default Principal-to-role mapping is turned on. These setup commands, using the AdminMojo, complete normally with an odd-to-decipher but presumably OK SUCCESS message.

In my .ear file Maven project, I have a single unit test that attempts to look up this bean from an embedded Glassfish instance that has been started by the maven-embedded-glassfish-plugin. This lookup fails. The lookup string is correct, as the lookup succeeds if I unprotect the bean by removing the @RolesAllowed annotation.

To perform the lookup, I first do a ProgrammaticLogin. I take care to make sure that the login configuration file is passed as a system property, containing the proper configuration for the default realm. The ProgrammaticLogin of course doesn't actually log anyone in at this point; it just stashes the credentials. This completes normally.

But the lookup fails with a CORBA NO_PERMISSION error.

I'm going to attach a Maven project that demonstrates the issue.



 Comments   
Comment by Bhavanishankar [ 08/Mar/12 ]

assigning to Sakshi.





[GLASSFISH-16885] GlassfishRoleMapper in in-memory JACC package cannot work Created: 21/Jun/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ljnelson Assignee: kumarjayanti
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-exclude, 3_1_1-next, 3_1_1-scrubbed, jacc, security

 Description   

GlassfishRoleMapper.java (http://java.net/projects/glassfish/sources/svn/content/trunk/v3/security/inmemory.jacc.provider/src/main/java/com/sun/enterprise/security/jacc/provider/GlassfishRoleMapper.java?rev=47593) looks like it cannot possibly function.

GlassfishRoleMapper is a RoleMapper implementation that is shipped as part of the in-memory JACC provider. It is supposed to help provide insight into how to do principal-to-role-mapping when implementing a JACC provider. It appears that such role mapping-required for a JACC provider to operate-is impossible? maybe?



 Comments   
Comment by kumarjayanti [ 11/Aug/11 ]

Hi laird,

Is this still an issue or can we close this ?.

Comment by Nithya Ramakrishnan [ 20/Oct/11 ]

Hi Laird,

Do you mean that you need to understand how to provide a custom role mapping using the in memory JACC provider? We could help you with a sample test case, if that is the case. If not, could you please clarify your exact requirements?

Thanks
Nithya

Comment by Nithya Ramakrishnan [ 15/Nov/11 ]

The RoleMapper functionality works as designed.
The cleanup required for the class would be done as part of 4.0





[GLASSFISH-16836] GUI remains blocked when i try to add a new user to realm file . Manage user for security don't work. Created: 10/Jun/11  Updated: 16/Jul/11  Resolved: 06/Jul/11

Status: Resolved
Project: glassfish
Component/s: i18n
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b11

Type: Bug Priority: Major
Reporter: mauro2011 Assignee: gmurr
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

wondows xp and ubuntu linux


Attachments: JPEG File blocked.jpg    
Tags: 31, dont, for, glassfsi, mange, security, user, work

 Description   

i have the equals problem into wondows xp and ububtu .

i have tried to add a user for use of security into a application .
i have tried with default installation of glassfsih with not passaword for admin and with a other installation of glassfish with a password for the admin.

into gui glassfsih admin .
i have write into brower :
localhost:4848
next:
config-server /sedcurity/reaml/file

but when i have reached the panel for manage user , i get a message: "you have reached a process long-time . Wait........
but it remains blocked and i am inable for add the new user ........

help me......

also if i go to change for the password amministrotor it remanis blocked.



 Comments   
Comment by mauro2011 [ 10/Jun/11 ]

the image of panel for add user at realm file for use security into a application.
It remains blocked........
it show:" you have reached a process long.time .Wait....
but it remains into blocked state , and i am inable to add a new user to realm file .

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

but how i an update the locale???????

i am into italy .

Comment by srinik76 [ 10/Jun/11 ]

Please update the locale in which you are trying. In my ubuntu en_US locale it works fine

Comment by srinik76 [ 13/Jun/11 ]

This is reproduced only in it locale. The js error console reports following

Error: missing ) after argument list
Source File: http://localhost:4848/resource/common/js/adminjsf.js
Line: 2724, Column: 69
Source Code:
if ( getConfirm(this,'Impostare una password vuota per l'utente specificato. Continuare?') ){

The string in manage new users page needs to be reviewed.

Transferring this bug to i18n

Comment by Rui Wang [ 27/Jun/11 ]

The issue occurs in IT only because after a new user is added, there is a confirmation about empty password in IT "Impostare una password vuota per l'utente specificato. Continuare?"

For the code :
if ( getConfirm(this,'Impostare una password vuota per l'utente specificato. Continuare?') ){

There is another ' in the string (l'utente) which should be transferred to '/n.

To fix this, we need escape "'" in the translation.

Comment by Anissa Lam [ 27/Jun/11 ]

GUI team realize there will be a problem if there is ' (single quote) in the String that will be displayed in the alert window using Javascript.
Thus, the key for those strings begins with "msg.JS".
eg.

msg.JS.confirmDeletePswdAlias=Selected Password Alias(es) will be deleted. Continue?
msg.JS.confirmEmptyPswdForPswdAlias=Set empty password for this password alias ?

Thus when localizing Strings that starts with msg.JS, special care needs to be taken for single quote. This has been the case since v2.

Comment by gmurr [ 05/Jul/11 ]

The fix will be provided in next translations integration

Comment by gmurr [ 06/Jul/11 ]

Fix will be available in 3.1.1 build 11.

Comment by sunny-gui [ 13/Jul/11 ]

Fixed and verified in build 11 in the two OSs. Here are details.

1.
OS: OEL 5 u5 32bit
Bundle: glassfish-3.1.1-b11-unix-ml.sh
JDK: jdk1.6.0_26-b03 32bit
Browser: FF 3.6.17
Server & Browser Locale: it_IT

2.
OS: Windows XP SP3
Bundle: glassfish-3.1.1-b11-windows-ml.exe
JDK: jdk1.6.0_26-b03 32bit
Browser: FF 3.6.17 and IE 7.0.5730.13
Server locale: en
Browser locale: it_IT

Comment by mauro2011 [ 16/Jul/11 ]

i am mauro that i have signaled the problem .
i ask you :
how i have to resolve???
you have the link of build 3.1.1.build 11 of glassfsih that you have fixed the problem of add user intolocalized version?????

mauro





[GLASSFISH-16238] could not redeploy web application with libraries - Error in linking security policy for Created: 20/Mar/11  Updated: 13/Apr/11  Resolved: 13/Apr/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: 3.1

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

Tags: deployment, security

 Description   

I m having an web application with few jar files namely:
commons-io-1.4.jar
commons-fileupload-1.2.1.jar
gdata-base-1.0.jar

first i could easily deploy the web application with the libraries without any problems
but for the second time i could not re deploy the application

i get the error:
Exception while loading the app : Error in linking security policy for void – Inconsistent Module State

after renaming the jar files to _ wihtout the hyphen i could deploy the application for the first time

but for the second time i could not re deploy the application

Now i consistently getting the error: -

Exception while loading the app : Error in linking security policy for void – Inconsistent Module State
I think i will have fall back to glassfish 3.01 without the recent update

even doing this... deleting the _internal directory and restarting the server did not help

http://www.mentby.com/jacques-21/error-in-linking-security-policy-for-testing-inconsistent-module-state.html

the log files say that:-

===========================================================================================================================

WARNING: Illegal character in path at index 18: file:/D:/Documents and Settings/Administrator/My Documents/NetBeansProjects/void/build/web/WEB-INF/lib/commons_fileupload-1.2.1.jar

java.net.URISyntaxException: Illegal character in path at index 18: file:/D:/Documents and Settings/Administrator/My Documents/NetBeansProjects/void/build/web/WEB-INF/lib/commons_fileupload-1.2.1.jar

at java.net.URI$Parser.fail(URI.java:2809)

at java.net.URI$Parser.checkChars(URI.java:2982)

at java.net.URI$Parser.parseHierarchical(URI.java:3066)

at java.net.URI$Parser.parse(URI.java:3014)

at java.net.URI.<init>(URI.java:578)

at java.net.URL.toURI(URL.java:918)

at com.sun.enterprise.v3.server.SnifferManagerImpl.getURIs(SnifferManagerImpl.java:268)

at com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers(SnifferManagerImpl.java:202)

at com.sun.enterprise.v3.server.SnifferManagerImpl.getSniffers(SnifferManagerImpl.java:150)

at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:604)

at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)

at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)

at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)

at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)

at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)

at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)

at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)

at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)

at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)

at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)

at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)

at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)

at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)

at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)

at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)

at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)

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:619)

INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.

SEVERE: Exception while loading the app

===========================================================================================================================



 Comments   
Comment by kumarjayanti [ 13/Apr/11 ]

Can you please try with GlassFish V3.1 release and let us know if this is still an issue.





[GLASSFISH-15061] [BLOCKING] OAM 11G with LINUX for Basic authentication in the client got failed Created: 08/Dec/10  Updated: 04/Jan/11  Resolved: 28/Dec/10

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_b27
Fix Version/s: 3.1_ms08

Type: Bug Priority: Blocker
Reporter: rameshthiyaga Assignee: kumarjayanti
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux / Windows


Attachments: GIF File b27-linux-11G-results-Page.gif     GIF File b27-Windows-11G-results-page.gif    
Tags: 11G, 3_1, 3_1-blocking, OAM, blocker, security

 Description   

Configure GlassFish v3.1 with OAM 11G as it is given in the document.

To check the OAM server connection provide the URL as http://localhost:8080/BasicAuthen/SecureServlet
in the browser.

Authentication at OAM failed for user : GlassFish

Failure happens in both Windows and Linux platform.



 Comments   
Comment by kumarjayanti [ 08/Dec/10 ]

As far as we can see this seems like the OAM 11g instance has undergone some change w.r.t embedded LDAP configuration that is causing this failure. We have not changed any code in the OAM provider since the last time this test passed.

Have contacted OAM 11g experts at oracle, they have asked us to setup a WebGate to make debugging easier. Will do that in MS_08 timeframe and hopefully this test will pass without requiring any checkins into the OAM security provider.

Comment by kumarjayanti [ 13/Dec/10 ]

There was a problem with the OAM server. Someone had changed it to use an external LDAP instead of the embedded LDAP on which the devtest had configured its users.

Please try now. It works for me now.

Comment by rameshthiyaga [ 14/Dec/10 ]

Hi Kumar,

My windows and Linux system I have checked it and I am getting the same error in the console.
Please check it. I am going to reopen issue If I am not getting any reply before 5.30PM on today.

Thanks,
Ramesh T
On 12/14/2010 1:23 PM, Ramesh T wrote:
> Hi Kumar,
>
> I have tried in Linux system and it is giving the same error in the console.
>
> Please check in
> VNC viewer : ejp-172x-53.india.sun.com:1 ( pwd:abc123)
>
> Thanks,
> Ramesh T

I have provided the system and the login details. The test is getting failed for me. So I am reopening this issue.

Comment by rameshthiyaga [ 14/Dec/10 ]

Hi Kumar,

My windows and Linux system I have checked it and I am getting the same error in the console.
Please check it. I am going to reopen issue If I am not getting any reply before 5.30PM on today.

Thanks,
Ramesh T
On 12/14/2010 1:23 PM, Ramesh T wrote:
> Hi Kumar,
>
> I have tried in Linux system and it is giving the same error in the console.
>
> Please check in
> VNC viewer : ejp-172x-53.india.sun.com:1 ( pwd:abc123)
>
> Thanks,
> Ramesh T

The Basic Authentication test is getting failed in both Linux and Windows after I have seen your rectified mail. As it is reproducible in my systems consistently I am reopening this issue.

Comment by kumarjayanti [ 14/Dec/10 ]

Ramesh,

You come to my seat i will show it is working and give you a live handoff.

We have another person Fabian testing it in France and he has confirmed it is working for him yesterday :
----------------------
On 14/12/10 1:49 PM, Fabian Ritzmann wrote:
> On 11.12.2010 05:56, Kumar.Jayanti wrote:
>> On 10/12/10 8:23 PM, Martin Matula wrote:
>>> Hi Kumar,
>>> This is an interesting datapoint - looks like Fabian was able to get
>>> the Basic auth to work! So, wondering how come you and the QA guys are
>>> still facing the issue. Maybe the wrong ordering of the steps in the
>>> guide that Fabian mentions is the culprit?
>> Fabian, what credentials (username/password) did you supply for BASIC
>> auth to work. Can you send me the screen shot or can i vnc to the system
>> and try it out.
>
> I just tried the basic authentication again, user GlassFish, and it worked this time. Screenshot is attached.
>
yes. it worked for me as well. Someone had changed the OAM config to point to a different ldap so authentication was failing.

regards,
kumar
----------------------------------

Comment by rameshthiyaga [ 16/Dec/10 ]

After the meeting on 15 Dec 2010 at 4PM. The windows 11G is working fine. But in the Linux I am facing the same issue as it is reported.

I have checked in Linux (redhat release-5.5 ) and also with OEL ( Oracle Enterprise Linux ) version 5.

Both the systems are giving the same error as

"Authentication at OAM failed for user: GlassFish" after providing the user / password as : GlassFish/GlassFish.

You can verify the same with the systems that are tested,

Linux (redhat release -5.5)
VNC Viewer : ejp-172x-53.india.sun.com:1 ( abc123 )

OEL
VNC Viewer : ejp-172x-138.india.sun.com:1 ( pwd : abc123 )

I have used the same OEL system for the 10G which got passed early.

As I am getting the failure in the Linux system I am reopening the issue after you have agreed that it is an issue.

Comment by rameshthiyaga [ 17/Dec/10 ]

I have gone through the steps as it is given here,
http://appserver.sfbay.sun.com/Wiki.jsp?page=3.1OAM

ejp-172x-138.india.sun.com
Appserver is installed under :
/space/gf31/b2711G/
AppserverSDK install Loc : /opt/netpoint/AppserverSDK/

Comment by kumarjayanti [ 24/Dec/10 ]

Edited the bug summary since the problem now is only on LINUX and not on WINDOWS, but the summary indicates both Linux and Windows

Comment by kumarjayanti [ 28/Dec/10 ]

VNCed to ejp-172x-138.india.sun.com

When i enter username/password as glassfish/glassfish i get to see the following :

---------------
Servlet SecureServlet at /BasicAuthen
Principal cn=Glassfish,o=company,c=us
---------------

Since the user glassfish/glassfish was created by me on the OAM-10g Backend, i started suspecting that somehow the ASDK is not configured with the 11g AccessGate.

So i tried running the command :

[root@ejp-172x-138 lib]# ./configureAccessGate -i /opt/netpoint/AccessServerSDK -t AccessGate -w GlassfishAG -m open -h cieqalnx01.us.oracle.com -p 5575 -a oam_server1

This was successful however when i observe the file :

/opt/netpoint/AccessServerSDK/oblix/lib/ObAccessClient.xml

which is the main file which the AccessGate client tries to use, i still see that it is pointing to the 10g instance :

<ValNameList
xmlns="http://www.oblix.com"
ListName="primaryServer1">
<NameValPair
ParamName="host"
Value="staqh24-5.us.oracle.com"></NameValPair>
<NameValPair
ParamName="port"
Value="6021"></NameValPair>
<NameValPair
ParamName="numOfConnections"
Value="1"></NameValPair>
</ValNameList>

And this explains why the username/password glassfish/glassfish works whereas GlassFish/GlassFish gives the following error

---------
Authentication at OAM failed for user :GlassFish
---------

1. I tried to manually update the ObAccessClient.xml (stored the old one as ObAccessClient.xml.bak) file to point to the 11g Instance (and restarted GlassFish) :

Now authentication fails for both username/password pairs : glassfish/glassfish as well as GlassFish/GlassFish

2. If i restore it back

-----------
[root@ejp-172x-138 lib]# mv ObAccessClient.xml ObAccessClient.xml.11g
[root@ejp-172x-138 lib]# mv ObAccessClient.xml.bak ObAccessClient.xml
-----------

Again try then username/password pair glassfish/glassfish works successfully but GlassFish/GlassFish does not work again.

So i suspect this has something to do with the fact that the QE is using the same ASDK installation for both 10g and 11g testing and this is somehow causing interference

I would suggest the QE use a Fresh Linux Machine where the ASDK was never configured to work with 10g. Then configure it to work with 11g. This should solve the problem.

Comment by kumarjayanti [ 28/Dec/10 ]

Just shutting down the linux system and restarting it and then executing the following steps before starting glassfish might also help :

cd /opt/netpoint/AccessServerSDK/oblix/lib
mv ObAccessClient.xml ObAccessClient.xml.bak
mv ObAccessClient.xml.11g to ObAccessClient.xml

cd <gf.home>bin
asadmin start-domain

then try to access : http://localhost:8080/BasicAuthen/SecureServlet

Comment by kumarjayanti [ 04/Jan/11 ]

1. There seems to be a problem with configureaccessgate command when executed on linux systems as root.

---------
[root@ejp-172x-138 configureAccessGate]# ./configureAccessGate -i /opt/netpoint/AccessServerSDK -t AccessGate -w GlassfishAG -m open -h cieqalnx01.us.oracle.com -p 5575 -a oam_server1

Please enter the Password for this AccessGate :

Preparing to connect to Access Server. Please wait.

Error: Permission denied

---------

2. Also as observed above when i looked into the Linux systems they seemed to have the 10G OAM address in their ObAccessClient.xml and since the 11g username is GlassFish/GlassFish it will fail on the 10G OAM Server.
3. By manually copying ObAccessClient.xml onto both the systems :ejp-172x-138.india.sun.com, ejp-172x-53.india.sun.com i was able to get the scenario working.

4. From time to time someone sets the default LDAP Server on OAM Server instance to point to an External LDAP instead of the Embedded LDAP on which we have initially created the users for the Dev-Test. So we have to make sure we reset the default to Embedded LDAP before testing these scenarios.





[EJB_SPEC-48] Programmatic login from within EJB components Created: 08/Jan/12  Updated: 05/Apr/13

Status: Open
Project: ejb-spec
Component/s: None
Affects Version/s: 3.2
Fix Version/s: Future version

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: marina vatkina
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: authentication, context, login, security

 Description   

JSR 315 standardized how Servlets should initiate a programmatic login. This now happens via a call to HttpServletRequest#login, where previously a vendor specific mechanism was required.

For EJB components such a programmatic login has not been standardized, which means vendor specific solutions are still required (e.g. the ProgrammaticLogin from GlassFish 3.1). This hurts portability and may make it quite hard for bean providers to accomplish this task (the GlassFish class is easy to find, but for other EJB implementations this can be rather difficult).

I therefor propose to standardize programmatic login from within EJB components.

Such a login should support at least the following use cases:

  • Login from within a local invocation of an EJB (where the call chain e.g. originates in a web component)
  • Login from within a remote invocation of an EJB
  • Login from within an asynchronous invocation of an EJB
  • Login from within a timeout method (both automatic and programmatic)
  • Login from a MDB during message delivery

Some thought should be given to the scope of the established security context. Some ideas:

  • During the invocation of the above mentioned methods/message delivery only.
  • For stateful session beans, for the full life-time of the bean until it is destroyed
  • For all beans, for the full life-time of the bean, but only when login executed in the @PostConstruct method
  • For all beans, for the full life-time of the bean, without restrictions in which method the login is executed

Possibly the API could make a distinction between a method invocation scoped login (first item) and a bean life-cycle scoped login (last three items).

E.g.

@Stateless
public class SomeBean {

    @Resource
    private SessionContext sessionContext;

    public void businessMethod() {
        sessionContext.invocationLogin("username", "password");
        assert sessionContext.getCallerPrincipal().getName().equals("username");
    }
}
@Stateless
public class SomeOtherBean {

    @Resource
    private SessionContext sessionContext;

    @PostConstruct
    private void doLogin() {
        sessionContext.beanLogin("username", "password");
    }

    public void businessMethod() {        
        assert sessionContext.getCallerPrincipal().getName().equals("username");
    }
}


 Comments   
Comment by marina vatkina [ 05/Mar/13 ]

The only alignment with the Servlet spec in the new security features will be support for the predefined "**" role. The rest I'm deferring till next release.





[EASYWEBMIEL-1] java.security.AccessController configuration Created: 08/Feb/15  Updated: 20/Apr/15  Resolved: 20/Apr/15

Status: Resolved
Project: easywebmiel
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8

Type: Bug Priority: Major
Reporter: chrix21 Assignee: chrix21
Resolution: Fixed Votes: 0
Labels: openjdk7
Remaining Estimate: 4 weeks
Time Spent: Not Specified
Original Estimate: 4 weeks
Environment:

Debian GNU Linux Jessie with personalization J'ai l'inux
openjdk-7_7u71-2.5.3


Attachments: Text File stackTrace.txt    
Tags: awt, java, mvc, security, toolkit

 Description   

Hello, Folks!

I am developping a new class for AWT.
This class replaces FileDialog, proposing a Model View Controller approach to this wellknown class.

But in order to integrate this class to AWT and not to disturb other classes, I developped a new Tookit inheriting from UNIXToolkit.

My problem with this toolkit is how to integrate it with the security of Java:

When running the application, here is the stack trace blocking my XJToolkit:

Exception in thread "main" java.lang.IllegalAccessError: tried to access method sun.awt.X11.XlibWrapper.XKeysymToKeycode(JJ)I from class sun.awt.X11.XJToolkit
at sun.awt.X11.XJToolkit.keysymToPrimaryKeycode(XJToolkit.java:1579)
at sun.awt.X11.XJToolkit.setupModifierMap(XJToolkit.java:1657)
at sun.awt.X11.XJToolkit.<clinit>(XJToolkit.java:127)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:379)
at java.awt.Toolkit$2.run(Toolkit.java:881)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:861)
at java.awt.Window.getToolkit(Window.java:1355)
at java.awt.Window.init(Window.java:498)
at java.awt.Window.<init>(Window.java:536)
at java.awt.Frame.<init>(Frame.java:420)
at java.awt.Frame.<init>(Frame.java:385)

This version of Easy Webmiel intends to enforce a strict MVC pattern all over the application, including the GUI.

This means java.awt.FileDialog is not acceptable because it breaks the MVC separation of concern by accessing directly to the file system.

Thanks for your advices.

Cheers,
Chrix21



 Comments   
Comment by chrix21 [ 20/Apr/15 ]

The solution was to modify FileDialog without creating a new JFileDialog. The new FileDialog is retro-compatible with the old behavior.
I am recompiling OpenJDK-7 to test the solution.

I am writing a book in French to explain the need for this architectural change. Contact me if you want explainations.

Best regards,
Chrix21





[CONNECTOR_SPEC-10] Incorrect non-null constraint for serviceSubject in SecurityContext.setupSecurityContext's javadoc Created: 07/Mar/13  Updated: 28/Mar/13  Resolved: 28/Mar/13

Status: Resolved
Project: connector-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 1_6, connector, inflow, javadoc, security

 Description   

The Connector 1.6 (and the current 1.7) javadoc for SecurityContext ( http://docs.oracle.com/javaee/6/api/index.html?javax/resource/spi/work/SecurityContext.html ) has the following erroneous non-null constraint for serviceSubject.

In the description of setupSecurityContext [1], we have the following erroneous line:
"The serviceSubject argument must be non-null and it must not be read-only."

In the spec, and in the same method's 'serviceSubject' parameter javadoc, we talk about serviceSubject being nullable. The correct statement must be
"The serviceSubject argument may be null, and when not null it must not be read-only."

[1] http://docs.oracle.com/javaee/6/api/javax/resource/spi/work/SecurityContext.html#setupSecurityContext(javax.security.auth.callback.CallbackHandler, javax.security.auth.Subject, javax.security.auth.Subject)



 Comments   
Comment by Sivakumar Thyagarajan [ 28/Mar/13 ]

Fixed in the final version of the Connector 1.7 spec.





Generated at Mon May 25 21:02:17 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.