7.7. Login with Credentials From a Flat File

Hard coding login credentials is great for a sample, but not realistic when it comes to a production deployment. In this next section you see how OpenIG can be configured to fetch the user's credentials from an external source, such as a directory or a database. For this sample, you use a flat file and the FileAttributesFilter. The key to look up the user in the flat file is hard coded, but you can understand how the key could come from something in the incoming request, such as an HTTP header, a session cookie, or even a SAML assertion.

For this sample you must modify the file attribute in the FileAttributesFilter object in config.json to reflect the location of the sample flat file. The location of the user file shipped with the samples is forgerock-sample-configs/userfile. 

$ cp $HOME/forgerock-sample-configs/WordPressLoginFile.json
 $HOME/.ForgeRock/OpenIG/config.json
$ jetty.sh restart

After restarting the container, check that you can go to http://demo.forgerock.com:8080/wordpress and be logged in as the user george without seeing the login page. To verify the login credentials are being picked up from the flat file, change george's password, restart OpenIG, and try the login page again. You should get a login failed page. If you would like to log in as a different user, look for the value attribute in config.json, replace george@seinfeld.com with kramer@seinfeld.com. Both george and kramer have accounts on the Portal so you can log in with either.

To see what is happening behind the scenes, take a look at $HOME/.ForgeRock/OpenIG/config.json. For this sample, you added one additional filter to the LoginChain and made a slight modification to the LoginRequestFilter. Take a look at the LoginChain and you can see the filters attribute now has the value of ["FileAttributesFilter","LoginRequestFilter" ]. When the LoginChain is executed the FileAttributesFilter will be called prior to the LoginRequestFilter. The FileAttributesFilter sets the results of its lookup in the Exchange accessible through the Expressions ${exchange.credentials.xxx} where xxx is the name of any one of the values from the flat file. Now take a look at the form attribute in the LoginRequestFilter. The hard coded values for log and password have been replaced with ["${exchange.credentials.username}"] and ["${exchange.credentials.password}"].