Enabling IP Validation in Load Balancer Environment using ProxyTrustedList & ProxyRemoteIPHeaderVar in OAM 11g

Why we are discussing this topic?

• It is important to understand the configuration required to be done in OAM for validating the IP addresses when the application server is behind the proxies.

What difference will it make if app server is behind the proxy?

• The client ip calculation will be different if proxy is present.

How client ip is fetched in OAM/Webgate?

• remote_addr contains the client ip, in case of proxy this remote_addr will have the last proxy IP Address.

How can i than validate the IP in this scenario where proxies are used?

• For such scenario we have to configure 2 user defined parameters in Webgate Profile:

• ProxyRemoteIPHeaderVar = <by default it is set to HTTP_X_FORWADED_FOR>

• ProxyTrustedIPList = <list of comma seperated IP Addresses>

• Along with these parameter we need to set the IP Validation flag in webgate profile.

How remote_addr & x_forwaded_for header are related?

• Remote_addr: Actually it contains the IP address of the client in general. But in scenarios where proxies are involved, this remote_addr conatins the last proxy IP Address.

• HTTP_X_FORWARDED_FOR: header is a common method for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer.

Considering the scenario such as:

Client -> Proxy1 -> Proxy2 -> OHS Server(having Webgate)
 

Thus in this scenario, the headers contains following values;

• REMOTE_ADDR = Proxy2 IP

• HTTP_X_FORWARDED_FOR = Client IP, Proxy1 IP

So how the ProxyTrustedIPList is to be configured?

• This parameter should have all the proxies IP Addresses that are present in the deployment or production environment.

How HTTP_X_FORWADED_FOR & ProxyTrustedIPList co-relates?

The IP Addresses present in x_forwaded_for header are backtracked against trustediplist & when the Ip is not found in TrustedList than that is considered to be the client ip.

Consider the scenario:
Client -> Proxy1 -> Proxy2 -> OHS Server(having Webgate)

Headers:

• HTTP_X_FORWADED_FOR = ClientIp, Proxy1

• REMOTE_ADDR = Proxy2

Configuration:

• ProxyTrustedIPList = Proxy1, Proxy2

 

Enjoy :-)

OAM Webgate DCC NAP TUNNELING

Enabling DCC NAP TUNNELING:

NOTE: DCC as a Resource Webgate doesn't support NAP Tunneling, which means if you want to access a resource protected by DCC itself than in that case NAP TUNNELING is not supported.
You have to have a separate resource webgate which is DCC Protected & in DCC webgate you have enabled nap tunneling.

• Supported Case:

• Non-Supported Case:

Prerequisites:

• 2 profiles has already been created i.e.
• One for resource webgate.
• Other one for DCC Webgate
• If possible do test whether you are able to access a resource protected by DCC. So that we are sure that things are working in DCC Mode & we just need to test NAP Tunneling via DCC.

Note: I will be demonstrating Login Page NAP Tunneling Via DCC Webgate.

Let's Start:

1) Make sure the parameter "DirectAuthenticationServiceDescriptor" is set to true in oam-config.xml file.

2) Create an authentication scheme, that will be used to protect the resources on Resource Webgate.

3) Now update the authentication scheme, in the protected resource policy of the resource webgate profile;

Note: This policy scheme needs to be updated for RESOURCE WEBGATE PROFILE not for DCC WEBGATE PROFILE


4) Once done, now we need to update DCC WEBGATE PROFILE:

• Update the user defined parameter; add the tunneled url information, i.e. which url you want to tunnel.

Note: here i have tunneled '/oam' url, thus any request landing on dcc webgate having /oam in the url will be tunneled to oam server.

• Now we need to create a new resource in dcc webgate profile; goto the launch pad -> Application domain -> <DCC WEBGATE PROFILE> -> Resources -> Create new resource.
• This new resource name should be the one that you have added in the tunneled url above.
• And this resource should use PUBLIC RESOURCE POLICY.
• Keep one thing in mind, if you have tunneled 2 urls, like /oam,/oamfed than 2 resources should be created.

Note:

• In the above step you can see we have added a resource '/oam/**' as a public resource which means, any url which has /oam, will be treated as public resource by DCC WEBGATE PROFILE.
• Also, you can see i have added 3 more resources i.e. for the DCC WEBGATE itself. It has nothing to do with the NAP TUNNELING. You can skip this as well.

Demo:
1) Say you access a resource /index.html, that is protected by DCC & in DCC NAP TUNNELING is enabled;
2) DCC Webgate need to show the OAM server login page rather than its own, thats what we intent to see in this demo.

resource webgate: abc.com
dcc webgate - xyx.com

So we are able to tunnel the login page, & thus DCC shows the oam server login page instead of the one that is present on DCC itself.
But it doesn't mean that credential collection will be done by OAM SERVER.... no no no....
It is just that DCC has shown the login page of oam server that it has received via NAP tunnel. Rest all functionality remains the same.


Enjoy :-)

OAM R2PS3 - why there is need for 2 cwallet.sso files in webgate profile

Did you ever wondered that why there are 2 cwallet.sso files generated for your webgate profile in OAM R2PS3?

Let's take a look of the directory structure of the webgate profile when you create it;

• Here you see a cwallet.sso file & a wallet folder. This wallet folder was never there in previous releases, but from R2PS3 onwards you will see this folder as well..

Let' see what this folder contains;

• On expanding this wallet folder you see one more cwallet.sso file present int it.

bash-3.2$ ls -ltr
total 12
drwxr----- 2 ckukreja dba 4096 Oct 20 10:42 wallet
-rw-r----- 1 ckukreja dba 2796 Oct 20 10:42 ObAccessClient.xml
-rw-rw-rw- 1 ckukreja dba    0 Oct 20 10:42 cwallet.sso.lck
-rw------- 1 ckukreja dba  433 Oct 20 10:42 cwallet.sso   ----> this R2PS2 compatible wallet
bash-3.2$ cd wallet/
bash-3.2$ ls -ltr
total 4
-rw-rw-rw- 1 ckukreja dba   0 Oct 20 10:42 cwallet.sso.lck
-rw------- 1 ckukreja dba 401 Oct 20 10:42 cwallet.sso  -------> this R2PS3 compatible wallet

So the answer for these 2 cwallet.sso files is as follows:

• The cwallet.sso file present in wallet folder is R2PS3 compatible wallet, which means if you try to use this cwallet.sso file with R2PS2 webgate, it won't work. You will get FATAL error that "unable to read agent key". And thus webgate is not initialized successfully. 
• This cwallet.sso is used by R2PS3 webgate, but there is a catch here. Consider you don't copy the wallet folder to webgate instance directory in that case R2PS3 webgate is intelligent enough to understand the R2PS2 cwallet.sso.
• So this means that R2PS3 webgate can work with R2PS2 cwallet.sso as well as R2PS3 cwallet.sso.
• While the other cwallet.sso present outside is R2PS2 compatible wallet file i.e. when you try to use R2PS3 OAM Server with R2PS2 WebServer having R2PS2 Webgate. This cwallet.sso will be used by the webgate to read the agent key.
• This means that if this cwallet.sso is not present in that case R2PS2 webgate will be unable to initialize as it won't be able to read the agent key i.e. is present in cwallet.sso.
• Hence to make R2PS2 webgate work with R2PS3 OAM server it is mandatory to use the cwallet.sso file presnet outside the wallet folder.

  

There is one more change done in the cwallet.sso files for R2PS2 & R2PS3 created by R2PS3 OAM Server i.e.

• If you open the cwallet.sso of R2PS2 or R2PS3 it only contains shared secret key, there are no default certs present.

  

      Remember: to set the JAVA_HOME before you use the orapki command.

• While the cwallet.sso created by R2PS2 OAM Server used to contain default certs and the shared key.

Note: 

• To open R2PS3 cwallet.sso present in wallet folder you need the latest orapki executable which comes with R2PS3 OAM server, this same orapki can open the R2PS2 cwallet.sso as well. 
• But the orapki that comes with R2PS2 OAM Server will be unable to open R2PS3 wallet & will ask for login password in-spite of the fact that the cwallet.sso is auto login wallet.

Enjoy :-)

User Defined Parameters in OAM 11G

The complete list of user defined parameters is described in the following oracle doc:

R2PS2:

http://docs.oracle.com/cd/E40329_01/admin.1112/e27239/register.htm#AIAAG5856

R2PS1:

http://docs.oracle.com/cd/E28271_01/doc.1111/e15478/shared.htm

OAM R2PS3 - no need to add cacert.pem or aaa_chain.pem in cwallet.sso anymore

With the recent release of Webgate R2PS3, now a new feature is added which saves manual intervention of adding cert in cwallet.sso for SIMPLE & CERT Mode.

Previously for SIMPLE/CERT Mode one needs to add the cacert.pem or aaa_chain.pem cert in the wallet. If not than handshake between webgate & oam is not done successfully.

But now webgate itself picks the cert from the desired location like;

• for simple mode -> cacert.pem is added in wallet which is placed at <webgate_install_dir>/tools/openssl/simpleCA directory location.
• for CERT Mode -> aaa_chain.pem needs to be added in wallet which is to be placed in webgate instance directory location.

So now when we start the webserver in which webgate is integrated, during SSL Handshake first time no cert is found in cwallet.sso hence "TLS Handshake failure" message is gets logged. After detecting this error webgate itself adds the cert in cwallet.sso & retry the handshake once again.

Hence this time all goes good & NAP Channel is initialized in secure mode.


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 :-)

Configuring self signed SSL Certificates for OHS 11.1.1.7 or 11.1.1.9

Recently i came across a very good article by the a-team regarding configuring the SSL certificates signed by CA authority with the OHS.

Currently if we access a secured SSL port of OHS, our browser shows us a warning, and ask us whether to trust the certificate or not. Basically this certificate is the default one that comes with the OHS.
But in actual scenario's we need configure the SSL certificate of our organization that will be signed by CA authority like VeriSign.

It is also possible for us to generate the SSL Certificate & sign it by root CA i.e. basically our own CA, because for testing purpose we are not going to sign it by external CA.

So the article shared by a-team describes the steps to be followed to achieve the purpose.

http://www.ateam-oracle.com/setting-up-https-on-ohs-for-fusion-apps/



Enjoy :-)