Tuesday Sep 21, 2010

Security annotations support in Sailfin CAFE

Recently we added security annotations support to CAFE on Sailfin. Though there is lot of work to be
done in this area, please give it a try.


JavaDocs can be found here

Here is musicstore sample bean annotated with security annotations. Though this eliminates the need for sip.xml for
security configuration, you still need to declare role to group or principal mapping in sun-sip.xml

Cafe Security Annotations

Sample security role mappings in sun-sip.xml

Security Role to Group mapping

Permanent link to this entry | Comments [0]

Thursday Jan 21, 2010

Metro performance comparision with Axis2

Its good to see Metro performance comparision (with and without security) against Axis2 from Dennis , please read his articleto find out more. Finally streaming security implementation from Metro team has payed off.

Wednesday Jan 07, 2009

P-Asserted-Identity authentication in Sailfin Communication Server

P-Asserted-Identity authentication in Sailfin is based on RFC 3325 and requirements from JSR 289,

Steps to configure P-Asserted-Identity authentication

We will break the steps to configure P-Asserted-Identity authentication module into following steps,

       1.Configuring security realm
       2.Configuring Trust
       3.Configuring security for SIP Applications

1.Configuring security realm

Refer to section Configuring security realm in my previous blog entry.

2.Configuring Trust

  • Open sailfin administration console, default url will be http://localhost:4848
  • Click on Configuration tab
  • Click on Trust configurations

You can now either create new trust configuration elements or edit if you have already have one.
When you create a new trust configuration you have the option to either choose static configuration or you can write your own custom trust handler(to determine if a host from which message is being received or sent to is trusted).

Here are some snapshots 1 & 2.

Default trust handler provided by Sailfin trusts all hosts and maps the value in P-Asserted-Identity to a format suitable to the container for use in authentication,authorization tasks.For eg: "Cullen Jennings" value will be mapped/formatted to "CullenJ".

3.Configuring security for SIP Applications.

  • Configuration as per JSR 289
           1.Login configuration
           2.Securing methods

  • Implementation specific configuration
           1.Configuring sun-sip.xml

Configuration as per JSR 289.

1.Login configuration

              JSR 289 specific configuration elements (standard configuration) are defined in sip.xml, sip.xml has   following additional elements under login-config.

As per JSR 289 sailfin supports P-Asserted-Identity authentication in two modes (SUPPORTED , REQUIRED). When SUPPORTED value is used then incoming SIP messages are processed as follows

a) if P-Asserted-Identity header is present then process it.

b) if P-Asserted-Identity header is not present then apply the authentication method configured in auth-method element.




          <!-- SUPPORTED/REQUIRED are supported values for identity-assertion-support -->


As per JSR 289 Sailfin supports P-Asserted-Identity authentication in two modes (SUPPORTED , REQUIRED). When SUPPORTED value is used then incoming SIP messages are processed as follows

  a) if P-Asserted-Identity header is present then process it.

  b) if P-Asserted-Identity header is not present then apply the authentication method configured in auth-method element.        
















When P-Asserted-Identity scheme is REQUIRED by the application, the P-Asserted-Identity header MUST be present in the request. If the P-Asserted-Identity header is not present, Sailfin will reject the request with a 403 response. If authorization of the Identity specified by P-Asserted-Identity header fails, Sailfin will return a 403 response.

2.Securing methods

   JSR 289 defines security-constraint( auth-constraints and resource-collection) elements which enables users to configure SIP methods that need to be secured i,e accessed by authorized users.

please refer to sample sip.xml file for more details.

Implementation specific configuration

1.Configuring sun-sip.xml

Following elements and properties need to configured in sun-sip.xml

security-role-mapping  element to enable principal to role mapping

properties trust-id-ref  and trust-auth-realm-ref, please refer to my previous blog entry to know learn about these properties.

Thursday Dec 18, 2008

Configuring NonceManager for Digest and Identity authentication modules

Identity authentication and Digest authentication modules need NonceManager to cache call-id and nonce values respectively.
One can configure the max nonce age for these modules using NonceManager property under Security-Service element in domain.xml. maxNonceAge value is in milliseconds.
"property name="NonceManager" value="id=identity-nonce-config,maxNonceAge=350000;id=sip-nonce-config,maxNonceAge=3000"

NonceManager for Digest authentication module is sip-nonce-config whose default value is 600000 milliseconds.
NonceManager for identity authentication module is identity-nonce-config whose default value is 3600000 milliseconds.

Snapshot of configuring NonceManager using Admin UI is here

Wednesday Jan 02, 2008

Using Digest Authentication with SIP Servlets

It is time to write in detail on how to use security features available in Sailfin, so here we go.

Before you begin follow these two common steps.
  1. Download latest stable sailfin build from here.
  2. Install Netbeans 6.0 with SIP plugin. You will find this installation document useful.

In this entry I will share on how to enable SIP Digest Authentication for SIP Servlet Application and authenticate using a SIP Client(We have tried Twinkle available with Ubuntu and X-Lite)

Step 1:

Create a new SIP Project in Netbeans as shown in Fig1.

Figure: 1

Step 2 :  Create a new Sip Servlet as shown in Figure 2

Figure 2

Step 3 :  Netbeans generates the SIP servlet with empty methods, I changed it to look like what is seen in figure 3.

Figure 3

Step 4 :  Now that we have created the servlet, we will now proceed to configure the application server.
            To do this Start the application server and database using following commands

            To start Sailfin Application server
                        asadmin start-domain domain1

            To start database   
                       asadmin start-database

Figure : 4

Step 5  Login into Admin console( http://localhost:4848 ) and create JDBC resource as shown in Figure 5

 Figure : 5

Step 6 : Now that we have created the JDBC resource we can now go ahead and create JDBC Digest Realm using the Admin console (shown in Figure 6)

Figure:  6

Step 7 :  Next step is to setup the backend . Connect to the database using Netbeans as shown in Figure 7 and run the following sql script.

Figure 7

Step 8 : Now that we have configured both the backend and the application server it is time to enable security in the SIP Servlet application.Create sip.xml and sun.xml as shown in Figure 8 and Figure 9.  The security constraint in sip.xml shows that REGISTER methods should be authenticated and only users with manager role should be allowed to register.

Figure 8

Figure : 9

Step 9 : Now build and deploy the application on to the Sip Application server. You can either do this using Netbeans or command line option (asadmin deploy <filename>).

Step 10 : Once the application is deployed run the SIP Client(In this case I used twinkle) . When the client tries to register user will be requested to enter authentication information as shown in Figure 10 and Figure 11 shows logs in Application server once the user is authenticated and authorized.

Figure: 10

Figure : 11

Powered by ScribeFire.

Monday Sep 24, 2007

Implementing Custom Realms for Digest Authentication in Sun Java System Communication Application Server

Recently we refactored and enabled Digest authentication support for both HTTP and SIP Container in Sun Java System Communication Application Server(SJSCAS/Sailfin).Supporting digest authentication with different backends can be done by writing custom Login modules and a custom realm.

1.Custom Login Module
2.Custom Realm

1.Custom Login module:
can be provided either by extendingcom.sun.enterprise.security.auth.login.DigestLogin abstract class or by implementing javax.security.auth.spi.LoginModule standard interface. If one chooses to extend from DigestLogin module class then below mentioned abstract method has to be implemented. The getGroups method returns all the groups the user belongs to.

protected abstract Enumeration getGroups(String username);

The login module has to be configured in login.conf file under $AS_INSTALL_HOME/domains/domain1/config/login.conf directory.
Eg: of JDBC Digest Login module in login.conf file is shown below


/\* Copyright 2004 Sun Microsystems, Inc. All rights reserved. \*/
/\* SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. \*/

fileRealm {
com.sun.enterprise.security.auth.login.FileLoginModule required;
ldapRealm {
com.sun.enterprise.security.auth.login.LDAPLoginModule required;
solarisRealm {
com.sun.enterprise.security.auth.login.SolarisLoginModule required;
jdbcRealm {
com.sun.enterprise.security.auth.login.JDBCLoginModule required;
jdbcDigestRealm {
com.sun.enterprise.security.auth.login.JDBCDigestLoginModule required;


Sample implementation of DigestLogin Module is shown below.

public class JDBCDigestLoginModule extends DigestLoginModule {

public JDBCDigestLoginModule() {

protected Enumeration getGroups(String username) {

   try {

    return this.getRealm().getGroupNames(username);

   } catch (InvalidOperationException ex) {

   Logger.getLogger("global").log(Level.SEVERE, null, ex);

   } catch (NoSuchUserException ex) {

   Logger.getLogger("global").log(Level.SEVERE, null, ex);


   return null;



2.Custom Realm :

Inorder to provide a custom realm one has to write a new custom realm[1] or modfiy existing realms by extending from com.sun.enterprise.security.auth.realm.DigestRealmBase abstract class. The method validate is an abstract method in DigestRealmBase.

public boolean validate(String username, DigestAlgorithmParameter[] params);

the implementors validate function will have to retrieve the password from the backend and invoke the validate method of the super class. The validate method syntax of the super class DigestRealmBase is shown below. The validate method will return true if digest validation has succeeded or false if digest does not match. The DigestAlgorithmParameter parameter shown below represents the digest algorithm parameters retrieved from incoming SIP/HTTP request.

protected final boolean validate(Password passwd, DigestAlgorithmParameter[] params) throws NoSuchAlgorithmException ;

com.sun.enterprise.security.auth.digest.api.Password is used to pass the password either a prehashed (username+realmname+password) password or plain text password to validate the digest.

public interface Password {

public static final int PLAIN_TEXT= 0;
public static final int HASHED = 1;

\* returns PLAIN_TEXT or HASHED.
\* @returns int
    public int getType();

\* returns password.
\* @returns byte[]
  public byte[] getValue();


This custom realm can be configured for use in SIP/HTTP applications as described in docs [2].

You can download sailfin/SJSCAS builds from https://sailfin.dev.java.net/.


Note : Interfaces and classes described above are subject to improvement and change in future milestone releases of SJSCAS

Powered by ScribeFire.

Wednesday Aug 29, 2007

Sailfin/Sun Java System Communication Application Server/SJSCAS

From past couple of months I have been working on implementing Security features for Sailfin. Sailfin is based on JSR 289 and all the functional specifications that are under development are posted here. You can post your comments on features,requirements using the template posted here.

JSR 289 requires Sailfin to support Digest Authentication and P-Asserted Identity. We have enabled Digest authentication for both SIP and HTTP containers and one should be able to try it out using latest builds. I will soon write on how to configure Digest authentication for HTTP, SIP Containers in SJSCAS/Sailfin.

Tuesday Apr 17, 2007

WSIT Security Configuration

Kumar recently wrote a nice article which covers some important details about WSIT Security Configuration. If you want to learn all about WSIT Security Token Validators then this is the article you need to read.

Wednesday Feb 28, 2007

WSIT at Sun Tech Days 2007 Hyderabad

Kumar and myself had  the opportunity to present on WSIT at Sun Tech Days 2007 Hyderabad. The title of the presentation was "JAX-WS and WSIT : Tangoing with .NET". The talk was well attended and we had to face some interesting questions :). Developers were excited about WSIT and .Net interoperability. The goal of the presentation was to introduce developers to JAXWS , Netbeans and various components of WSIT(Transactions, Optimization, Security,Reliable Messaging , WSIT programming model). Kumar did a demo on JAXWS and RM using Netbeans, this demonstrated how simple it was to write a Web service application and enable WSIT components. 

For those who are still wondering on what WSIT is all about and how it will benefit you or if you have more specific questions or issues, I recommend you to visit us at http://wsit.dev.java.net or post questions on WSIT forum or email us at users@wsit.dev.java.net / dev@wsit.dev.java.net .

WSIT is part of Glassfish v2 builds and can also be downloaded from WSIT .

powered by performancing firefox

Improved XWSS implementation in WSIT Milestone 3

In order to take advantage of new Message design provided in JAXWS 2.1 we revamped XWSS in WSIT milestone 3. XWSS 3.0 now has two implementations of WS Security one is based on DOM/SAAJ api's and other is based on JAXB and StAX api's . We have by default enabled JAXB and StAX based implementation. The performance benefits we get from the default implementation is really exciting. The burden of DOM and SAAJ is no longer needed to support most commonly used security scenarios. I will soon publish the performance improvement we have got over XWSS 2.0. Though the default implementation is efficient it has some limitations in this release of WSIT. We do not support XPATH , i,e we do not support SignedElements and EncryptedElements. We do support this under DOM based implementation.

Ability to switch between these two implementation automatically based on the SecurityPolicy will be supported in future releases of WSIT. In this release we can switch to DOM based WS Security implementation by adding DisableStreamingSecurity policy assertion in wsit-client.xml on client side and wsit.xml/ wsdl on the server side.

Client side assertion :

<sunsp:DisableStreamingSecurity xmlns:sunsp="http://schemas.sun.com/2006/03/wss/client"></sunsp:DisableStreamingSecurity>

Server side assertion :

<sunsp:DisableStreamingSecurity xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"></sunsp:DisableStreamingSecurity>

powered by performancing firefox




« July 2016