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.
Wednesday, October 31, 2007
Monday, October 22, 2007
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.
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.
We declare the SpringIndexAction in the actionContext.xml file.
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.
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.
Monday, October 15, 2007
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]
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.
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.
Friday, October 12, 2007
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.
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.
Friday, October 05, 2007
WAS 6.1/RSA 7.0 File-based Authentication
To enable file-based authentication,
- start up WAS 6.1 in RSA 7.0
- run administrative console
- security > secure administration, applications, and infrastructure
- check on "Enable administrative security"
- check on "Enable application security" (might be checked on automatically when check on "Enable administrative security")
- check off "Use Java 2 security to restrict ..." (if on, be ready to define web resource and beans and roles)
- select "Standalone custom registry" from the "Available realm definitions"
- click on "Set as current"
- click on "Configuration", the "Standalone custom registry" page will be shown
- click on "Custom properties"
- add two properties, usersFile ${USER_INSTALL_ROOT}/File-based_JACC/users.props, groupsFile $USER_INSTALL_ROOT}/File-based_JACC/groups.props
- 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" - under the newly created folder, create two files, users.props and groups.props,
- in users.props, add entry "wsadmin:password:100:100:Administrator"
- in groups.props, add entry "admins:100:wsadmin:Administrative group"
- go back to "Standalone custom registry" page in the administrative console
- enter "wsadmin" into "Primary administrative user name"
- select "Automatically generated server identity"
- make sure the "Custom registry class name" is "com.ibm.websphere.security.FileRegistrySample" (shall be by default)
- click on "OK" and click on "Save" if asked
- click on "Apply" and click on "Save" if asked
- right click on the "WebSphere Application Server v6.1" in "Servers" view and select "Open"
- expand "Security" and check on "Security is enabled on this server"
- enter "wsadmin" in "User ID" and "password" in "Password"
- save changes made to the server
- restart the server, the server should be ready to use file-based authentication.
Wednesday, October 03, 2007
Ant with JUnit in WID 6.0.2
Since I had a junit task in my ant script, I added the junit.jar into ant::Runtime::Classpath::Global Entries. The interesting part was, WID warned me no tools.jar in the classpath and asked me if I wanted to ignore it.
I searched tools.jar under WID installation. None of them was exactly fit to me. So I decided to ignore it.
Run the ant script, it completed successfully. Question is, what does tools.jar do in ant classpath?
I searched tools.jar under WID installation. None of them was exactly fit to me. So I decided to ignore it.
Run the ant script, it completed successfully. Question is, what does tools.jar do in ant classpath?
IBM WebSphere Integration Developer
Current version is 6.0.2. Updates will be made available through the Rational Product Updater. As I installed it on 10/2/2007, necessary updates were available and required to be installed.
If IBM WebSphere Process Server Test Environment is also installed, its updates are not provided through the Rational Product Updater, but may be obtained by visiting http://www.ibm.com/software/integration/wps/support/. Current updates are Fixpack 2 to 6.0.2, released on 7/31/2007.
Started using WID without updates. Since we use Harvest, I started with installing Harvest plugin. WID 6.0.2 uses Eclipse 3.0.2. Harvest plugin site is the same for Eclipse 3.2, 3.1, and 3.0. The site is http://supportconnectw.ca.com/public/harvesteclipse.
Carefully selected Eclipse 3.0, then plugin version 6.20.2. Check out a project from Harvest, no problem. Synchronize the workspace with Harvest, it suggested removing local files.
Harvest plugin was actually installed under rwd. Locate it and uninstall it. Do the plugin installation again, select 6.20.1 and then carefully select the destination to eclipse not rwd. This time the synchronization worked fine.
WID 6.0.2 uses Sun JDK 1.4.2 as default JRE. It has WAS 5.1 and 6.0, but not 6.1. It has the default perspective Business Integration, the only one cannot be found in Rational Software Architect 7.0.0.3.
- WebSphere Integration Developer Fix Pack 6.0.2.2
- WebSphere Integration Developer 6.0.2.2 Interim Fix 002
- WebSphere Integration Developer 6.0.2.2 National Language Support Interim Fix
- J2EE Connector Tools 6.0.1.5
If IBM WebSphere Process Server Test Environment is also installed, its updates are not provided through the Rational Product Updater, but may be obtained by visiting http://www.ibm.com/software/integration/wps/support/. Current updates are Fixpack 2 to 6.0.2, released on 7/31/2007.
Started using WID without updates. Since we use Harvest, I started with installing Harvest plugin. WID 6.0.2 uses Eclipse 3.0.2. Harvest plugin site is the same for Eclipse 3.2, 3.1, and 3.0. The site is http://supportconnectw.ca.com/public/harvesteclipse.
Carefully selected Eclipse 3.0, then plugin version 6.20.2. Check out a project from Harvest, no problem. Synchronize the workspace with Harvest, it suggested removing local files.
Harvest plugin was actually installed under rwd. Locate it and uninstall it. Do the plugin installation again, select 6.20.1 and then carefully select the destination to eclipse not rwd. This time the synchronization worked fine.
WID 6.0.2 uses Sun JDK 1.4.2 as default JRE. It has WAS 5.1 and 6.0, but not 6.1. It has the default perspective Business Integration, the only one cannot be found in Rational Software Architect 7.0.0.3.
Tuesday, October 02, 2007
JACC - Java Authorization Container Contract
The Java Authorization Container Contract (JACC) is a specification that was introduced in Java 2 Platform, Enterprise Edition (J2EE) 1.4 through the Java Specification Request (JSR) 115 process. This specification defines a contract between J2EE containers and authorization providers. This enables any third-party authorization providers to plug into any J2EE 1.4 Application Servers such as WebSphere to make authorization decisions when a J2EE resource is being accessed. The access decisions is made through the standard java.security.Policy object.
When an authenticated user makes a request to a web or a EJB resource, the security runtime makes the decision of whether to allow the access. This is called an access decision. Based on JACC, the appropriate permission object is created, the appropriate policy context handlers are registered, and the appropriate policy context identifier (contextID) is set. A call is made to the java.security.Policy object that is implemented by the provider to make the access decision.
In IBM WebSphere Application Server (WAS), when security is enabled, the default authorization is used unless a JACC provider is specified. The default authorization does not require special setup, and the default authorization engine makes all of the authorization decisions. However, if a JACC provider is configured and set up for WAS, all of the enterprise bean and web resource access decision will be delegated to the JACC provider.
When an authenticated user makes a request to a web or a EJB resource, the security runtime makes the decision of whether to allow the access. This is called an access decision. Based on JACC, the appropriate permission object is created, the appropriate policy context handlers are registered, and the appropriate policy context identifier (contextID) is set. A call is made to the java.security.Policy object that is implemented by the provider to make the access decision.
In IBM WebSphere Application Server (WAS), when security is enabled, the default authorization is used unless a JACC provider is specified. The default authorization does not require special setup, and the default authorization engine makes all of the authorization decisions. However, if a JACC provider is configured and set up for WAS, all of the enterprise bean and web resource access decision will be delegated to the JACC provider.
Monday, October 01, 2007
WAS 6.1 Startup Error on SystemOut.log
My WAS 6.1 on RSA 7.0.0.3 has this error when starts up.
[10/1/07 9:48:28:785 EDT] 0000000a WrappingFileO E archiveCurrentFile TRAS0016E: An unexpected exception while trying to archive log file C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\server1\SystemOut.log Exception is java.io.IOException: Unable to rename file C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\server1\SystemOut.log to C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\server1\SystemOut_07.10.01_09.48.28.log. Logging continues.It was said on IBM WID Forum that the fix for this issue will be available in 6.0.2.25 fixpack.
Subscribe to:
Posts (Atom)