Joseph Amrith Raj’s WebSphere Blog

Note: I assume that you’ve already set up your user registry and enabled the administrative security.

If you haven’t finished those steps, refer to previous post.

Having set the administrative security and adding an user registry, now we need to find a way in which we can map the users to different roles.

For example, we do not want everyone to be an administrator. For some people only deployment features in the admin console are enough. some users may need to only monitor the state of the WebSphere through the console.

By default, WebSphere provides few roles, those are listed below

Only for WebSphere v7

Read the rest of this entry »

Once you enable the global security, it applies to security policy for all administrative functions and is used as default security policy for user applications. When you select the Enable administrative security option, the Enable application security and Use Java 2 security to restrict application access to local resources options are selected by default. However, you can clear the Enable application security and Use Java 2 security to restrict application access to local resources options so that they function independently from the Enable administrative security option. So Global security is combination of Administrative security and j2ee security.

from WebSphere v6.1 onwards we have option to enable security while installing/creating the profile. Enabling from these options will use the custom file based repository for storing user names and passwords for authentication.
Before you can enable security for WebSphere Application Server, you must configure a user registry.

For WebSphere v6.1 Click Security > Secure administration, applications, and infrastructure.
for WebSphere v7.0 users have this under security->global security.

Select the Enable administrative security option

Notes:     1. Clear the Enable application security option if you do not want to require WebSphere Application Server to authenticate application users.
2. Clear the Use Java 2 security to restrict application access to local resources option if you do not want to enable Java 2 Security permission checking.

Now select the User account repository

Here we have 4 options:

• • Federated repositories
    The federated repositories functionality enables you to use multiple registries with WebSphere Application Server. These registries, which can be file-based registries, LDAP registries, or a sub-tree of an LDAP registry, are defined and theoretically combined under a single repository.
  • Local operating system
    The implementation is a SAF compliant registry such as the Resource Access Control Facility, which is shared in an MVS sysplex.
  • Standalone LDAP registry
    The standalone LDAP registry settings are used when users and groups reside in an external LDAP directory. When security is enabled and any of these properties are changed, go to the Secure administration, applications, and infrastructure panel and click OK or Apply to validate the changes.
  • Standalone custom registry
    The standalone custom registry feature supports any user registry that is not implemented by WebSphere Application Server. You can use any user registry that is used in the product environment by implementing the UserRegistry interface.

Configure the selected repository and click “set as current”. and then click apply.

Once you’ve applied the new configuration, you need restart all the process (dmgr/node/server) for the administrative security to be in action.

Configuring standalone LDAP for user account repository

I assume that you’ve already set up your LDAP repository.

go to Security->Secure administration, applications, and infrastructure->User account repository->available realm definitions
here select standalone LDAPregistry and click configure

Now, you’ll be taken a new panel, where you configure LDAP for webSphere

First give the primary administrative user name.
This is the primary user WebSphere will use for the server identity. This user must have administrative privileges on LDAP.

Select the server user identity - automatically generate server identity.

Select the type of LDAP server you are using

and you need enter the following details
Host - where you ldap is running (give fully qualified domain name)
Port - port where your ldap is running
Base distinguished Name (DN)
Bind distinguished name (DN)
Bind password

Once gave all the above details, click apply

navigate back to the global security page and click ’set as current’

If you select custom LDAP option in the above step, you may get an error message saying ‘Primary administrative user ID does not exist in the registry error message’. This is because, default LDAP configuration for Custom in WebSphere is set to look for the uid attribute for a common name. You’ll need to set these as per your LDAP.
for example, in OpenLDAP we create a new user using ‘cn’ attribute.

To set this custom field, goto Additional properties-> Advanced Lightweight Directory Access Protocol (LDAP) user registry settings. A default set of predefined filters exist, which are provided for each LDAP server that the WebSphere supports. You can modify these filters to fit your LDAP configuration.

Once your changes are done click apply and save. and then save the changes to master configuration repository. You now have configured WebSphere to use an LDAP registry.

Now that we’ve enabled the administrative security, the next step is to configure the Administrative roles and map the users.

Administrative roles and mapping users will be discussed in the next post.

Part 1/3

Part2/3

Part3/3

The IBM WebSphere Application Server V7 product animations are designed to provide some insight into the product without requiring a significant investment to learn. These animations are overviews and may be updated as the products change.

Follow the below link and  fill the form to download/view the demos

https://www14.software.ibm.com/webapp/iwm/web/signup.do?lang=en_US&source=sw-app&S_PKG=wasdemo&S_TACT=109DA48W?&S_CMP=WBSP

Read the rest of this entry »

• The mod_deflate module provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network.
• mod_deflate allows Apache2 to compress files and deliver them to clients
• With mod_deflate, you can compress HTML, text or XML files to approx. 20 - 30% of their original sizes, thus saving you server traffic.
• Compressing files causes a slightly higher load on the server

How to use it?

1. Enable mod_deflate module

When we install apache2, mod_deflate should also already be installed on system
LoadModule deflate_module modules/mod_deflate.so

2. Configure mod_deflate

We have the option to enable it for the entire apache or just for the specified virtualhots.
Also we can specify which type of files to be deflated.

If you want only a few file types to be deflated
AddOutputFilterByType DEFLATE text/html text/plain text/xml

If you want to compress all file types and exclude just a few like already compressed zip, gzip etc
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary

Whatever you choose from the step2, add the following below that

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

3. Adding log file for viewing results

Now add the following to add the log file to view how much % a particular request was deflated.

DeflateFilterNote Input input_info
DeflateFilterNote Output output_info
DeflateFilterNote Ratio ratio_info
LogFormat ‘”%r” %{output_info}n/%{input_info}n (%{ratio_info}n%%)’ deflate
CustomLog /app/ihs/logs/mod_deflate.log deflate

4. Results

“GET /images/homepage_bg.jpg HTTP/1.1″ 49182/114603 (42%)

This means
homepage_bg.jpg was the images which was deflated
Its actual size is 114603 and size after delated is 49182 and % od deflation is 42.