OAM Webgate - Unable to get https redirect back to load balancer

Problem Description:

Load Balancer running on 'https' i.e. SSL enabled and behind it their is a web server (OTD/OHS/APACHE...any) on which webgate is integrated. 

The web server may be SSL enabled or may be not. But this webserver expects that the load balancer will tell about its SSL  state i.e. http or https. And this info actually not provided

Lets Understand the Use Case:

Say Load Balancer listening on - https://abc.com, the web server behind it is listening on http://xyz.abc.com:7777.

Now when the request lands on the load balancer it gives this request to the proxied web server where webgate redirects this to OAM Server by making a http://<host:port>/obrareq.cgi?<querystring> request.
OAM Server authenticates/authorizes the user's request & thus makes a redirect back to the server by making a http://<host:port>/obrar.cgi?<quesrystring> request. 

Thus here lies the issue, this obrar.cgi redirect should be on https:// rather it is on http://

Ever wondered why so; the reason is that the load balancer has not sent any info about its SSL state, that whether it is running in http or https mode.
That's why webgate has not given this same info to OAM Server, thus OAM server makes the obrar.cgi redirect on http instead of https.
 

Solution:

IS_SSL header is the solution; this header need to be set in the load balancer config file;
Now if load balancer is;

• Apache/OHS than one need to set this header in the virtual host config
• RequestHeader set IS_SSL ssl

• OTD; one need to set this in the server obj conf file;
• AuthTrans fn="set-variable" set-headers="is_ssl=ssl"     ;

After this restart the load balancer  ; test the use case & the issue is resolved;

Read More:
http://fusionsecurity.blogspot.in/2011/04/ssl-offloading-and-weblogic-server.html


Enjoy :-)

Understanding SSL Handshake Mechanism Between Webgate & OAM Server

Currently Webgate supports 3 modes of communication with OAM Server:

1. Open
2. Simple
3. Cert

With the SIMPLE & CERT Mode SSL comes in picture, but why at all we require it;

• The answer lies in the question it self i.e. security. OAM combined with Webgate is a security product that provides SSO & other features thus itself requires to be secure in talking terms.

From webgate-oam perspective we will be talking about NAP over SSL.

With SSL we ensure that the data transamitted b/w 2 parties is safe & sound as;

• Both the parties knows one another, but how because they do handshake before they start communication.
•  Once they start communicating, the packets or the data been transferred b/w them is secure as it is encrypted.

The 2 SSL modes of communication described above performs handshake process before they are sending data to each other; The handshake mechanism involves following steps;

Remember: In webgate & oam conversation, it is always the webgate who sends the request & server responds to it. So the request-response model is not vice-versa in OAM/Webgate case.   

1. In SSL Handshake first it is require for both client & server to ensure that they are talking to right or intended party only. So how webgate & oam do this;

1. It is the first INITIALIZE NAP message that is sent between both the parties;
2. This init_nap msg comprises of set of messages that they both exchange. And all this is done to ensure that the listener & receiver are not evil.
3. During this exchange webgate ask the server for the communication mode, if it is not open mode than webgate starts the SSL Handshake process. Describe in step 2.

2. At this step it is required to establish a secure connection between the webgate & oam. For this webgate prepare a CLIENT HELLO Message, which contains the following;

• Supported set of Cipher-suite like
  SSL_RSA_WITH_AES_256_CBC_SHA , SSL_RSA_WITH_3DES_EDE_CBC_SHA
• Which TLS Version to be supported; TLSv1.0, TLSv1.1, TLSv1.2; 
• Now webgate with r2ps3 also supports TLSv1.2 as well.

• Random Number - this number is of 32 bytes out of which 4 bytes contains date & time and rest are randomly generated. This random number will be used to prepare the master key (which is combination of client generated random number & server generated random number). This master key will be used for encrypting the data transferred b/w client & server once handshake is done.
• Session ID: a null session id is sent. If this is not the first time, than a valid value is been sent here as a session already exist b/w them.

 Cipher-suite: it is the algo that need to be used for encrypting the data.
 TLS version - it is the SSL supported version, latest one is TLSv1.2

3. Based on the Client Hello, server responds with SERVER HELLO, & in this server responds with;

• Supported cipher suite, that will be used in b/w webgate & oam for data encryption;
• Supported TLS version;
• And server sends its own certificate to webgate; And this is required to authenticate the server. Webgate does so by checking the cert in webgate truststore i.e. cwallet.sso. If webgate is able to verify the process is proceeded to next step, else it "TLS HANDSHAKE ERROR" is thrown.
• Possible reason for this:
• There is no trusted cert loaded in cwallet.sso, so webgate is unable to verify the server cert.
• Else the server provided cert is not a valid cert, hence server need to provide a valid cert.

• Random Number: server generated number same as client did while sending hello message.
• Session ID: server sends this newly generated id, that will be used in further communications. By this server can detect whether a session exist b/w webgate & server or not.

4. Key Exchange Phase: 

•  This phase is divided into 2 messages exchanged b/w client & server:
• SERVER KEY EXCHANGE
• CLIENT KEY EXCHANGE

Server key exchange - During this message exchange you will notice that while sending server hello, you see one more message along with it i.e. SERVER KEY EXCHANGE. This message is encrypted with server's private key and client decrypts it with the server's public key received with server's certificate.

• The SERVER KEY EXCHANGE Message is not mandatory to be sent by server, as it depends on the cipher suite selected for communication.
• DH_ANNON - for this cipher it will be sent
• RSA/MD5 - it will not be sent
• After this server key exchange, server hello is done. immediately after this from webgate side it is required to send CLIENT KEY EXCHANGE message. The data in this message is encrypted with server's public key.

Client key exchange -

• The purpose of sending this message is to share the master key, which client generates using the (client random number + server random number) encrypts it using the cipher suite selected & encrypts the whole message with public key shared by server in its certificate.

Note: 

• This above key exchange step is required so that to generate a master key that will be used as symmetric key b/w server & client for further data exchange.
• And to achieve this step we use asymmetric key, as we saw client used server public key for sending CLIENT KEY EXCHANGE Message while server used its private key to send SERVER KEY EXCHANGE Message.

5. FINISHED: at this point handshake process is done & now onwards client & server exchange the messages encrypted using the master key.


Note:

• It is possible that server will respond with error, if the list of cipher suite provided by webgate is not all supported not any one of it is supported or;
• The tls version provided by webgate is not supported by server.

6. Once client & server handshake is done successfully, after remaining INIT_NAP messages are excahnged b/w webgate & oam server.

7) Once above step is done successfully, than NAP channel is initialized b/w webgate & server. Basically this NAP channel in simple terms means a socket connection b/w webgate & server is established that will transmit the data over SSL.

Note: Once a NAP channel is initialized than for the requests been sent via this channel need not to do the SSL handshake again and again. It is a one time process per connection until unless that connections is to be refreshed or gets expired.


Hence the WEBGATE-OAM SSL Handshake finishes here.....



More Info: Related to SSL (nice article)
http://robertheaton.com/2014/03/27/how-does-https-actually-work/


Enjoy :-)

Webgate Caches: Understanding the Webgate Caching

We will be discussing the following:

1. When WebGate do the caching? At what time?
2. Why it is required to cache?
3. How it uses this cache?
4. How to tune this cache?
5. Webgate Caching Demo

1) When WebGate do the caching? At what time?

      Basically Webgate caches the information: 

• At the time of Authentication & 
• Authorization.

2) Why it is required to cache?

It is important to do the caching when we don't want the OAM Server to get overloaded.
And what does this means actually?

It means that if the webgate starts sending every similar request to the server, it is actually not adding any value. We are just asking the server to do the repetitive task.

But what if we can make these request a screening at webgate. What if webgate first looks to the request if found it has already served it than webgate takes the decision. As webgate already has the answer cached. And in case webgate doesn't have any info about the user request than it will make a trip to server asking for the same & hence caching it for future use.

3) So does it means that webgate caches the request for lifetime?

No, absolutely not. It do cache, but certainly it too have a life. And its life is depends on the configuration that we do while creating the Webgate Profile.

4) What all parameters do take care of caching in OAM?

    As discussed there are 2 types of caches:

• Authentication &
• Authorization

Parameters:

1. Authentication Cache Configurable Parameters:
1. Maximum Cache Elements
2. Cache Timeout
2. Authorization User Defined Parameters:
1. maxAuthorizationResultCacheElems
2. authorizationResultCacheTimeout  

5) Now the question comes that how these caches comes into picture? As in how webgate actually uses it?

Basically when user request comes to the webgate (obviously via a server where webgate is integrated), at that time a lookup is made to the cache. Now first look up is made to authentication cache for the required parameters & than look up is made to authorization cache.

Now the interesting point here is that in case cache miss hit occurs than a NAP/OAP call is made to the server, & the response is actually cached. So that next tym if the same request comes to the webgate before cache timeout than webgate has the capability to respond & do look up.

6) Tuning the webgate cache parameters:

As discussed at point (4), the parameters defined can be configured:

• Max cache elements: If we configure this parameter as -1, than webgate will not cache the elements.
• Cache Timeout: It tells after how much time will the cache drains out. If Max Cache Elements is configured as -1, than this parameter has no significance.
• maxAuthorizationResultCacheElems - This user defined parameter will set the max number of authorization cache elements that can be cached. 
• authorizationResultCacheTimeout - this is same a cache timeout but this is specifically for authorization cache. It has no impact on authentication cache. Default value is 15 seconds.
• If authorizationResultCacheTimeout is set to 0, Authorization Cache is disabled.

Reference Docs: http://docs.oracle.com/cd/E27559_01/doc.1112/e28552/oam.htm#ASPER490



Enjoy :-)

Installing & Configuring Apache 2.2 (64bit) on Solaris x86-64 Box

This post is divided into 3 sections: Installation, Configuration & Verification. 

So let's start the process.........

Installing Apache22-64bit-

1. To install apache22, we need the source code & than need to build it. This will generate the binaries.
2. Download the source code from http://httpd.apache.org/download.cgi#apache22 to your Solaris Sparc box.
3. Now we need to 'export' some settings, i.e. per-requisites before we start the build process:
1. export LD_LIBRARY_PATH=/usr/sfw/lib/amd64:/usr/local/lib/amd64
2. export PATH=/usr/sfw/bin:/usr/ccs/bin:/usr/local/ccs/bin:/usr/local/bin:$PATH
3. # if you want it 64 bits:
1. export CFLAGS=”-m64″
4. # if you want it 32 bits:
1. # export CFLAGS=”-m32″
5. export LDFLAGS=”-L/usr/sfw/lib/amd64″
 

      4.  Unzip the downloaded apache22 source code.

      5.  Change the directory, move to the unzipped folder.

      6.  Now we need to configure the environment for building the source code, for this it is 

           required to execute the 'configure' script present in the directory.

           For eg: /scratch/ckukreja/apache22 is the directory where you have unzipped the 

                       source code

                       

                       bash$>ls -ltr configure

      7.  Execute the 'configure'  script.

           ./configure --with-included-apr --enable-so --prefix=/scratch/ckukreja/apache64

      8. Now we need to build & install the binaries. Do the following:

• make

• make install

     9. Now go to the directory where you have install apache22

• Move to bin folder and execute the 'file' command on httpd executable file.

                 bash$> cd /home/ckukreja/apache22/bin 
                 bash$> file httpd

• 'file httpd' - It's output will show you the type of file is it. Here it should show 64bit, if not than the binaries are of 32bit. Check the steps again.

    

Configure Apache22 on Solaris Sparc Box:

 As you have installed the apache22 on your Solaris Machine. Now it is required to configure it before we start the server.

1. Go to the apache22 installation directory. Move to conf folder.

         bash$> cd /home/ckukreja/apache22/conf  

     2. Open httpd.conf file to edit it. 

          bash$> vi httpd.conf

• Change the port from '80' to the one you want. Like we use '8080'.
• By default username & group are configured as 'daemon'. Change them to the one you are logged in with.
• Save the changes & close the file.

      3. Now come out of the conf folder & change your directory to bin folder.

          

         bash$>cd /scratch/ckukreja/apache64/bin

      4. Execute the apachectl executable. It will start the httpd server process.

• ./apachectl -k  start

Verify the installation & configuration steps:

Try to access the default resource present on apache22 server like index.html.

Syntax: http://<hostname>:<port>/index.html

Eg: http://hostname:8080/index.html

It will display the "It Works!!!"

So guys you are done with the Installation & Configuration of Apache22-64bit on your Solaris x86-64 Machine..........!!!!!!!!!!!!!! :-)

Enjoy :-)

Post Data Restoration and Long URL handling - OTD Webgate11g

Post Data Restoration and Long URL handling:

This feature is available in newer OTD Webgate 11g R2PS2 release dated '06/06/2014'.
While in the older OTD R2PS2 release dated '12-dec-2103', this feature is missing.

So kindly upgrade the webgate to the newer release.

To Download follow below link:
https://edelivery.oracle.com/EPD/Download/get_form?egroup_aru_number=15364661

• Open the above link & download the Part Number-  V46017-01

Note: 

1. Although it is mentioned in the download setup 'Solaris SPARC 64bit', but it is generic installer. You can use it for all platforms.
2. Currently this new OTD Webgate 11g R2PS2 is not available on OTN.

Enjoy :-)

Installing & Configuring Apache 2.4 (64bit) on Linux Machine

This post is divided into 3 sections: Installation, Configuration & Verification. 

So let's start the process.........

Installing Apache 2.4 (64bit) on Linux Machine :

1. To install apache 2.4, we need the source code & than need to build it. This will generate the binaries.
2. Download the source code from http://httpd.apache.org/download.cgi#apache24 to your Linux 64bit box.
3. Pre-requisites:
1. Download & configure Apache Portable Runtime Libraries.
2. Download, Install & Configure PCRE (Perl Compatible Regular Expressions).
4.  Download APR & APR-Util:

1. bash$> wget http://apache.tradebit.com/pub//apr/apr-1.5.1.tar.gz
   bash$> wget http://apache.tradebit.com/pub//apr/apr-util-1.5.4.tar.gz

1. Untar both the archives.

                  bash$> gtar -xvzf apr-1.5.1.tar.gz

         bash$> gtar -xvzf apr-util-1.5.4.tar.gz

      4.  Now we need to copy the files from apr & apr-util unzipped folder to the apache 

           downloaded source code folder under "srclib".

               bash$> mv apr-1.5.1/* /scratch/ckukreja/apache24/srclib/apr

               bash$> mv apr-util-1.5.4/* /scratch/ckukreja/apache24/srclib/apr-util

      5.  Download the PCRE from http://sourceforge.net/projects/pcre/files/pcre/8.36/ 

1. Install the pcre. 

          bash$> wget http://sourceforge.net/projects/pcre/files/pcre/8.36/pcre-8.36.tar.gz/download

              2. Configure it.

           bash$> gtar -xvzf pcre-8.36.tar.gz

           bash$> cd pcre-8.36

           bash$> ./configure --prefix=/scratch/ckukreja/pcre

              3. Do make & make install 

            bash$> make

            bash$> make install        

          

      6.  Now we need to configure the environment for building the apache2.4 source code, for this 

           it is required to execute the 'configure' script present in the directory.

           For eg: /scratch/ckukreja/apache24/httpd2.4.10 is the directory where you have unzipped 

                       the source code

                       

                       bash$>ls -ltr configure

      7.  Execute the 'configure'  script.

./configure --with-included-apr --enable-so --with-pcre=/scratch/ckukreja/pcre/ --prefix=/scratch/ckukreja/myapache

      8. Now we need to build & install the binaries. Do the following:

• make
• make install

     9. Now go to the directory where you have install "myapache"

• Move to bin folder and execute the 'file' command on httpd executable file.

                 bash$> cd /home/ckukreja/myapache/bin 
                 bash$> file httpd
httpd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped

• 'file httpd' - It's output will show you the type of file is it. Here it should show 64bit, if not than the binaries are of 32bit. Check the steps again.

    

Configure Apache 2.4 on Linux Box:

 As you have installed the apache 2.4 on your Linux Machine. Now it is required to configure it before we start the server.

1. Go to the "myapache" installation directory. Move to conf folder.

         bash$> cd /scratch/ckukreja/myapache/conf  

     2. Open httpd.conf file to edit it. 

          bash$> vi httpd.conf

• Change the port from '80' to the one you want. Like we use '8880'.
• By default username & group are configured as 'daemon'. Change them to the one you are logged in with.
• Save the changes & close the file.

      3. Now come out of the conf folder & change your directory to bin folder.

          

         bash$>cd /scratch/ckukreja/myapache/bin

      4. Execute the apachectl executable. It will start the httpd server process.

• ./apachectl -k  start

Verify the installation & configuration steps:

Try to access the default resource present on apache 2.4 server like index.html.

Syntax: http://<hostname>:<port>/index.html

Eg: http://slc0010:8880/index.html

It will display the "It Works!!!"

So guys you are done with the Installation & Configuration of Apache24-64bit on your Solaris Sparc Machine..........!!!!!!!!!!!!!! :-)

[Webgate]: Configure ProxyPassMatch Directive -> Required for Apache/OHS Internal Redirect Calls

Potential Problem :

When webgate identifies an error/exception (may be reported by OAM) , in this
case webgate fires an internal redirect request for "/oberr.cgi" & this
invokes an error handler.
This error handler is defined in the webgate.conf file.
<Location "/oberr.cgi">
SetHandler obwebgateerr
</Location>

But when the resource webgate is the proxy. In this case if webgate
identifies error/exception, it fires an internal redirect request. But the
error handler "obwebgateerr" is not invoked.

Potential Reason: 

When apache sends the internal redirect request in that case it sets "proxy-server" handler by itself.
Due to which the handler defined for "/oberr.cgi" is not set as already an
handler is set. This causes the request to be proxied to the backend server &
causes problem.

Solution:

It is required to set a "ProxyPassMatch" directive before the "ProxyPass"
directive in the conf file.
By setting this directive, it will not proxy for the "/oberr.cgi" request to
the backend server rather it will be served by the webgate itself.

Configuration to do:

1) Add the following directive in the conf file. Restart the Web Server:

ProxyPassMatch ^/oberr.cgi !

Syntax:
ProxyPassMatch [regex] !

The ! directive is useful in situations where you don't want to reverse-proxy.

Eg:

ProxyPassMatch ^/oberr.cgi !
ProxyPass / http://something.com/AuthenticationService/
ProxyPassReverse / http://something.com/AuthenticationService/


Enjoy :-)