Thursday Oct 29, 2009

Follow up on Servlet 3.0 Security Annotations

In May 2009, I discussed the Servlet 3.0 security annotations in one of my blogs, Servlet 3.0 Security Annotations. At that time, the annotations were defined similar to those in EJB. During the discussion in JSR 315 expert group, two issues were identified as follows:
  1. In JSR 250, type level annotations only apply to methods declared in that class, not those inherited. This is an issue for servlets as they extend javax.servlet.http.HttpServlet.
  2. The doGet method et al may not correspond to http method GET et al as the logic can be overrided in service method of the servlet.

Thanks to Ronald Monzilo for discussions in Servlet 3.0 security. The following is the update on Servlet 3.0 security annotations:

  • As in servlet 2.5, @DenyAll, @PermitAll, @RolesAllowed will not apply to servlets. @TransportProtected will not be added to JSR 250.
  • The following new annotations will be added to javax.servlet.annotation:
    • ServletSecurity
    • HttpConstraint
    • HttpMethodConstraint
    Note that @ServletSecurity is a type level annotation and the rests are used as parameters in @ServletSecurity.
  • With the above new annotations, one can resolve the issue mentioned above. In addition, it covers the new use case where one want to have security constraint for extended http methods only, for instance FOO.

In this blog, I will illustrate how those annotation work. For convenient of readers of my previous blogs, I will first illustrate the four scenarios mentioned in my previous blog, Servlet 3.0 Security Annotations with the new annotations. Then I have an additional example.

Example 1: For all Http Methods

@WebServlet("/myurl")
@ServletSecurity(@HttpConstraint(rolesAllowed={"javaee"}))
public class TestServlet extends HttpServlet {
    ...
}

In this case, all http methods are protected and accessible only by users with role javaee.

Example 2: Http Method Level

@WebServlet("/myurl")
@ServletSecurity(httpMethodConstraints={ @HttpMethodConstraint("GET"),
    @HttpMethodConstraint(value="POST", rolesAllowed={"javaee"}),
    @HttpMethodConstraint(value="TRACE", emptyRoleSemantic=ServletSecurity.EmptyRoleSemantic.DENY) })
public class TestServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }

    protected void doPost(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }

    protected void doTrace(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }
}

The behaviors of the above servlet can be summarized as follows:

Http methodBehavior
GETall can access GET method
POSTonly authenticated users with role javaee can access POST method
TRACEno one can access TRACE method

Example 3: A General Constraint for all Http methods with some Exceptional Cases

@WebServlet("/myurl")
@ServletSecurity(value=@HttpConstraint(rolesAllowed={"javaee"}),
    httpMethodConstraints={ @HttpMethodConstraint(value="POST", rolesAllowed={"staff"}),
    @HttpMethodConstraint("TRACE") })
public class TestServlet extends HttpServlet {
    ...

    protected void doPost(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }

    protected void doTrace(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }
}

The behaviors of the above servlet can be summarized as follows:

Http methodBehavior
POSTonly authenticated users with role staff can access POST method
TRACEall can access TRACE method
methods other than POST and TRACEonly authenticated users with role javaee can access
Note that in the previous definitions, the exceptional cases must be the standard http methods. There is no such restriction for the new annotations as illustrated by the Example 5 below.

Example 4: Https and protected for a given role

@WebServlet("/myurl")
@ServletSecurity(value=@HttpConstraint(
    transportGuarantee=ServletSecurity.TransportGuarantee.CONFIDENTIAL),
    httpMethodConstraints={ @HttpMethodConstraint(value="TRACE", transportGuarantee=ServletSecurity.TransportGuarantee.NONE, rolesAllowed={"javaee"}) })
public class TestServlet extends HttpServlet {
    ...

    protected void doTrace(HttpServletRequest req, HttpServletResponse res)
        throws IOException, ServletException {

        ...
    }
}

The behaviors of the above servlet can be summarized as follows:

Http methodBehavior
TRACEHttps is supported. It just is not required. Only authenticated users with role javaee can access TRACE method
methods other than TRACErequire https

Example 5: Protect FOO only

@WebServlet("/myurl")
@ServletSecurity(value=@HttpConstraint,
    httpMethodConstraints={ @HttpMethodConstraint(value="FOO", rolesAllowed={"javaee"}) })
public class TestServlet extends HttpServlet {
    ...
}

The behaviors of the above servlet can be summarized as follows:

Http methodBehavior
FOOonly authenticated users with role javaee can access POST method
methods other than FOOall can access

Monday May 04, 2009

Servlet 3.0 Security Annotations

Update: The security annotations have been changed. The updated information can be found in my blog, Follow up on Servlet 3.0 Security Annotations.

In Servlet 2.5, only @DeclareRoles and @RunAs are supported in servlets. And @DenyAll, @PermitAll, @RolesAllowed are only supported for EJBs. In JSR 315: Java Servlet 3.0 Specification, @DenyAll, @PermitAll, @RolesAllowed will be supported in servlets. Furthermore, it supports JSR 250: Common Annotations for the Java Platform MR1:

  • @TransportProtected, a new annotation indicates whether the transport is confidential or none.
  • @DenyAll will also be available at the TYPE level.

The mapping of the @DenyAll, @PermitAll, @RolesAllowed and @TransportProtected to security constraint are described in Chapter 13.4.1 of Servlet 3.0 specification. These annotations can be applied to:

  • the servlet class
  • one of the following methods in HttpServlet:
    • doDelete
    • doGet
    • doHead
    • doOptions
    • doPost
    • doPut
    • doTrace
Note that method level authorization annotations (@DenyAll, @PermitAll, @RolesAllowed) override those in class level for the associated http method. Similarly, method level @TransportProtected overrides the one in class level.

In this blog, we illustrate the usages of these annotations by examples.

Example 1: Type Level

@WebServlet("/myurl")
@RolesAllowed("javaee")
public class TestServlet extends HttpServlet {
    ...
}

In this case, all http methods are protected and accessible only by users with role javaee.

Example 2: Method Level

@WebServlet("/myurl")
public class TestServlet extends HttpServlet {
    @PermitAll
    protected void doGet(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }

    @RolesAllowed("javaee")
    protected void doPost(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }

    @DenyAll
    protected void doTrace(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }
}

The behaviors of the above servlet can be summarized as follows:

Http methodBehavior
GETall can access GET method
POSTonly authenticated users with role javaee can access POST method
TRACEno one can access TRACE method

Example 3: Type and Method Level

@WebServlet("/myurl")
@RolesAllowed("javaee")
public class TestServlet extends HttpServlet {
    ...

    @RolesAllowed("staff")
    protected void doPost(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }

    @PermitAll
    protected void doTrace(HttpServletRequest req, HttpServletResponse res)
            throws IOException, ServletException {
        ...
    }
}

The behaviors of the above servlet can be summarized as follows:

Http methodBehavior
POSTonly authenticated users with role staff can access POST method
TRACEall can access TRACE method
methods other than POST and TRACEonly authenticated users with role javaee can access

Example 4: @TransportProtected and @RolesAllowed

@WebServlet("/myurl")
@TransportProtected
public class TestServlet extends HttpServlet {
    ...

    @TransportProtected(false)
    @RolesAllowed("javaee")
    protected void doTrace(HttpServletRequest req, HttpServletResponse res)
        throws IOException, ServletException {

        ...
    }
}

The behaviors of the above servlet can be summarized as follows:

Http methodBehavior
TRACEno https, only authenticated users with role javaee can access TRACE method
methods other than TRACErequire https

Friday May 25, 2007

Comparison of Security features in GlassFish and SJSAS 8.x EE

Security is very essential, especially in the enterprise environment. In this blog, we will compare security of Profiles in GlassFish (GF) v2 and also note those feature availability in Sun Java System Application Server (SJSAS) 8.x Enterprise Edition. Note that Enterprise Profile is not available in public yet and will be in beta around July 2007. More information on Profiles in GlassFish v2 can be found here.

Comparison of Security with GF and SJSAS 8.x EE
FeatureGlassFish SJSAS 8.x EE
v1v2 Development Profilev2 Cluster Profile v2 Enterprise Profile
Support JSR 196 noyesno
KeyStore for SSL JKS NSS
Key/Certificate management tools keytool certutil, pk12util, modutil
Java Security Manageroff (default)on (default)on
Support JDBCRealm yesno
SingleSignOn (SSO)disable (default)enable (default)
Virtual Server Realms noyesno

With JDK 1.5 and NSS 3.11.4, Enterprise Profile in GlassFish v2 and SJSAS 8.x EE (but not available in GF v2 Cluster Profile) support the following:

  • management of the PKCS#11 modules using modutil
  • explicit reference of keys in PKCS#11 providers for https or iiop/SSL listeners. (Note that with JDK 1.5 or later, one can add PKCS#11 providers to a given JDK. But those keys cannot be references by current server.)
  • Elliptic Curve algorithm for SSL and other crypto operations (need Enterprise Profile GlassFish v2 and JDK 1.6)

In SJSAS 8.2 EE and the coming GlassFish v2 Enterprise Profile, there is support for the use of private key in Solaris 10 Softtoken. As an example, let us take a look at how to set up Solaris 10 Softtoken.

  1. Initialize Solaris 10 Softtoken password if you have not.

    /bin/pktool setpin

  2. Register the Solaris 10 Softtoken to NSS.

    modutil -dbdir $SJSAS_HOME/domains/domain1/config -force -add "Solaris 10 Softtoken" -libfile /usr/lib/libpkcs11.so -mechanisms RSA:DSA

  3. Verify that the token is added properly and find out the corresponding token name.

    modutil -dbdir $SJSAS_HOME/domains/domain1/config -list

    A sample output is as follows:

    Using database directory ....
    
    Listing of PKCS #11 Modules
    -----------------------------------------------------------
      1. NSS Internal PKCS #11 Module
             slots: 2 slots attached
            status: loaded
    
             slot: NSS Internal Cryptographic Services                            
            token: NSS Generic Crypto Services
    
             slot: NSS User Private Key and Certificate Services                  
            token: NSS Certificate DB
    
      2. Solaris 10 Softtoken
            library name: /usr/lib/libpkcs11.so
             slots: 1 slot attached
            status: loaded
    
             slot: Sun Crypto Softtoken
            token: Sun Software PKCS#11 softtoken
    -----------------------------------------------------------
      

    In this case, the token name is "Sun Software PKCS#11 softtoken". And this will be used in subsequent commands.

  4. Create a private key and certificate in Solaris 10 Softtoken.

    certutil -S -x -n mytestcert -t "u,u,u" -v 120 -s "cn=j2ee,ou=J2EE,o=Sun,L=Santa Clara,ST=California,C=US" -d $SJSAS_HOME/domains/domain1/config -h "Sun Software PKCS#11 softtoken"

    A sample output is as follows:

    Enter Password or Pin for "Sun Software PKCS#11 softtoken":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
    
    |\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*|
    
    Finished.  Press enter to continue: 
    
    
    Generating key.  This may take a few moments...
      
  5. Change the cert-nickname to "Sun Software PKCS#11 softtoken:mytestcert" in your listeners.

  6. Restart the server, then it will prompt the password for Solaris 10 Softtoken as follows:

    Please enter password for NSS slot Sun Software PKCS#11 softtoken>

About

Shing Wai Chan

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today