I'm working on a project to migrate several legacy PHP and Oracle F&R applications to APEX. The biggest challenge we face right now is a matter of authentication. I understand APEX has several different methods for authentication, and this question doesn't apply to that.... what we are doing is basically a custom authentication.
Right now, we have a single password management system. A user accesses that system to manage/change their password and the system will distribute the password out to the Windows, *nix, and various applications across the business. For our existing applications we basically receive a file that contains <user>:<password_hash> and this file gets loaded into our database. The problem that I've run into is the hash we receive is based on the archaic UNIX crypt(1). With our PHP applications, this isn't a big deal since the PHP crypt function still supports it. Basically crypt(password, salt)=hash. Once a user is authenticated, everything else is handled by the applications and the security features that they use. No big deal there. According to the people that manage the password server, it can be modified to output a hash/encrypted password in any method available to OpenSSL.
What I'm trying to do, is create a PL/SQL procedure where I can pass the user password and have the procedure do the hash or encryption, match the value, and the return true/false. This will allow the package to be used by PHP, APEX, and some other stuff. Oracle does not support, in any method that I have found, the UNIX crypt(1). Looking at dbms_crypto, dbms_obfuscation_toolkit, and dbms_sqlhash it looks like the crypto package is the one to use. Here is where I've run into problems. I have been unable to generate a hash (using MAC) for, or encrypt (preferably AES256), a password that matches anything that I have output via OpenSSL. I know it's just a matter of getting the flags/parameters to line up between the two, but I'm afraid I'm out of my league here.
Has anyone successfully done anything like this before? How?
Worst case scenario, I could create a Java package in the database that shells out to the command line and runs OpenSSL and returns a hash. That is far more complicated and messy, so I'd rather avoid that route if at all possible.