All | Personal | Quality | SailFin | Security in Glassfish AppServer | Sun
20080613 Friday June 13, 2008

GlassFish security references (part1) GF_security_references

It useful to have a reference for all GlassFish application server related information. Here is what I could collect now ( as part1)!

The security startup information is easily found at  Security FAQ - https://glassfish.dev.java.net/javaee5/security/faq.html

Few other document resources


Technical tips/articles

Blogs

Posted by Jagadesh Babu Munta ( Jun 13 2008, 10:52:01 AM PDT ) Permalink

20070305 Monday March 05, 2007

JAXWS/SSL - How to secure a WS endpoint at transport level (https)

In order to secure webservice endpoints developed using JavaEE components (Servlets/EJB) at transport level (https), there is a easy and simple declarative way in GlassFish application server. The following information helps in understanding and trying out a sample called SSL-JAXWS application in JavaEESDK samples.

You can get the samples bundle from Java EE SDK downloads page.
Steps:
->Java EE Downloads page
->Goto "Download the Components Independently"
->Goto "Java EE 5 Samples Download" and click on download.

Unzip the saved file and browse the samples index page and go to JavaEE5 samples @ .../java_ee_sdk-5_01-samples/javaee5/index.html .
The JAXWS/SSL sample is "webservices/ssl-jaxws-ear" and can be found @ .../javaee5/webservices/ssl-jaxws-ear/docs/index.html Posted by Jagadesh Babu Munta ( Mar 05 2007, 06:44:43 PM PST ) Permalink

20070116 Tuesday January 16, 2007

GlassFishV2: How to see WSS SOAP messages glassfish_v2_webservices debug messages

In GlassFish v2/ Sun Java System Application Server 9.1, one can see the SOAP messages dump in the client console by doing the following 2 simple steps:
1) Edit client container configuration file, sun-acc.xml   to have the log level above WARNING (default) level. Say set at INFO level log.

        <log-service file="" level="INFO"/>

2)  Edit application client configuration file, sun-acc.xml  to update the wss debug property from 'false' to 'true'. See the following highlighted.
Example. <glassfish-install>/domains/domain1/config/sun-acc.xml
      <property name="debug" value="true"/>

Now you can re-run the webservice client again and see that SOAP messages are dumped on to the client console with new security elements (<wsse:>)

Example [ sample client side snapshot]:

     Jan 16, 2007 8:33:06 AM com.sun.xml.wss.impl.filter.DumpFilter process
     INFO: ==== Sending Message Start ====
     <?xml version="1.0" encoding="UTF-8"?>
     <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding
/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc
e" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
     <env:Header>
     <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustU
nderstand="1">
     <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:
Id="XWSSGID-1168965182525-287094422">
     <wsse:Username>j2ee</wsse:Username>
     <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">*
***</wsse:Password>
     </wsse:UsernameToken>
     </wsse:Security>
     </env:Header>
     <env:Body>
     <ns0:getStateTax>
     <double_1 xsi:type="xsd:double">85000.0</double_1>
     <double_2 xsi:type="xsd:double">5000.0</double_2>
     </ns0:getStateTax>
     </env:Body>
     </env:Envelope>
     ==== Sending Message End  ====
         Jan 16, 2007 8:33:13 AM com.sun.xml.wss.impl.filter.DumpFilter process
     INFO: ==== Received Message Start ====
     <?xml version="1.0" encoding="UTF-8"?>
     <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding
/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc
e" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
     <env:Body>
     <ns0:getStateTaxResponse>
     <result xsi:type="xsd:double">24000.0</result>
     </ns0:getStateTaxResponse>
     </env:Body>
     </env:Envelope>
     ==== Received Message End  ====

Posted by Jagadesh Babu Munta ( Jan 16 2007, 01:13:32 PM PST ) Permalink

20060417 Monday April 17, 2006

How to configure Security Manager ON/OFF? By default, the security manager is off on GlassFish, Sun Java System application server. One can enable the security manager by setting the following jvm option in the server configuration and restart the server.

-Djava.security.manager

If the development of the applications happend without security manager and later enabled in the production, there is a possibility that the application need more permissions. These permissions can be set in the domain's server.policy .

How to add JVM option?
Admin console --> http://localhost:4848/ goto ApplicationServer-> JVM Settings -> JVM Options -> Add JVM Option

It is better to test the applications with security manager to get the production ready applications.
Posted by Jagadesh Babu Munta ( Apr 17 2006, 05:01:24 PM PDT ) Permalink Comments [1]

20060314 Tuesday March 14, 2006

WSS security - new XWS providers Webservices providers configuration - latest changes
On latest glassfish or Sun Java System AppServer9 builds, you can observe more default providers in the domain configuration compared to my previous blog entry. This to separate the new providers with old providers supported in previous Sun JavaSystem Appserver 8.1 and maintain the backward compatibility with old developed applications.

These new providers are named as XWS_ServerProvider and XWS_ClientProvider, mainly added the following new features to the earlier providers. 1. By default username token is encrypted. 2. Dynamically determine the encryption key from the request at the server.

At application level, one can use the above providers or configure at server level by default using admin console or CLI.

Enjoy using the Glassfish or Sun Java System Appserver with latest Java EE standards for your applications! Posted by Jagadesh Babu Munta ( Mar 14 2006, 11:43:09 AM PST ) Permalink Comments [1]

20060203 Friday February 03, 2006

Applying security to webservice message layer on glassfish wss_security_blog In this entry,  I am going to provide the basic information on "how one can use the webservices security using Glassfish/ Sun Java System Application Server" where webservices' soap messages can be protected without changing the webservices implementation or invocation code. 

When the webservice client send the soap messages to the webservice endpoint, these soap messages are in clear text. In order to protect your messages from source (client) to destination (endpoint), AppServer providers the message layer security for webservices (uses WS-Security spec defined by OASIS) by injecting <wsse:Security> elements based on the configured policy mechanisms. Glassfish appserver by default configurs the required providers and users can enable and/or change the required policies. The default policy configured in the appserver is Signing (<wsse:BinarySecurityToken> ..<ds:Signature..>).

How to use the default message protection [using default configured policy (Signature) ]-

Here are the basic steps one can use and refer the appserver administration guide for more details on the commands and additional functionality.

1. Enable the server side providers
    Using Admin console-> http://localhost: <adminport>/ 
                         Go to (left frame. click on the nodes) ->Configuration->Security->Message Security-->SOAP
                         Select (right frame) Default Provider ->"Server Provider" from the dropdown list
                                    Default Client Provider ->"Client Provider" from the dropdown list
                          Click "Save" button  (notice that values saved and Restart Required warning)

    Using asadmin  CLI command [    Note that passfile contain "AS_ADMIN_PASSWORD=<password>"] :

i) <appserver>/bin/asadmin  set --user  <admin-user> --passwordfile <passwordfilepath> --port <admin-port> server-config.security-service.message-security-config.SOAP.default_provider=ServerProvider

ii) <appserver>/bin/asadmin  set --user  <admin-user> --passwordfile <passwordfilepath> --port <admin-port> server-config.security-service.message-security-config.SOAP.default_client_provider=ClientProvider

2. Restart the server
   i) Stop domain
    <appserver>/bin/asadadmin stop-domain  <domain-name>
    Ex. /export/munta/as9/bin/asadadmin stop-domain  domain1
   ii) Start  domain
    <appserver>/bin/asadadmin start-domain  <domain-name>
    Ex. /export/munta/as9/bin/asadadmin start-domain  domain1
  
At this point all deployed or future deployed webservices are protected at message layer with Signing policy. Your client should match with the same policy as in the server and is by default no changes required.

3. Enable the clide side provider

    Edit client container configuration file,  <admin.domain.dir>/<admin.domain>/sun-acc.xml   to add a client provider to the soap layer that matched the provider-id.
    Ex. /export/munta/as9/domains/domain1/config/sun-acc.xml   --> add the highlighted provider

<!DOCTYPE client-container ....
<client-container>
  <target-server name="munta" address="munta" port="53700"/>
  <log-service file="" level="WARNING"/>
  <message-security-config auth-layer="SOAP" default-client-provider="ClientProvider">
        <!-- turned off by default -->
        <provider-config class-name="com.sun.xml.wss.provider.ClientSecurityAuthModule" provider-id="ClientProvider" provider-type="client">
        <request-policy auth-source="content"/>
         <response-policy auth-source="content"/>
         <property name="security.config" value="/export/munta/as9pe/lib/appclient/wss-client-config-2.0.xml"/>
 </provider-config>
 </message-security-config>
</client-container>



4. Access the webservice appclient with following  default keyStore and trustStore properties (using Signing or binary token)  and point the -xml to the above xml path (by default it is point to  domain1/config/sun-acc.xml)

     Set the following environment  variable before access the appclient:

   VMARGS ="-Djavax.net.ssl.keyStore=<admin.domain.dir>/<admin.domain>/config/keystore.jks -Djavax.net.ssl.trustStore=<admin.domain.dir>/<admin.domain>/config/cacerts.jks"
  Ex. setenv VMARGS  "-Djavax.net.ssl.keyStore=/export/munta/as9/domains/domain1/config/keystore.jks -Djavax.net.ssl.trustStore=/export/munta/as9/domains/domain1/config/cacerts.jks"


*Your client will be  running normally but messages are protected!

How do I know webservice messages are protected?

You can see the SOAP messages dump in the client console by doing the following 2 steps:
1) Edit client container configuration file, sun-acc.xml   to have the INFO level log.

        <log-service file="" level="INFO"/>

2)  Edit client side wss security configuration file  (don't edit any other elements in the file as this configuration file is mainly used by the server and transparant to the user!)
      at <appserver>/lib/appclient/wss-client-config-2.0.xml  to the following highlighted.
Example. /export/munta/as9pe/lib/appclient/wss-client-config-2.0.xml

<xwss:SecurityConfiguration xmlns:xwss="http://java.sun.com/xml/ns/xwss/config"
                            dumpMessages="true">

Now you can re-run the webservice client again and see that SOAP messages are dumped on to the client console with new security elements (<wsse:)

Example [ note: removed the content (filled with .....)  to reduce the space]:
 Feb 3, 2006 7:26:11 PM com.sun.xml.wss.impl.filter.DumpFilter process
INFO: ==== Sending Message Start ====
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<env:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
<wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-11390235703121194903842">MIIClDCCAf0CBEPkDe4wDQYJKoZIhvcNAQEEBQAwgZAxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpD
.......
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
.......
</wsse:Security>
</env:Header>
<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1139023571163-313201494">
.......
</env:Body>
</env:Envelope>
==== Sending Message End ====

Feb 3, 2006 7:26:12 PM com.sun.xml.wss.impl.filter.DumpFilter process
INFO: ==== Received Message Start ====
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<env:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
<wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-1139023367140-550544941">MIIClDCCAf0CBEPkDe4wDQYJKoZIhvcNAQEEBQAwgZAxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpD
.......
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
.......
</wsse:Security>
</env:Header>
<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1139023571907-1675963724">
.......
</env:Body>
</env:Envelope>

==== Received Message End ====

Posted by Jagadesh Babu Munta ( Feb 03 2006, 07:56:20 PM PST ) Permalink Comments [4]

20060121 Saturday January 21, 2006

How is SSL in Glassfish
The SSL (Secure Socket Layer) or TLS (Transport Layer Security) configuration is so simple and is readily available on Glassfish appserver.The latest version is TLS1.0 or SSL3.0.

The default server certificate installed and configured when the appserver is installed and domain is created. The default SSL port is 8181 unless changed during the installation. Once the installation is done, https://localhost:8181/ should work.

The SSL implementation in glassfish is JSSE (Java Secure Socket Extension) and certificate database is the java standard JKS format. The server certificate is a self signed RSA algorithm without any extensions. It is very usual that one generate a certificate request and get signed with a well known CA (Certificate Authority) certificate and import back into the certificate store (say keystore).

There is a simple page on commands and ant based targets for listing , generating, importing and exporting of certificates with keytool is available at handling certs.

...more to come... have a nice weekend!
Posted by Jagadesh Babu Munta ( Jan 21 2006, 12:55:13 AM PST ) Permalink Comments [5]

Calendar

RSS Feeds

Search

Links

Navigation

Referers