Commons Logging and IBM WebSphere 6.1

RSA 7.0.0.3/WAS 6.1.

Apache Commons Logging has a problem with WAS 6.1. Its Log4JLogger either can't be loaded or be reported not compatible with LogFactory.

The root cause is WebSphere uses commons-logging and so it's in the root classloader. In addition, WebSphere ships a commons-logging.properties with the following properties set:

org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger

Therefore by default the application will use JDK logging and not log4j. The solution is to ensure that the right classloader mode is set and the application has an appropriate commons-logging.properties:

Set application classloader mode as PARENT_LAST. Also, add a commons-logging.properties to the application classpath with the following entries:

priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

The priority flag was introduced in Commons Logging 1.1 to allow an ordering based on priority. To ensure that an application's commons-logging.properties will take precedence over WebSphere's file, a priority of greater that 0.0 must be set.

This project needs to migrate WTP metadata

Hello There, I had exactly the same error message and none of the above fixes worked. The problem I found were the following
1) The runtime the old code is still pointing to is WAS 6.0 not WAS 6.1 (in RAD7)
2) RAD7 has more options to change more settings

The Solution: I had to fix the problem on the WAR file that is used by the EAR file Following is my fix for the problem in RAD7 PART I with the WAR PROJECT
\---------------------------
1) Right click on the war project and click on properties.
2) Click on Targeted Runtimes in the properties
3) Now check your desired Runtime WebSphere Application Server 6.1
4) Now click on the WebSphere Application Server 6.1 Runtime in the same window
5) You will see under Runtime Composition com.ibm.ws.ast.st.runtime.61 JRE 5.0: WebSphere v61 JRE
6) Now click on Add/Remove Project Facets link in the same window
7) It opens a new windows Project Facets. This page has dependencies when checking the boxes. Therefore...
8) Here First check Java, I selected the version 5.0.
9) Then check Dynamic Web Module (as I am using web module), I selected 2.4
10) Then check WebSphere Web (coexistence) 6.1
11) Then check WebSphere Web (Extended) 6.1
12) Click Finish
13) Click OK in the properties window
14) Now again open the same properties window
15) You will see new types on the Left Hand Side(LHS) windows namely J2EE Module Dependencies.
16) Click J2EE Module Dependencies. Select from the drop down the EAR file name that should have this WAR file
17) Click Java Build Path on the LHS window.
18) Make sure you see WebSphere Application Server v6.1 under your libraries tab on the Right Hand Side(RHS) window.
19) Click on Project Facets and make sure you see the 4 facets namely Dynamic Web Module, Java, WebSphere Web (Co-existence) and WebSphere Web (Extended) listed with the correct values.
20) Click on the Server on the LHS window.
21) Make sure you see the WebSphere Application Server v6.1 selected on the RHS window. If not, select it.
22) Click on Targeted Runtimes. Mostly you should see this time only WebSphere Application Server v6.1
23) Click OK
24) Manually Refresh and Rebuild this project.

PART II with the EAR project
\----------------------------
1) Right click on the EAR project and click properties
2) Click J2EE module dependencies.
3) Make sure desired xxxxxx.war file is checked.
4) Click on Targeted Runtimes.
5) Make sure you have WebSphere Application server 6.1 is checked
6) Click on project Facets
7) Make sure you have EAR 1.4, WebSphere Web (coexistence) 6.1, WebSphere Web (Extended) 6.1 are selected. If not, go to step 5 and click on the add/remove proejct facets link to do it.
8) click on server and check WebSphere Application Server v6.1
9) Manually Refresh and Rebuild this project.

You should be all set. All the best.

IBM HATS in Passport Advantage

HATS version 7.0 under

Rational Software/IBM WebSphere Host Integration Solution (HIS) for ... v 7.0/

IBM WebSphere Host Access Transformation Services (HATS) Standard v7.0 ... (C97NZML)
IBM WebSphere Host Access Transformation Services Run-Time Web Enablement ... (C97P2ML)

It's so hard to find anything in IBM Passport Advantage.

CICS ECI Resource Adapter - execute timeout

The execute timeout can be specified at creating method in a J2C bean.

0 - No timeout, this is the default value.
any positive int value - in milliseconds

How to Add a VM Argument to WAS 6.1

Actually the WAS 6.1 is the embedded one inside RSA 7.0.

Open the Administrative Console. Navigate through server -> process definition -> Java Virtual Machine -> Customer Variables.

Done.

J2C CICS ECI - Generate Simple JSP

Do the same steps as generate a web service, instead, select Simple JSP at the J2EE Resource Type.

Enter /minzyWeb as the Web project, ou as the JSP folder.

Show Advanced, if the Resource Reference is missing, enter eisOrderUpdateRef.

Click on Finish.

Notice 4 jsp files were created under WebContent\ou.

J2C CICS ECI - Generate Web Service

Start Web Page, Web Service, or EJB from J2C Java Bean wizard.

Enter \minzyConnect\src\tliu\minzy\eis\ou\OrderUpdateJ2CImpl.java as the J2C bean implementation. Click on "Next >".

Select "Web Service" and click on "Next >".

Browse and select /minzyWeb, show advanced and enter eisOrderUpdateRef as the resource reference, keep JNDI lookup name as eis/OrderUpdate as proposed.

Click on Finish.

Notice minzyWeb was changed to have a reference to minzyConnect, 10 classes generated under tliu.minzy.eis.ou, OrderUpdateJ2CImpl.wsdl generated under WEB-INF/wsdl and webservices.xml, etc under WEB-INF.

Note, do not remove the "gen" folder. It is the generated folder for the 10 new classes.

J2C CICS ECI - Generate J2C Bean Classes

Select DIC44010.cpy and start J2C Java Bean wizard.

Select ECIResourceAdapter (IBM 6.0.2.1) under J2C 1.5. (CTG 6.1 needs this match up)

Give eis/OrderUpdate as JNDI name.

Click on "New...", select WAS v6.1 as server.

Enter tcp://10.104.252.233 as Connection URL. (For remote, tcp://, for WAS and CTG on same server, local:), AMGCOHA3 as server, 32006 as the port number, user and password etc.. (configurations here shall be obtained from CTG admin)

After that, enter minzyConnect as project, tliu.minzy.eis.ou as package, OrderUpdateJ2C as interface, the implementation class will automatically be given as OrderUpdateJ2CImpl.

At next step, click on Add... to add a method.

Give updateOrder as the method name.

Click on Browse... and select OrderUpdateBind as input type and check on Use the input type for output.

If execute time out is a required argument, enable the Show Advanced and expand Interaction Spec to select executeTimeout - int.

Click on Finish and enter DIC44010 as the Function name.

Click on Finish and generate the J2C Java bean.

Notice the OrderUpdateJ2C and OrderUpdateJ2CImpl were created under tliu.minzy.eis.ou, cicseci6021 i was created and minzyConnect was updated to have cicseci6021 in its build path.

J2C CICS ECI - Generate J2C Data Binding Classes

Select the DIC44010.cpy file and summon the J2C CICS/IMS Java Data Binding wizard.

Choose mapping COBOL to Java.

Select z/OS for Platform, IBM-037 for Code page. Click on Query.

Select the DFHCOMMAREA which is the CICS common area.

Select "Shorten names" as Generation Style, minzyConnect as project, tliu.minzy.eis.ou as package, OrderUpdateBind as class.

Class OrderUpdateBind, OrderUpdateBind_DFH_PAL_ID_DATA_DFH_EPC_DATA and OrderUpdateBind_DFH_PAL_ID_DATA will be created under tliu.minzy.eis.ou.

J2C CICS ECI - Obtain COBOL Copybook

RSA J2C wizard in version 7 accepts only the copybook of common area. It used to accept the whole COBOL program in WSAD version 5.1. I obtained the whole program and I found out I needed to trim it to the copybook only and rename it from DIC44010.ccp to DIC44010.cpy. The wizard actually tells the difference between ccp and cpy.

The copybook looks like this,

01 DFHCOMMAREA.
02 DFH-INPUT-FIELDS.
05 DFH-MRG-NBR PIC 9(07) VALUE ZEROS.
05 DFH-DC-NBR-FILLING PIC X(02) VALUE SPACES.
05 DFH-SESSION-CNT PIC 9(02) VALUE ZEROS.
05 DFH-PAL-ID-DATA OCCURS 5 TIMES.
10 DFH-PAL-ID-NBR PIC 9(03) VALUE ZEROS.
10 DFH-PAL-EPC-NBR PIC 9(09) VALUE ZEROS.
10 DFH-EPC-DATA OCCURS 300 TIMES.
15 DFH-EPC-NBR PIC 9(12) VALUE ZEROS.
02 DFH-STATUS-FIELDS.
05 DFH-RETURN-CODE PIC 99 VALUE ZEROS.
05 DFH-RETURN-TEXT PIC X(80) VALUE SPACES.
05 DFH-PROGRAM-NAME PIC X(08) VALUE SPACES.
05 DFH-ERROR-STATUS PIC X(04) VALUE SPACES.
05 DFH-ERROR-RECORD PIC X(16) VALUE SPACES.
05 DFH-ERROR-SET PIC X(16) VALUE SPACES.
05 DFH-ERROR-AREA PIC X(16) VALUE SPACES.
05 DFH-DML-SEQUENCE PIC 9(08) VALUE ZEROS.

Do not edit the file.

I created a eis folder under minzyConnect. I put DIC44010.cpy under the newly created eis folder.

J2C CICS ECI - Review the Environment

In this trial, I will create a J2C service to call a CICS COBOL program. I use

• IBM Rational Software Architect (RSA) v 7.0.0.3
• IBM WebSphere Application Server (WAS) v 6.1, embedded in RSA 7
• IBM CICS Transaction Gateway (CTG) v 6.1

CTG connection URL is tcp://10.104.252.233, port 32006, server name AMGCOH3, user name ctgwebu, and password ***.

Note, if WAS and CTG sit at the same server, CTG connection URL shall be local:.

Project minzyConnect is created to hold the data binding and J2C beans.

Project minzy is created as EAR holder, and its module project minzyWeb, minzyEnt (for EJB), and minzyClient are also created.

CICS Transaction Gateway

Connection URL set to "local" if the servlet sits at the same server. Set to "tcp:" if the servlet needs to connect a remore CICS Transaction Gateway, e.g. tcp://9.100.101.102:2006.

Informatica Upgrade to 8.1.1 - Client

Informatica is a Web Service Hub. When the server upgrades to 8.1.1, from the client side, do the followings,

1. Open the Hub's home page, e.g. http://host:7333/wsh/
2. Click on the "Batch Web Services"
3. Click on the WSDL icon under Metadata WSDL
4. Right click on the pop-up page and select "View Source"
5. Save the content as MetaData.wsdl
6. Do the same for DataIntegration WSDL, save as DataIntegration.wsdl
7. Import these two files to a RSA project
8. Add axis-1.4.jar to the project
9. Create a Java Application Run,
10. Set main class as org.apache.axis.wsdl.WSDL2Java
11. Check "Include libraries when searching for a main class" on
12. Select Arguments tab
13. Enter "--NStoPkg http://www.informatica.com/wsh=com.informatica.www -W informatica-8.1.1/MetaData.wsdl" as Program arguments, where the informatica-8.1.1 is the folder of MetaData.wsdl file
14. Run this Java Application
15. Informatica client code for MetaData service will be generated
16. Do the same for DataIntegration service
17. There are some changes from version 7, especially of the connection, workflow and folder
18. Modify the client application accordingly

CICS ECI Resource Adapter

The CICS resource adapter makes use of interfaces within J2EE Connector Architecture to facilitate the communication between J2EE applications and CICS information systems. The JCA defines a programming interface called the Common Client Inteface (CCI). This interface can be used, with minor changes, to communicate with any EIS. This CICS Transaction Gateway provides resource adapters that implement the CCI for interfactions with CICS.

• ECIResourceAdapter (IBM : 5.1): This version of the CICS ECI resource adapter is based on Version 1.0 of the J2EE Connector Architecture (JCA 1.0). Because CICS ECI resource adapter for Java verion 5.1 is a JCA 1.0 resource adapter, it will only run in a JCA 1.0 application server or WAS version 5.0.2 (or above). Select CICS 5.1 resource adapter if targeting a WAS v 5.0 server.
• ECIResourceAdapter (IBM : 6.0.2): This version of the CICS ECI resource adapter is based on version 1.5 of the JCA (JCA 1.5). It runs on WAS 6.0.
• ECIResourceAdapter (IBM : 7.0.0): This version based on JCA 1.5. It runs on WAS 6.1.

If you select Configure Resource Adapter Deployment on the Deployment Information page of the J2C wizard, you can use the Resource Adapter Deployment page to configure RAR.

The resource adapter can be deployed as a standalone resource adapter or as part of an EAR file. Typical environments use the standalone method, giving all modules on the application server visibility to the adapter.

Note: Multiple resource adapters should not be installed as standalone on the same runtime server, especially if they are for the same EIS type (for example, CICS ECI 5.1 and CICS ECI 6.2). This is because all standalone resource adapters share the same class loader.

My note: It's probably easier for application maintanence to deploy the adapter per EAR file.

Axis 1.1 and 1.2

Some Web Service software, such as Informatica, generate stub classes to access web services. Some classes were generated based on Axis 1.1 and they use org.apache.axis.enum.Style.

In Axis 1.2, that class has been replaced by org.apache.axis.constants.Style. When clients try to make connections to web services, it will get an error that enum.Style cannot be found.

I think it will solve the problem to regenerate the stub classes with Axis WSDL2Java emitter from the WSDL definition files. We will see the result after several days.

DelegetingActionProxy

DelegetingActionProxy solves the problem of having to create an action as subclasses of ActionSupport. It is better to define beans in the Spring application context are proxies to the Struts Actions.

For example, class SpringIndexAction extends Action and declares a setter for the productionManager property. We add an action declaration to the Struts configuration file struts-config.xml.

[action path="/sindex"
type="org.springframework.web.struts.DelegatingActionProxy"
validate="false"]
[forward name="success"
path=".index"/]
[/action]

Notice the action type is set to DelegatingActionProxy, which is a Spring class that delegates all calls to the real bean of the SpringIndexAction class.

Before we can use DelegatingActionProxy, we first need to add the ContextLoaderPlugin bean to the Struts configuration file.

[plug-in
className="org.springframework.web.struts.ContextLoaderPlugin"]
[set-property property="contextConfigLocation"
value="/WEB-INF/actionContext.xml"/]
[/plug-in]

We declare the SpringIndexAction in the actionContext.xml file.

[beans]
[bean name="/sindex" class="com.....actions.SpringIndexAction"]
[property name="productManager"][ref
bean="productManager"/][/property]
[/bean]
[/beans]

When we now make a request to the /sindex.do URL, DelegatingActionProxy looks up the bean with its name set to /sindex. It uses the beans defined in the WebApplicationContext that is loaded by the ContextLoaderPlugin declared in the file specified in its contextConfiguration property. The /sindex bean is the actual SpringIndexAction, it is instantiated, and its productManager property is set.

The difference after using DelegetingActionProxy is that the SpringIndexAction is a fully Spring-managed bean and we have no manual dependency lookup code in the Action.

Form-based Authentication in WAS

Form-based login

One of the login challenges defined in J2EE Specification is form-based login. It enables the application developer to customize the login process and present an application-specific form by making use of the Form Login Authentication Method.

Form login works in the following manner:

1. An unauthenticated user requests a resource protected by the Form Login authentication type.
2. The application server redirects the request to the Login Form defined previously in the Web deployment descriptor.
3. On the HTML login form, the user enters the user ID and password and submits the form.
4. The action triggered by the form submission runs a special WebSphere Application servlet j_security_check. The Web container, after receiving a request for the j_security_check servlet, dispatches the request to another WebSphere servlet that authenticates the user.
5. If the servlet authenticates the user successfully, the originally requested resource is displayed.

Form login configuration using WebSphere Studio

1. Open the web.xml file under the Web project. A Web Deployment Descriptor should be opened in a deployment descriptor editor window.
2. Select the Pages tab, then modify the Login section.
3. Type in the realm name, for example: SecureRealm.
4. Click the drop-down list and select FORM as the Authentication method.
5. In the Login page, click Browse and select your login page from the project, for example: /login/login.html.
6. In the Error page, click Browse and select your login page from the project, for example: /login/loginerror.html (we have used the same page for login and error, but you can define a custom error.jsp page that will present actual error code and error messages).
7. Save and close the Web deployment descriptor file.

Setting the Authentication Method for the application Web module will create a [login-config] section in a Web deployment descriptor XML file, as shown in the following example.

[login-config]
[auth-method]FORM[/auth-method]
[realm-name]SecureRealm[/realm-name]
[form-login-config]
[form-login-page]/login/login.html[/form-login-page]
[form-error-page]/login/loginerror.html[/form-error-page]
[/form-login-config]
[/login-config]

Simple form-based login does not require any extra code development on the server side. The j_security_check servlet used by WebSphere Application Server enforces only the name of the input fields that the developer should put in the custom Login Form. These fields are as follows:

* j_username should be the input field in which a user will type the user ID.
* j_password should be the input field into which the user will type the password.

The action required for the HTTP POST method is j_security_check. A simple HTML code for the custom Login Form is given in the following example:

[!-- ............... --]
[form method="post" action="/itsobank/j_security_check"]
[table width="80%"]
[tr]
[td width="20%" align="right"]Userid:[/td]
[td][input size="20" type="text" name="j_username" maxlength="25"][/td]
[/tr]
[tr]
[td align="right"]Password:[/td]
[td][input size="20" type="password" name="j_password" maxlength="25"][/td]
[/tr]
[tr]
[td][/td]
[td][input type="submit" name="action" value="Login"] [input type="reset" name="reset" value="Clear"][/td]
[/tr]
[/table]
[/form]
[!-- ............... --]

Form-based logout

One of the IBM’s extensions to the J2EE Specification is the form-based logout. After logging out, the user is required to re-authenticate to have access to protected resources again. This logout form can be on any page with calling a POST action on the ibm_security_logout servlet. This form must exist within the same Web application to which the user gets redirected after logging out.

[form method="post" action="ibm_security_logout" name="logout"]
[input type="submit" name="logout" value="Logout"]
[input type="hidden" name="logoutExitPage" value="/login/login.html"]
[/form]

A Real Case with WAS Security

This case worked under RSA 7.0 and WAS 6.1.

In the application, it defined two roles, tliu:passw0rd:101:101:Thomas Liu and authenticated_user. Only users with administrator role can access administrator pages and carry out administrator functions. Any users authenticated with a pair of user id and password can access general pages and carry out general functions.

In the application.xml file of the EAR project, two security-roles were defined.

[security-role id="admin"]
[role-name]administrator[/role-name]
[/security-role]
[security-role id="user"]
[role-name]authenticated_user[/role-name]
[/security-role]

In the ibm-application-bnd.xml file of the EAR project, one authorization table with two authorizations was defined.

[authorizationTable xmi:id="AuthorizationTable_1126620398213"]
[authorizations xmi:id="RoleAssignment_1126807102767"]
[specialSubjects
xmi:type="applicationbnd:AllAuthenticatedUsers"
xmi:id="AllAuthenticatedUsers_1140011292114"
name="AllAuthenticatedUsers" /]
[role
href="META-INF/application.xml#user" /]
[/authorizations]
[authorizations xmi:id="RoleAssignment_1140011292114"]
[role
href="META-INF/application.xml#admin" /]
[groups xmi:id="Group_1140011292114" name="ceadmin" /]
[/authorizations]
[/authorizationTable]

In the web.xml file of the web project, two security-constraint, one login-config, and two security-role were defined.

[security-constraint]
[display-name]Administrators Constraint[/display-name]
[web-resource-collection]
[web-resource-name](Administrator Web Resource Collection)[/web-resource-name]
[description][/description]
[url-pattern]/admin/*[/url-pattern]
[http-method]GET[/http-method]
[http-method]PUT[/http-method]
[http-method]HEAD[/http-method]
[http-method]DELETE[/http-method]
[http-method]OPTIONS[/http-method]
[/web-resource-collection]
[auth-constraint]
[description][/description]
[role-name]administrator[/role-name]
[/auth-constraint]
[user-data-constraint]
[transport-guarantee]NONE[/transport-guarantee]
[/user-data-constraint]
[/security-constraint]
[security-constraint]
[web-resource-collection]
[web-resource-name](Users Web Resource Collection)[/web-resource-name]
[description][/description]
[url-pattern]/document/*[/url-pattern]
[http-method]GET[/http-method]
[http-method]PUT[/http-method]
[http-method]HEAD[/http-method]
[http-method]POST[/http-method]
[http-method]DELETE[/http-method]
[/web-resource-collection]
[auth-constraint]
[description][/description]
[role-name]authenticated_user[/role-name]
[/auth-constraint]
[user-data-constraint]
[transport-guarantee]NONE[/transport-guarantee]
[/user-data-constraint]
[/security-constraint]
[login-config]
[auth-method]FORM[/auth-method]
[form-login-config]
[form-login-page]/login.do[/form-login-page]
[form-error-page]/login_error.do[/form-error-page]
[/form-login-config]
[/login-config]
[security-role]
[description][/description]
[role-name]administrator[/role-name]
[/security-role]
[security-role]
[description][/description]
[role-name]authenticated_user[/role-name]
[/security-role]

The above login-config enabled the application to use a WebSphere extension called Form-based authentication. WAS Form-based authentication will be introduced in a later post.

In WAS administrative console, in Applications - Enterprise Applications - [Appl] - Security role to user/group mapping, there were two lines

Role | Everyone? | All authenticated? | Mapped users | Mapped groups
authenticated_users | unchecked | checked | null | null
administrator | unchecked | unchecked | null | ceadmin

WAS was defined to use File-based J2EE security. See a previous post about File-based J2EE security for details.

In the groups.props, add a line ceadmin:101:tester:CE Administrative Group, where the 101 was the group number.

In the users.props, add a line tester:password:101:101:CE Admin Tester, where the first 101 was the user number and the second group number.

With the above definitions, the application was able to make use of WAS security and can distinguish users by their authentication and role.

LDAP Browser in Eclipse

Actually I was installing LDAP browser plugin in my Rational Software Architect 7. I defined a remote update site using the URL http://directory.apache.org/studio/update/1.x and installed the LDAP Browser on my RSA.

That site was somehow a little bit weird. I tried the connection for several times before I was able to see the LDAP browser selection.

I used the "Connections" view to set up a new connection to LDAP server. After connected, I switched to the LDAP Browser view and saw three roots, DIT, Searches and Bookmarks.

The LDAP server which I connected was quite a big one. I easily got lost in the DIT tree. So I had to use the search. I learned something new here which was called the LDAP query.

For example, I needed to search any records that has a uid of ABC. What I needed to put in the "Filter" was (&(uid=ABC)). In my application, it had a query like (&(cn=my_group)(member=uid={0}, *)). It was very interesting, at least to me, since LDAP query was a new thing to me.

The searching speed was actually quite cool. Boom, the result was out. Since I would need to view that record from time to time. I saved it as a bookmark.

So far, the experience was good.

WAS 6.1/RSA 7.0 File-based Authentication

To enable file-based authentication,

1. start up WAS 6.1 in RSA 7.0
   
2. run administrative console
3. security > secure administration, applications, and infrastructure
4. check on "Enable administrative security"
5. check on "Enable application security" (might be checked on automatically when check on "Enable administrative security")
6. check off "Use Java 2 security to restrict ..." (if on, be ready to define web resource and beans and roles)
   
7. select "Standalone custom registry" from the "Available realm definitions"
8. click on "Set as current"
9. click on "Configuration", the "Standalone custom registry" page will be shown
10. click on "Custom properties"
11. add two properties, usersFile ${USER_INSTALL_ROOT}/File-based_JACC/users.props, groupsFile $USER_INSTALL_ROOT}/File-based_JACC/groups.props
12. in Windows explorer, go to folder \runtimes\base_v61\profiles\AppSrv01, e.g. C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01, and create a new folder "File-based_JACC"
13. under the newly created folder, create two files, users.props and groups.props,
14. in users.props, add entry "wsadmin:password:100:100:Administrator"
15. in groups.props, add entry "admins:100:wsadmin:Administrative group"
16. go back to "Standalone custom registry" page in the administrative console
17. enter "wsadmin" into "Primary administrative user name"
18. select "Automatically generated server identity"
19. make sure the "Custom registry class name" is "com.ibm.websphere.security.FileRegistrySample" (shall be by default)
20. click on "OK" and click on "Save" if asked
21. click on "Apply" and click on "Save" if asked
22. right click on the "WebSphere Application Server v6.1" in "Servers" view and select "Open"
23. expand "Security" and check on "Security is enabled on this server"
24. enter "wsadmin" in "User ID" and "password" in "Password"
25. save changes made to the server
26. restart the server, the server should be ready to use file-based authentication.