Encode and Decode WAS Password

Hi All,

Please follow below method to encode/decode password:

Encode:

$WAS_BINARIES/java_1.7_64/jre/bin/java -Djava.ext.dirs=$WAS_BINARIES/plugins:$WAS_BINARIES/lib com.ibm.ws.security.util.PasswordEncoder abcdef

Output:

decoded password == "abcdef", encoded password == "{xor}Pj08Ozo5"

Decode:

$WAS_BINARIES/java_1.7_64/jre/bin/java -Djava.ext.dirs=$WAS_BINARIES/plugins:$WAS_BINARIES/lib com.ibm.ws.security.util.PasswordDecoder {xor}Pj08Ozo5

output:

encoded password == "{xor}Pj08Ozo5", decoded password == "abcdef"

Add Certs to WAS Truststore

1)     Go to Websphere Console

2)     Click on Security -> SSL Certificate and Key Mgmt -> Manage endpoint security configurations

3)     Click on node 1 (inbound/outbound - NodeDefaultSSLSettings) -> Check and note down“Inherited SSL Configuration Name”

4)     Click on Security -> SSL Configurations -> “Inherited SSL Configuration Name”

5)     Note “Trust Store name”

6)     Click on Key Stores and certificates

7)     Take backup of trust.p12 path mentioned in front of “Trust Store name”.

8)     Click “Trust Store name” -> Signer Certficates

9)     Place the cert on that node at any location.

10)  Click on Add

11)  Name it anything (Preferred – name of the URL)

12)  Give complete path of the cert.

13)  Restart all Nodeagents and app servers for changes to take place.

Liberty Profile

Introduction to Liberty Profile:

• The Liberty profile provides a simplified stand-alone run time for web applications, supporting a subset of the programming model and run time features available with the full profile. Any application that runs on the Liberty profile will also run on the full profile.
• It is a good option for developers who are building web applications that do not require the full Java EE environment of traditional enterprise application server profiles. For production environments, enterprise qualities of service, such as security and transaction integrity, are enabled as required.
• Liberty profile instances are stand-alone servers similar to application server profiles;however, they are characterized by a dynamic runtime based on the OSGi model. This design allows you to configure the server runtime stack and features in real time. This design also results in a small server footprint and fast startup time because the server uses only feature that are needed by the applications. For example, if an application requires just a servlet engine, Liberty profile can be configured to only start the WebSphere Application Server kernel, an HTTP endpoint for connection, and a web container. If the application needs additional features, such as database connectivity, the Liberty profile configuration can be dynamically modified to include the JDBC feature without the need of a server restart.
• The Liberty profile includes the following key features:

• • A dynamic and flexible run time to load only what the application needs
  • A quick startup time (under 5 seconds with simple web applications)
  • A simplified configuration that uses a single configuration file or modular configuration
  • Support for deploying applications developed in the Liberty profile to run in the full profile
  • Support of web applications, OSGi applications, and Java Persistence API
  • (New in V8.5.5) Support for web services
  • (New in V8.5.5) Support for Java Messaging Support (JMS)
  • A secure server environment. User registry options include single or (New in V8.5.5) federated LDAP registries, role based authorization, SSL, single sign-on, custom login modules, (New in V8.5.5) OAuth support, and more.
  • (New in V8.5.5) Support for the use of MongoDB, a NoSQL database system. The server and client drivers are not shipped with WebSphere Application Server.
  • Ability to deploy an application and configured server as a package
  • (New in V8.5.5) Ability to extend the Liberty profile with custom features
  • (New in V8.5.5) Ability to cluster servers for high availability and scalability
  • (New in V8.5.5) Centralized operational management of groups of Liberty servers and of Liberty clusters.
  • Managed, centralized deployment for many nodes of a packaged application and server using the Job Manager.
  • Availability of WebSphere Application Server Developer Tools as Eclipse plug-ins for broad tool support
  • Support for z/OS platform native features such as System Authorization Facility (SAF),
  • Resource Recovery Services (RRS), and z/OS Workload Manager (WLM)
• The Liberty profile comprises the Liberty profile kernel and any number of optional features that run inside of a single Java Virtual Machine (JVM) process. Most of the kernel runs as OSGi bundles within an OSGi framework. The Liberty profile requires Java Runtime Environment version 6 or higher.
• When the server is started, the launcher bootstraps the kernel and starts the OSGi framework. The server configuration is parsed, and features are loaded by the feature manager. The kernel makes extensive use of OSGi services to provide a highly-dynamic runtime:
• System configuration is managed by the OSGi configuration admin service.
• The OSGi declarative services component is used to manage the lifecycle of system services.
• Application and configuration file changes are detected by the file monitor service. The file monitor service detects changes that are then reflected in real-time updates.

Configuration: 

1) You can obtain the latest Liberty profile package from the following WASdev community website:

click on WASDevCommunity

2) Configuring JRE

• The Liberty profile requires a Java Runtime Environment to run in. By default, it does not share the Java Runtime Environment with the WebSphere Application Server, so you must specify the JRE location. The JVM on the system PATH is used by default.

The Liberty profile runtime searches for the java command in the following order of properties:

• JAVA_HOME, JRE_HOME and PATH.
• Additionally, you can use the Liberty profile server.env configuration file to set up a specified Java Runtime. To configure the Java runtime using this file, add the following line into the file:
• JAVA_HOME=C:\IBM\jre6
• If the file does not exist, you must create it manually in the Liberty profile etc directory.
  
• Installing the Liberty profile is as simple as running a self-extracting archive. The WASdev web site provides three archives for V8.5.5:
• Liberty profile: wlp-developers-runtime-8.5.5.0.jar - This archive contains the Liberty core features (equivalent to the V8.5.0 Liberty profile) plus the features that complete the web profile support.
• Extended content for Liberty profile: java -jar wlp-developers-extended-8.5.5.0.jar - This archive includes web services, messaging, and MongoDB support. 
• Embeddable EJB container: java -jar wlp-developers-extras-8.5.5.0.jar - This archive includes the embeddable EJB container and JPA client.
• To manually install a Liberty profile archive:
• java -jar wlp-developers-runtime-8.5.5.0.jar
• Press x to skip reading the license terms, or press Enter to view them.
• Press Enter to view the license agreement.
• Press 1 if you agree to the license terms and want to proceed.
• Provide the installation path for the Liberty profile, for example C:\IBM\WebSphere, and press Enter.
• Server:
• Run following Command to create the server: server create server1
• Run following Command to start the server: server run server1
• Starts the server in debug mode: server debug server1
• Stop: server stop server1
• Status: server status server1
• Configuration:

• server description should include Server Name
• feature - what feature we need to enable
• host - hostname on which the JVM is installed
• port - WC Default Host and WC Default Host Secure
• Application ID - Name of the WAR
• location - Full path of war file
• name - Name of the WAR 
• type - WAR
• if we need to add Data Source Config: We can use include statement as demonstrated below:
  
  
  
  
  
  
• The bootstrap.properties file is the second file that can be used for the Liberty profile server configuration. Changes to this file require the server to be restarted. By default this file is not generated when you create the Liberty profile server instance. If you want to use this file, you first have to create it. Place this file in the main server directory along side the server.xml file. The bootstrap properties are generally used to initialize the runtime environment for a particular server.
• Data Source Configuration:

• Parameters:

  Attribute name	How the configuration update is applied
  beginTranForResultSetScrollingAPIs	The update is effective immediately.
  beginTranForVendorAPIs	The update is effective immediately.
  commitOrRollbackOnCleanup	The update is effective immediately.
  connectionManagerRef	All connections and the connection pool are destroyed. The data source is then managed by the new connection manager
  connectionSharing	The update is applied with each first connection handle in a transaction.
  isolationLevel	The update is applied with new connection requests. Current connections retain their isolation level
  jdbcDriverRef	All connections and the connection pool are destroyed. The new JDBC driver is then used.
  jndiName	All connections and the connection pool are destroyed. The new JNDI name is then used.
  propertiesRef	If the data source is Derby Embedded, all connections and the connection pool are destroyed before new properties go into effect. For other JDBC drivers, the new properties go into effect with new connection requests.
  queryTimeout	The update is effective immediately.
  statementCacheSize	The statement cache is resized upon next use.
  supplementalJDBCTrace	All connections and the connection pool are destroyed. The new setting is then used.
  syncQueryTimeoutWithTransactionTimeout	The update is effective immediately.
  transactional	The update is applied to new connections and existing connections not in use from the connection pool.
  type	All connections and the connection pool are destroyed. The new setting is then used.
  agedTimeout	The update is effective immediately.
  connectionTimeout	The update is effective immediately.
  maxIdleTime	The update is effective immediately.
  maxNumberOfMCsAllowableInThread	The update is effective immediately.
  maxPoolSize	The update is effective immediately.
  minPoolSize	The update is effective immediately.
  numConnectionsPerThreadLocal	The update is effective immediately.
  reapTime	The update is effective immediately.
  purgePolicy	The update is effective immediately.
  numConnectionsPerThreadLocal	The update is effective immediately.

• Integrating Messaging Queues

• The wasJmsServer-1.0 feature configures the Liberty server to support the JMS server run time that provides the capabilities for connections, transactions, persistence, security, and so on.
• The wasJmsClient-1.1 configures the Liberty server to support JMS client connectivity. This feature provides the resource adapter support that allows JMS clients to perform synchronous and asynchronous messaging activities.
• The Liberty profile server also supports the use of message-driven beans (MDB). The jmsMdb-3.1 feature provides support for deploying and configuring the JMS resources that are required for the MDB to run within the Liberty profile. This feature enables MDB to interact with either the embedded Liberty messaging or WebSphere MQ.
• If you want to perform a JNDI lookup for JMS resources, then you must also add the jndi-1.0 feature.
• Enable JMS in Binding Mode: 
  <wmqJmsClient nativeLibraryPath="/opt/mqm/java/lib64"/>

Implementing Security (LDAP)

• The Liberty profile provides support for securing the server runtime environment and web applications by using user registries, authentication, and authorization. For secure communication between the client and the server, you can enable SSL for the Liberty profile. A minimal or detailed configuration can be done by adding the ssl-1.0 server feature to the server configuration file.
• Implementing LDAP:

Installing Liferay on WAS 8.5

When the application server binaries have been installed, start the Profile Management Tool to create a profile appropriate for Liferay.

1. Click on Create…. Choose Application Server. Click Next.
2. Click the Advanced profile creation option and then click Next. Why Advanced? You can specify your own values for settings such as the location of the profile and names of the profile, node and host. You can assign your own ports. You can optionally choose whether to deploy the administrative console and sample application and also add web-server definitions if you wish. Web server definitions are used with IBM HTTP Server. For more information about these options, please see the WebSphere documentation.
   
   
3. Check the box Deploy the administrative console. This gives you a web-based UI for working with your application server. Skip the default applications. You’d only install these on a development machine. Click Next.
4. Set profile name and location. Ensure you specify a performance tuning setting other than Development, since you’re installing a server for production use. Please see the WebSphere documentation for further information about performance tuning settings. Click Next.
5. Choose node, server, and host names for your server. These will be specific to your environment. Click Next.
6. Administrative security in WebSphere is a way to restrict who has access to the administrative tools. You may want to have it enabled in your environment so that a user name and password are required to administer the WebSphere server. Please see WebSphere’s documentation for further information. Click Next.
7. Each profile needs a security certificate, which comes next in the wizard. If you don’t have certificates already, choose the option to generate a personal certificate and a signing certficate and click Next.
8. Once the certificates are generated, set a password for your keystore. Click Next.
9. Next, you can customize the ports this server profile uses. Be sure to choose ports that are open on your machine. When choosing ports, the wizard detects existing WebSphere installations and if it finds activity, it increments ports by one.
10. Choose whether you want this profile started when the machine starts. Click Next.
11. WebSphere ships with IBM HTTP Server, which is a rebranded version of Apache. Choose whether you want a web server definition, so that this JVM receives requests forwarded from the HTTP server. Please see WebSphere’s documentation for details on this. When finished, click Next.
12. The wizard then shows you a summary of what you selected, enabling you to keep your choices or go back and change something. When you’re satisfied, click Next.

 

WebSphere then creates your profile and finishes with a message telling you the profile was created successfully. You’re now ready to install Liferay!

Copying portal dependencies

Liferay ships with dependency .jars it needs to have on the global classpath. These should be copied to WebSphere’s global folder provided for this purpose:

[Install Location]/WebSphere/AppServer/lib/ext

If you have a JDBC database driver .jar, copy it to this location as well. Once you’ve copied the .jars, start the server profile you created for Liferay. Once it starts, you’re ready to configure your database.

Database Configuration

If you want WebSphere to manage the database connections, follow the instructions below. Note this is not necessary if you’re planning on using Liferay’s standard database configuration; in that case, skip this section. You’ll set your database information in Liferay’s setup wizard after the install.

1. Start WebSphere.
2. Open the Administrative Console and log in.
3. Click Resources → JDBC Providers.
4. Click New.
5. For name, enter the name of JDBC provider (e.g. MySQL JDBC Provider).
6. For Implementation Class Name, enter:
   

   com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource
   

7. Click Next.
8. Clear any text in classpath. You already copied the necessary .jars to a location on the server’s class path.
9. Click Next.
10. Click Finish.
11. Click Data Sources under Additional Properties.
12. Click New.
13. Enter a name: liferaydatabasesource.
14. Enter JNDI: jdbc/LiferayPool.
15. Everything else should stay at the default values. Save the data source.
16. When finished, go back into the data source and click Custom Properties and then click the Show Filter Function button. This is the second from last of the small icons under the New and Delete buttons.
17. Type user into the search terms and click Go.
    
18.  
19. Select the user property and give it the value of the user name to your database. Click OK and save to master configuration.
20. Do another filter search for the url property. Give it a value that points to your database. For example, the MySQL URL would be: jdbc:mysql://localhost/lportal?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false. Click OK and save to master configuration.
21. Do another filter search for the password property. Enter the password for the user ID you added earlier as the value for this property. Click OK and save to master configuration.
22. Go back to the data source page by clicking it in the breadcrumb trail. Click the Test Connection button. It should connect successfully.

Once you’ve set up your database, you can set up your mail session.

Mail Configuration

If you want WebSphere to manage your mail sessions, use the following procedure. If you want to use Liferay’s built-in mail sessions, you can skip this section.

1. Click Resources → Mail → Mail Providers.
2. Click the Built-In Mail Provider for your node and server.
3. Click Mail Sessions and then click the New button.
4. Give it a name of liferaymail and a JNDI name of mail/MailSession. Click OK and save to master configuration.
5. Click Security → Global Security and de-select Use Java 2 security to restrict application access to local resources if it is selected. Click Apply.

Great! Now you’re ready to deploy Liferay.

Deploy Liferay

1. Click Applications → New Application → New Enterprise Application.
2. Browse to the Liferay .war file and click Next.
3. Leave Fast Path selected and click Next. Ensure that Distribute Application has been checked, and click Next again.
4. Choose the WebSphere runtimes and/or clusters where you want Liferay deployed. Click Next.
5. Map Liferay to the root context (/) and click Next.
6. Ensure that you have made all the correct choices and click Finish. When Liferay has installed, click Save to Master Configuration.

You’ve now installed Liferay, but don’t start it yet. If you wish to use PACL, you have one more thing to configure.

Enabling Security for Portal Access Control Lists

In the administrative console, go to Security $rarr; Global Security. Check the box to enable Java 2 security, and click Apply. Save to the master configuration.

Next, you need to configure security for the Liferay profile you created. This requires editing a text file, which can be found nested several folders deep in WebSphere’s profiles directory. The exact path depends on how you’ve named your profile, but it will be something like this:

[profile_root]/config/cells/[cell_name]/nodes/[node_name]/app.policy

First, in each existing grant section, replace the content with java.security.AllPermission;. Then add the following lines to the bottom of the file:

grant codeBase "file:${was.install.root}/lib/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${was.install.root}/plugins/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${server.root}/-" {
  permission java.security.AllPermission;
};

Save the file. You should now stop the profile and restart it. Once it comes up, you’re ready to start Liferay.

Start Liferay

1. If you plan to use Liferay’s setup wizard, skip to the next step. If you wish to use WebSphere’s data source and mail session, create a file called portal-ext.properties in your Liferay Home folder. Place the following text in the file:
   

   jdbc.default.jndi.name=jdbc/LiferayPool
   mail.session.jndi.name=mail/MailSession
   setup.wizard.enabled=false
   

2. Select the Liferay application and click Start.
   
    
   
   
3. In the setup wizard, select and configure your database type. Click Finish when you’re done.
   Liferay then creates the tables it needs in the database.

Congratulations! You’ve installed Liferay on WebSphere!

WAS 8.5 - Architecture

WHAT IS WEBSPHERE:

•Family of Software products from IBM

•WebSphere Application Server, being the most popular, is an implementation of JEE (Java Platform Enterprise Edition) specification

•Extends JEE by providing several features and Services

•Is the runtime environment for your JEE Applications

•Equivalent products from other Vendors are Oracle WebLogic, JBOSS,Oracle GlassFish

WAS 8.5 Core Components:

Web Container:

•Runs JEE compliant Web Applications that contain Servlets,JSPs and static HTML pages

•Handles HTTP Sessions

•Runs Portlets (using a Portlet Container) and SIP (Session Initiation Protocol) Applications (using a SIP container)

•Provides Transport Chain that includes TCP Inbound Channel, HTTP inbound channel and Web Container Channel

•There is one Web Container per Application Server

EJB Container:

•Provides runtime for EJBs (Enterprise Java Beans)

•EJBs handle business logic and can manage data access (Entity EJBs)

•EJB Container provides threading and transaction support

•EJBs are packaged as JAR files (Java archive) and deployed as EJB modules

Clients:

Clients can be one of the following:

- Application Clients: Run in a JEE compliant Client container (installed separately from the Application Server). launchClient tool can be used to start the client

- Web Clients: Most common. This is typically the Web Browser

- Web Services client

- Admin Client: wsadmin and Admin Console Web Application

Web Services Infrastructure:

- Application Server acts as both Web Services client and Server

- Web Services are reusable Web Applications that can be described,published,discovered and invoked over Network. They implement SOA (Service Oriented Architecture.

-Under the cover, Web Service operations are executed as Servlets

Messaging Infrastructure:

Full support for JMS (Java Messaging Service)

- Message Providers: Default Messaging Provider,WebSphere MQ Provider, Generic JMS Provider

- Providers use JCA (Java Connector Architecture) to communicate with JMS destinations (Queues or Topics)

- Concept of inbuilt JMS Server has been replaced since Version 6

Service Integration Bus:

- Integrated Communication infrastructure for Messaging and SOA Applications

- Contains Messaging Engines and acts as a JMS Provider

- Contains destinations (Web Service endpoints, Messaging Queues or Topics)

- Contains a Message Store

You can make an external Web Service available at a service destination

Data Access:

•WAS uses JCA to access external Data Sources such as EIS, RDBMS

•JCA requires a Resource Adapter to be provided by the EIS Vendor

•Resource Adapter is a system level driver that enables WAS to communicate with the Data Provider

•Resource Adapters are plugged into WAS

•WAS provides pre defined RDBMS Resource Adapter

Naming and Directory:

•Each Application Server runs a JNDI Naming Service which enables Applications to register and look up resources

•WAS provides distributed Name Space for scalability

•Objects are bound in hierarchical structure in Name Space

•dumpNameSpace tool exports the Name space for troubleshooting

Transactions Infrastructure:

-Transactions are multiple operations on resources co ordinated as one unit of work

- Transaction Manager, part of WAS handles transactions. Also participates in other transaction managers on Global Transactions

- Operations are rolled back in case of failure

- Transactions can be container managed or bean managed.

- Transactions are tracked through logs 

Other Services provided by WAS:

•       Java Mail

•       Resource References: Enables to specify logical names in deployment descriptors that bind to physical resources. Logical names are then accessible through JNDI lookups

•       Scheduler: Runs tasks at specified times or intervals. Tasks can be prioritized

•       Asynchronous Beans: Enables a resource intensive task to be run as multiple tasks

•       Startup Beans: Runs your code on WAS startup or shutdown

•       Dynamic Cache: Greatly improves performance of Web Applications. Can replicate Cache among clusters

•       Object Pools: Improves performance by reducing object instantiation time

•       Activity Sessions: Enables grouping of  operations on multiple one-phase commit resources

•       Internationalization: Enables application to process information based on the geographical location of the client

Security Infrastructure:

- Solid security at various tiers in the architecture (end to end)

- Support for federated user repositories and Security domains

- Support for strong encryption (SSLv3/TLS)

- Efficient SSL Certificate Management

- Supports Java 2 Application level security

High Availability Infrastructure:

- Support for Application Server Clusters

- Data among the cluster members are replicated either using memory-to-memory replication or using Database

- HA Manager, which runs in each Application Server provides the framework for communication among cluster members. 

- Dynamic Clusters: Balance workload among cluster members based on the performance, dynamically. Can expand or contract.

Performance Infrastructure:

PMI (Performance Management Infrastructure) makes metrics available through Management Beans

Tivoli Performance Viewer can be used to view current activity and summary reports via WAS Admin Console

Tivoli Performance Viewer Advisor provides advice to tune inefficient settings

Performance and Diagnostic Advisor prints warning messages in SystemOut.log about inefficient settings

Liberty Profile:

A profile defines the runtime environment

- Is a lightweight Application Serving environment mostly used in Development environments

- Uses OSGI framework (Pluggable modules)

- Supports Web Applications, OSGI Applications and JPA

- Very fast startup

- Deploy applications using 'dropins' or by updating configuration

- Comprises of JVM, Liberty Kernel and Features (OSGi bundles)

- server.xml is the server configuration file

- Updates to configuration file is read by File Monitor Service. Features are loaded dynamically.

- Features to be loaded are specified in the server.xml 

<server>

<featureManager>

<feature>servlet-3.0</feature>

</featureManager>

</server>

- Security as per Servlet 3.0 specification

- Web Container delegates security check to WebSecurity Collaborator which talks to Authentication Service first to create 'subject' and then to authorization service to perform authorization check

- You can use the quickStartSecurity element in server.xml to quickly grant access to one user

- Auth Constraints can be defined in the deployment descriptor (web.xml)

Full Profile:

- Meant for Production environments (can be used in Development a well)

- Full blown product with all the bells and whistles

- Main components: Application Servers, Clusters, Resources, Administration

- Supports the three-tier architecture (Presentation, Business Logic, Data/ERP)

Topologies:

- Various components in any Topology:

- Application Servers

- Application Server Clusters

- Nodes

- Node Agents

- Deployment Manager

- Web Servers

- Profiles

- Cell

Various Topologies:

- Standalone

- Network Deployment - Nodes from same platform

- Network Deployment - Nodes from various platforms

- Flexible Management