OAAM Schema Custom Schema Example

22-4 Oracle Fusion Middleware Developers Guide for Oracle Adaptive Access Manager

22.2.1 Default Load Implementation

The default load implementation is summarized below. Figure 22–2 Default Load Implementation

22.2.2 Default Playback Implementation

The default playback implementation is summarized below. Table 22–2 Default Implementation Components Description LoadRunMode The default LoadRunMode class instantiates a DatabaseRiskAnalyzerDatasource as its data source and a AuthFingerprintLoader as its loader. DatabaseRiskAnalyzerDatasource The DatabaseRiskAnalyzerDatasource creates LoginRecords from a JDBC data source. It uses a set of configuration properties to tell it how to connect to the JDBC data source and to tell it how to build a LoginRecord from the tables and fields in the remote database. The default values for these properties map to the tables in an OAAM database. LoginRecord The login record contains all of the available fields required to call the methods for device fingerprinting on the TrackerAPIUtil class. AuthFingerprintLoader The AuthFingerprintLoader uses the data in the LoginRecord to simulate a login. This causes the system to perform device fingerprinting, run device identification time rules, and store the user node log and fingerprint data in the OAAM Offline database. Developing a Custom Loader for OAAM Offline 22-5 Figure 22–3 Default Playback Implementation

22.3 Implementation Details: Overriding the Loader or Playback Behavior

There are several cases that would require the default behavior to be overridden. You would need to override the default loading behavior to load data from a source other than a database or to load transactional data into the system. You would need to override the default playback behavior if you needed to perform a procedure other than rules processing. Table 22–3 Default Playback Implementation Components Description PlaybackRunMode The default PlaybackRunMode class instantiates a UserNodeLogsRiskAnalyzerDataSource as its data source and a RunRulesLoader as its loader. UserNodeLogsRiskAnalyzerDatasource The UserNodeLogsRiskAnalyzerDatasource creates LoginRecords from the VCRYPT_TRACKER_USERNODE_LOGS and V_FPRINTS tables in the OAAM Offline database. LoginRecord The login record contains all of the fields required to call the methods for rules processing on the TrackerAPIUtil class. RunRulesLoader The RunRulesLoader processes pre-auth rules on all LoginRecords, and processes post-auth rules on all LoginRecords with a successful authentication status. 22-6 Oracle Fusion Middleware Developers Guide for Oracle Adaptive Access Manager Figure 22–4 Overriding the Loader or Playback Behavior

22.4 Implement RiskAnalyzerDataSource

If you are loading login data from a data source other than a JDBC database, or if you are loading transactional data, then you will need to create your own subclass of RiskAnalyzerDataSource. There are three ways to do this: extending AbstractJDBCRiskAnalyzerDataSource, extending AbstractTextFile-RiskAnalyzerDataSource, or extending AbstractRiskAnalyzerDataSource.

22.4.1 Extending AbstractJDBCRiskAnalyzerDataSource

This is the appropriate choice if you are loading any sort of data through a JDBC connection. It includes default behavior for opening a JCBC connection, issuing a subclass specified SQL query to build a JDBC result set, and querying the database for a count of the total number of records. There are three abstract methods that you have to implement. ■ buildBaseSelect returns the SQL query you will use to read the data. It should not include any order by statement. The superclass will use your implementation of getOrderByField to add the order by statement. Developing a Custom Loader for OAAM Offline 22-7 ■ getOrderByField returns the name of the database field that your query should be sorted on. This is usually the date field. ■ buildNextRecord turns one or more records from the JDBC result set into your loadable data record. There are protected fields in the superclass available for your use, and you will need them when you implement the abstract methods. The most important is resultSet, which refers to your JDBC result set. When hasMoreRecords has been called and returns true, you are guaranteed that resultSet is in a valid state and pointing at the current record. In addition, when you implement buildNextRecord, you can safely assume that resultSet is in a valid state and pointing at the current record. Other fields you might need to know about are connection and controller. connection refers to your JDBC to the remote database. controller is an instance of RiskAnalyzer and contains context information about your current OAAM Offline job. Other methods that you can override if the default behavior is not what you need are buildConnection, buildSelectCountStatement, getTotalNumberToProcess, and buildSelectStatement. You would override buildConnection if you wanted to change how you instantiate the remote JDBC connection. You would override buildSelectCountStatement if you wanted to change the SQL used to count the number of records to be read in. You would override getTotalNumberToProcess if you wanted to replace the algorithm that returns the number of records to be read in. You would only do this if overriding buildSelectCountStatement was not enough to give you the behavior you need. Finally, you would override buildSelectStatement if you wanted to make changes to the SQL used to read the records from the remote databases, such as changing how the order by clause is applied.

22.4.2 Extending AbstractTextFileAnalyzerDataSource

This is the appropriate choice if you are loading data from a text file. It includes default behavior for opening a file, skipping to the first line in the file whose date is at or above the beginning of the session sets range, and stopping when you reach a line whose date is above the end of the session sets range. For this scheme to work, the input file must be sorted by date. There are two abstract methods you will have to implement. dateOfCurrentRecord tells us the date of the current record. When this method is called, you are guaranteed that the currentLine field is valid and contains the current line of your file. buildNextRecord turns one or more lines from the file into your loadable data record. If your input file contains lines that you need to ignore, you can override the lineIsBad method to examine the text passed to it, and return true if the line is one that needs to be skipped. There are protected fields in the superclass available for your use, and you will need them when you implement the abstract methods. The two most important ones are currentLine, which refers the last read in line from your file, and reader, which is a java.io.BufferedReader representing a character stream your file and is pointed at the next line after currentLine, if any. When hasMoreRecords has been