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

OAM 11g - Webgate NAP Tunneling

 

What is NAP Tunneling?

NAP or OAP is the protocol that is used for communication mechanism between OAM Server & Webgate.
Webgate relies on this channel for communication with the server. This channel is webgate initiated i.e. the request is made by webgate via this NAP channel & server sends the response on this NAP itself.

Now what this tunneling is meant for? It is basically a mechanism via which one can access the resource that is actually deployed at the OAM Server.

So what does that mean by accessing a resource?
Ok, take an example. I want to use an app, which is actually deployed at the OAM Server. But as we know that resources are something which are placed in some resource server.
And to use this app i can't directly hit the resource url because it is not accessible directly.

Thus with webgate r2ps2, a new feature is added i.e. NAP Tunneling. With this we can actually configured the urls that need to be tunneled, like tunneled the request only when the requested url has '/oam' in the url. So by this webgate sends this tunnel request to the server, which in turn sends the resource to the webgate & it is the responsibility of the webgate to parse the response & redirect it back to the user's browser.

How to configure/enable NAP Tunneling Feature in OAM?

1) Define a user-defined parameter in the Webgate Artifact i.e.

     TunneledUrls=<url_path> (relative path not absolute)

Like - I want to tunnel all the request that has '/oam' or '/oamfed' or '/sample'

     TunneledUrls=/oam, /oamfed, /sample

2) The Urls path that we want to tunnel, they must use public resource policy both for authentication & authorization.


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

Note: This oam-config.xml file is placed at <Middleware_Home>/user_projects/domains/<domain_name>/config/fmwconfig/oam-config.xml



The above 3 steps are required for enabling tunneling for ECC. But in case you want to enable tunneling in DCC, than you need to perform few more steps;
 
Following post shows DCC NAP TUNNELING.


Enjoy :-)

Configuring Authorization Policy Conditions/Rules in OAM 11G R2PS2

Authorization Policy : Creating Condition/Rules

Basically if you are aware of the SSO thing, than you must know that once you are authenticated than you are checked for - WHETHER YOU ARE AUTHORIZED OR NOT.
And what does that means?

It means that if you are allowed to log in to the system than it needs to be checked that whether you are authorized to access the resource or not.

Generally we have Authorization Policy for Protected & Public Resources. But we can also specify our conditions & rules for these authorization policies.

So now the question arises what's the use of these condition & rules?

• Basically we can add our condition to allow or deny the user to access the resource.
• And thus we need to add these condition to the rules for allow or denial access.

Remember - You can create your condition & rules for each of the authorization policies created for the webgate profile. Their is no constraint of only single condition or so.

In this post we will be creating a condition for IP Range, for other condition soon i will be posting a new post.

Pre-Requisites:

• Webgate Profile is created.
• Working Webgate Instance is in place i.e. webgate is integrated with your server say OHS
• And You can properly access a protected resource.

Let's see how to configure Authorization policy:

1) Log in to oamconsole: http://host:port/oamconsole

2) Go to Application Domain -> Select Webgate Profile -> Go to Authorization policy

• Note: I will be adding condition with my Protected Authorization Policy
• By default there is just one condition added 'TRUE' which is also available in the Rules.
• This is allowable condition, & TRUE in all sense.

•  Now we will be adding a new condition, and this will be for IP Range testing.

• Apply the changes
• Now once it is added, than we need to add a condition in it. In the above step we have just created a condition entry, now we will be adding a condition to it.

• Here i will be adding a IP Range - i am blocking the IP Addresses starting from 10.0.0.0 to 10.255.255.255. Any IP Address coming for authorization having IP Range b/w this mentioned series. It will be not be able to access the resource.

 

• We need to add this condition in the rules table. You can see that we have 2 types of rule:
• Allow Rule
• Deny Rule

• Here we will be adding the condition in the 'deny rule' table.

• Apply the changes & we are good to go.
• Note: 
• We need not to restart the server instance, because the changes are done at the OAM Server side and as webgate talks to OAM via OAP/NAP connection. Thus OAM Server will tell the webgate about access or denial via this NAP only. That's why no restart required.
• But remember that in case we have done changes in the webgate profile, than server restart is a must.

• Lets test this by accessing the Protected Resource URL. And my ip address starts with 10.* series. Thus i will be getting a resource denial message.
• Access the resource. http://host:port/index.html
• Provide the credentials

•  Eureka....!!!! Did you see, we get the denial message for the resource index.html.

We are done with the Authorization IP Range Condition/Rules Testing....... Soon i will be adding the use cases for other condition tests as well....


Enjoy :-)

Purpose of Max Session Time OAM

Purpose of Max Session Time field:

Max Session Time (hours)

Maximum time to keep server connections alive. The unit is based on the maxSessionTimeUnits user-defined parameter which can be 'minutes' or 'hours'. When maxSessionTimeUnits is not defined, the unit is defaulted to 'hours'.

What does this above definition means?

Basically this is the session time for the OAP/NAP connections made between Webgate & OAM Server.
This is the TTL (Time to live) of these OAP/NAP connections.

Is this field defines the time in minutes or hours?

By default it is in 'hours'. But when you create a Webgate Agent Profile there is a user defined parameter defined as 'maxSessionTimeUnits' & it has value 'minutes'.
Thus this makes the value configured in 'MAX SESSION TIME' in minutes.

• In this agent profile we have max session time configured as '2'. This is in minutes why?
• Because we have configured the user defined parameter 'maxSessionTimeUnits' & value of this parameter is 'minutes'.

But if you remove this parameter 'maxSessionTimeUnits' than MAX SESSION TIME will have 'hours' as its unit.

Note:

• User won't be challenged for credentials again because of the 'MAX Session time'. This time is not user session timeout. It is for the OAP/NAP connection timeout.

How will you test these connections?

bash$> netstat -anp | grep 5575 | grep httpd.worker

Note:

1. Port 5575 is the listening port used by the OAM Server. While creating webgate agent profile server connection port is mentioned.
2. 'httpd.worker'  is the OHS server process.
3. In this example 2 worker threads have made OAP/NAP connection with the OAM Server. 

After 2 minutes these connections are re-established, here is the proof.

Hope it clears your doubts.....!!!!!!


Reference Doc:
http://docs.oracle.com/cd/E40329_01/admin.1112/e27239/register.htm#AIAAG631


Enjoy :-)