Database Reference
In-Depth Information
The last thing we do is compare the cached_two_factor_cd we found to the two_factor_cd that the
user handed us. If they are equal, we return a ā€œYā€ (equivalent to a boolean true , but easier.) Otherwise,
we return the default ā€œNā€.
Notice that this is one of two places where you need to set a different cache duration, if 10 minutes
is not correct for your application. The other place is in the OracleJavaSecure.distribute2Factor()
method.
As with other procedures and functions defined in this chapter, we are not placing them in an
Oracle package. Because of the different grants (none or PUBLIC ) to these structures, we would need
different packages with only one or two procedures or functions each. In the next chapter, we will add
many similar procedures and functions and we will organize them into packages at that time.
Sending Two-Factor Pass Codes
If we have determined that we need to send two-factor codes to a user, we will call the function
f_send_2_factor on Oracle database. It is a Java stored procedure that calls Java code on the Oracle
Database to do what we cannot (easily) do in PL/SQL.
In this case, we call the distribute2Factor() method (see Listing 9-14), which generates the two-
factor code, attempts to send it to pagers and cell-phones, and stores the code in the cache table.
Listing 9-14. Send the Two-Factor Code to the User, f_send_2_factor
CREATE OR REPLACE FUNCTION appsec.f_send_2_factor( just_os_user VARCHAR2 )
RETURN VARCHAR2
AS LANGUAGE JAVA
NAME 'orajavsec.OracleJavaSecure. distribute2Factor ( java.lang.String ) return
java.lang.String';
/
Updating the Secure Application Role, HRVIEW_ROLE Procedure
Recall our secure application role, hrview_role . Without it we cannot read the data that we've deemed
sensitive in the HR schema. We originally created the procedure, p_check_hrview_access , in Chapter 2 to
provide access to the secure application role. At that time, we just checked IP Address and time of day.
In the last chapter, we updated the procedure to do SSO. If the user connection passed our SSO
requirements, we set the role; otherwise, not.
Now in this chapter, we are adding another test - has the user passed a valid two-factor
authentication code? See Listing 9-15. In order to accommodate that test, we have to modify the
procedure to take an argument: the two-factor code that the user has entered. We also return error
codes, as we've done in other procedures. In this case, we will return our distribution code (remember 1
if by pager?) in the err_txt field if there is no actual error (no err_no ).
Listing 9-15. Secure Application Role Procedure Header, p_check_hrview_access
CREATE OR REPLACE PROCEDURE appsec.p_check_hrview_access(
two_factor_cd t_two_fact_cd_cache.two_factor_cd%TYPE,
m_err_no OUT NUMBER,
m_err_txt OUT VARCHAR2 )
 
Search WWH ::




Custom Search