Tuesday 20 October 2015

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

Monday 19 October 2015

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

Sunday 18 October 2015

OAM 11g - Start & Stop Servers using Node Manager and Weblogic Console

Let's start the process: follow the below steps;


We need to enroll the machine on which the domain is running via wlst; for this do the following;


1) Goto - <MiddlewareHome>/<wls server>/common/bin
2) Execute the wlst.sh  
    bash$> ./wlst.sh

3) Now one needs to connect to the domain via connect() command;
wls:/offline> connect()
Please enter your username :weblogic
Please enter your password :
Please enter your server URL [t3://localhost:7001] :
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'base_domain'.


4) After this we need to enroll the machine; using nmEnroll() command:
    This command does the following;
  • Enrolls the machine on which WLST is currently running with Node
    Manager. WLST must be connected to an Administration Server to
    run this command; WLST does not need to be connected to Node Manager.
  • This command downloads the following files from the Administration
    Server:
    o Node Manager secret file (nm_password.properties), which
     contains the encrypted username and password that is used for
     server authentication 
  •  This command also updates the nodemanager.domains file under the
    WL_HOME/common/nodemanager directory with this new domain, where
    WL_HOME refers to the top-level installation directory for
    WebLogic Server.
Note: You must run this command once per domain per machine, unless the domain shares the root directory of the Administration Server.
  • If the machine is already enrolled when you run this command, the Node
    Manager secret file (nm_password.properties) is refreshed with the
    latest information from the Administration Server.
wls:/base_domain/serverConfig> nmEnroll('/scratch/ckukreja/Oracle/Middleware/user_projects/domains/base_domain')
Enrolling this machine with the domain directory at /scratch/ckukreja/Oracle/Middleware/user_projects/domains/base_domain ...
Successfully enrolled this machine with the domain directory at /scratch/ckukreja/Oracle/Middleware/user_projects/domains/base_domain.


5) Goto weblogic console, under Machines -> check if a machine is added their if not create one;



Note: if you create a new machine than provide the node manager host & port details. Dn't use localhost as host name.

Once you update/create the machine, it contacts the node manger & creates some file in its directory path (wlserver/common/nodemanger); like
bash-3.2$ ls -ltr
total 16
-rw-r----- 1 ckukreja dba 114 Oct 18 13:15 nodemanager.domains
-rw-r----- 1 ckukreja dba   0 Oct 18 13:34 nodemanager.log.lck
-rw-r----- 1 ckukreja dba 130 Oct 18 13:34 nm_data.properties
-rw-r----- 1 ckukreja dba 900 Oct 18 13:34 nodemanager.properties
-rw-r----- 1 ckukreja dba 793 Oct 18 13:34 nodemanager.log


Initially only nodemanger.domains file is present under this directory path.


Do a bit of Configurations:

6) Configuring nodemanager.domains File

This file contains the domain name = directory path (key-val pair)
It is present under the following directory path;
<wlserver>/common/nodemanger/

7) Configure nodemanger.properties file:
Set the below 2 parameters value as mentioned below; by default they are set to false;
  • StopScriptEnabled=true
  • StartScriptEnabled=true

 

Let's start the node manager

8) Starting the node manager;


  • Goto the wlserver/server/bin directory;
  • Execute startNodeManager.sh
 bash-3.2$ ./startNodeManager.sh
.
.
.
.
<Oct 18, 2015 1:34:11 PM PDT> <Info> <Security> <BEA-090905> <Disabling CryptoJ JCE Provider self-integrity check for better startup performance. To enable this check, specify -Dweblogic.security.allowCryptoJDefaultJCEVerification=true>
<Oct 18, 2015 1:34:11 PM PDT> <Info> <Security> <BEA-090906> <Changing the default Random Number Generator in RSA CryptoJ from ECDRBG to FIPS186PRNG. To disable this change, specify -Dweblogic.security.allowCryptoJDefaultPRNG=true>
<Oct 18, 2015 1:34:11 PM PDT> <Info> <Security> <BEA-090908> <Using default WebLogic SSL Hostname Verifier implementation.>
<Oct 18, 2015 1:34:11 PM> <INFO> <Secure socket listener started on port 5556>
Oct 18, 2015 1:34:11 PM weblogic.nodemanager.server.SSLListener run
INFO: Secure socket listener started on port 5556


When we execute this command, it actually sets the default configuration which it reads from the nodemanager.properties, present at;
<wlserver path>/common/nodemanager directory path.


  Assigning Servers to the Machines


9) Now we need to add the Admin/Managed Server to the 'Machines' in Weblogic Console, so that node manager can start/stop them;

Note: This cannot be done when server is in running state so first stop the Managed Server; 


 




Now we need to add admin server as well; but we know when server is in running state we cannot do that; so this requires manual effort; let's do that:
  • Stop AdminServer 
  • Goto the domain config file; present at <domain>/config/config.xml
  • Find the element used to assign the machine for oam_server1
  • <machine>Machine-0</machine>
  • Copy that and paste that element right after the AdminServer <name/> element .
  • Also specify the AdminServer listen address to be the hostname to bind to, by default it is blank which means bind to all network interfaces. 
   

  • Start the weblogic again.
  • Now you will see the Machine-0 registered with the server.

  •  Configure the start up details for the Managed servers, that are required by the console to start & stop the servers;
  •  Configure Node Manager Username & password on console;  
Note: Keep this uid/password same as the default one, else you will be asked for 2 time credential at the time of nmConnect(). <you will see this command in next step>


Connecting to the Servers


10) Now we need to connect to Admin & Managed Server by node manager & console;
  • Execute the wlst.sh
bash$>cd <domain path>/bin
bash-3.2$ ./setDomainEnv.sh
*****************************************************
** Setting up OAM specific environment...
.
USER_MEM_ARGS=-Xms1024m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m
.
*****************************************************
** End OAM specific environment setup
*****************************************************


bash$> cd <wlserver>/common/bin
bash$>./wlst.sh
wls:/offline> help('nmConnect')

Description:
Connects WLST to Node Manager to establish a session. After connecting
to Node Manager, you can invoke any Node Manager commands via WLST.
Node Manager must be running before you can execute this command. 


wls:/offline> nmConnect(domainName='base_domain',username='weblogic',password='Welcome1')
Connecting to Node Manager ...
Successfully Connected to Node Manager.


wls:/nm/base_domain> nmStart('AdminServer')
Starting server AdminServer ...
Successfully started server AdminServer ...



Note: Once you are connected to node manager, one can view the logs at
/<domain_directory>/servers/AdminServer/logs/AdminServer.out
Here i have started AdminServer, if it is managed than in its respective directory you can view the log

Now we can start the Admin Server Console;




  • Let's start the Managed Server from the console it self;
    • Goto servers-> select Control -> Under this you will see the list of servers
    • Now select the one you want to start, like in our case we will be starting oam_server1
  
Note
Admin/Managed Servers log can be viewed at <domain_dir>/servers/<server_name>/logs/


Test a bit

 11) Now its testing time; you need to manually kill the managed servers process & need to verify whether its gets restarted or not.
 Node manager should restart it, & you can view the server logs to verify the same.



More Info:
https://docs.oracle.com/cd/E23943_01/web.1111/e13740/nodemgr_config.htm#NODEM161
Great Help:
https://blogs.oracle.com/jamesbayer/entry/weblogic_nodemanager_quick_sta



Enjoy :-)

What is Oracle Coherence

If someone is new to this Oracle Coherence term, than following things one might ask;
1) What it is?
2) Why to use it?
3) Where does it comes into picture?

It is answered very well in the below post;
http://www.mythics.com/about/blog/the-features-and-benefits-of-oracle-coherence

But yes one will see this Oracle Coherence mostly when you are installing weblogic server say 10.3.6
At that time you have the option to either use the typical installation mode or go for the custom mode.

If you select custom mode, than there you will see that Oracle Weblogic Server & Oracle Coherence are the 2 products that will get installed.
One can untick the Oracle Coherence if not required, else it will by default gets installed with the weblogic server.


Enjoy :-)

Unable to login to oam console with new identity store

Unable to login to OAM Console 11g:

Sometimes we get into a situation where we are unable to login to oamconsole when we change the identity store in OAM 11G oamonsole from EMBEDDED LDAP store to some other LDAP Store like OID, OVD or ODSEE etc...

In this case we should take caution by taking backup of oam-config.xml file; now the question comes in that why it is so important to take backup of this file?

This file contains all the configurations related info required for OAM Server and also it gets updated when update the server configuration.

For example: Default LDAP store configured in it will be like;

<Setting Name="UserIdentityStore" Type="htf:map">
     <Setting Name="SECURITY_PRINCIPAL" Type="xsd:string">cn=Admin</Setting>
    <Setting Name="GROUP_SEARCH_BASE" Type="xsd:string">ou=groups,ou=myrealm,dc=base_domain</Setting>
     <Setting Name="USER_NAME_ATTRIBUTE" Type="xsd:string">uid</Setting>
     <Setting Name="Type" Type="xsd:string">LDAP</Setting>
     <Setting Name="IsSystem" Type="xsd:boolean">true</Setting>
     <Setting Name="IsPrimary" Type="xsd:boolean">true</Sghetting>
     <Setting Name="Name" Type="xsd:string">UserIdentityStore1</Setting>
     <Setting Name="SECURITY_CREDENTIAL" Type="xsd:string">{AES}F8E3A9FAD9D662F753D842979423ED3D</Setting>
    <Setting Name="LDAP_PROVIDER" Type="xsd:string">EMBEDDED_LDAP</Setting>
    <Setting Name="USER_SEARCH_BASE" Type="xsd:string">ou=people,ou=myrealm,dc=base_domain</Setting>
    <Setting Name="ENABLE_PASSWORD_POLICY" Type="xsd:boolean">false</Setting>
    <Setting Name="LDAP_URL" Type="xsd:string">ldap://ldap-host:7001</Setting>
   <Setting Name="UserIdentityProviderType" Type="xsd:string">OracleUserRoleAPI</Setting>
   </Setting>

Similarly when you configure a new LDAP Store, a same sort of entry will be created where you will notice that the new IDENTITY Store will become the primary store and its flag will be set as true while the embedded ldap store isPrimary flag turns false;
<Setting Name="IsPrimary" Type="xsd:boolean">true</Setting>

Possible way outs:
1) Check whether the user you are logging with has admins rights; i.e. is that user added to the administrators group of the LDAP Store.
2) If the step 1 is fine than you might not have done proper configuration in weblogic console;
  • Check for the users&groups configuration, whether the added user is present under users tab or not,
  • Check for the roles&policies, i.e. under global roles->Admin-> is your admin group is present.
  • Check whether the identity store is placed at the top in the providers tab, if not you need to reorder it.
3) If step 2 is ok than check oamconsole settings, now you will ask when i am not able to login than how can i check those?
  • So the answer lies in below mentioned explanations.
Thus in case you are enable to login to the oamconsole than just replace the oam-config.xml file with the old one. Remember whenever you do changes in oam server configuration after applying the changes a backup file gets generated automatically.

So either replace the current oam-config.xml with the last saved auto backed up file or with the one you have saved as a copy.

Than restart the admin & manged server, you should be able to login with the default credentials of embedded ldap store. 



Enjoy :-)