Lets start with a little overview of the OAAM Architecture. The software is made up of two components:
- OASA – Oracle Adaptive Strong Authenticator
- OARM – Oracle Adaptive Risk Manager
The OASA component is provides numerous means to protect from phishing, pharming, trojan, and keylogging attacks. The different authentication options are interesting and well designed to protect an organization. The OARM component tracks user usage patterns to help prevent fraud detection. It uses such things as your user name, known computer attributes, known locations you access the system from, etc. to build a comprehensive profile about you. It also allows organizations to monitor in real time what users are accessing their systems and either automatically or manually (through an operator) force a user to perform a secondary level of authentication to prove they are the actual person at the computer. The Risk Manager creates a virtual fingerprint of your users through a combination of IP addresses, geo location, city, state, country information, connection type, connection speed, routes, isp flag, ASN, carrier, top level domain, registering organization, hostnames, routers, and how quickly you navigate pages. You never realized there was so much stuff people could track you by and you don’t really have an option of controlling it.
OAAM is deployed just like any standard J2EE application. It’s packaged as a set of jar files, some static images, and database scripts with property files to link it all together. Nothing here that I haven’t done a million times before. So lets start at the bottom and work our way up. I started with a standard Oracle 10.1.4 OID /SSO deployment and 10.1.3 OC4J/OHS install. So onto the database.
The database much be of version 9.2.0.4 or higher, honestly, if you’re deploying a new software architecture and still using 9.2.0.4 database to store your data give me a call and I’d love to discuss the business reasons for sticking with that. Lucky for me, the basic OID install uses a 10.1.0.5 database so I’m ready.
The first step is to validate the database parameters so that they match the minimum requirements for the install. We first must get access to the pile so we can change it into an spfile to open the database. So first we log into the database as sys.
After we log into the database, create a pfile from the database parameters, after the pfile is created you need to then edit the init<sid>.ora file you’ve created. To do this we set our ORACLE_HOME, ORACLE_SID, and PATH.
$> export ORACLE_HOME=/software/oracle/oaam_oid_1014
$> export ORACLE_SID=oaamoid
$> export PATH=$ORACLE_HOME/bin:$PATH
$> sqlplus /nolog
sql> connect /as sysdba
sql> create pfile = ‘initoaamoid.ora’ from spfile;
sql> quit;
$> vi $ORACLE_HOME/dbs/initoaamoid.ora
Within the pfile you need to set the minimums for the following settings:
*.db_writer_processes=4
*.fast_start_mttr_target=300
*._hash_join_enabled=TRUE
*.open_cursors=2000
*.pga_aggregate_target=512M
*.processes=500
*.query_rewrite_enabled=’FALSE’
*.sessions=500
*.shared_pool_size=500M
*.star_transformation_enabled=’FALSE’
*.timed_statistics=TRUE
*.undo_management=’AUTO’
*.undo_retention=’3600′
*.session_cached_cursors=500
*.commit_write=’BATCH,NOWAIT’
One thing to note, commit_write is not a 10g R1 parameter, it was introduced in 10gR2, so the instructions are a bit off, but not hard to get around, just don’t put it in the end of your pfile. Write out your pfile to the OS and finally we log back into the database, create the spfile from the pfile and start the database.
$> sqlplus /nolog
sql> connect /as sysdba
sql> create spfile = ’spfileoaamoid.ora’ from pfile;
sql> startup
sql> quit
Once the database is started we then have to load all of the data that allows the components to run. To do this we log back into the database and then execute the db_setup.sql script.
$> sqlplus system/<oraclevms>
sql> @/software/source/oracle/AdaptiveAccessManager10g/oracle_fa_database/db_setup.sql;
The script asks you to enter the location where you want to put the two new tablespaces the application creates, the name of the user you want to use, and the password, then halfway through the script it asks you the name of your temp tablespace (TEMP). Once the script started executing it creates the actual tablespaces, database user, database objects, loads the initial data, and then the location database (for the ip address locations).
Alright, that was stupid simple, the database is done, stay tuned for the software deployment. I apologize for no pictures on this one, I was using a different machine than the one I normally do and my copy of SnagIt was setup to only snap one screen shot and overwrite it each time. I promise the rest of the install log will have pictures to go along. Thats all for now, check back in a few hours (maybe 24) for the java application deployment instructions.
