Thinking back on our secure application role—
hrview_role and the procedure that sets the role—what application-specific features did it implement? It tested for a number of things that are not application specific: IP address, time of day, two-factor authentication, and most important, SSO identity. However, a couple things were application-specific: the user who was seeking the role (
appusr) and the role itself (
Our goal at this juncture is to build a single secure application role procedure that will work for any application, enforcing all our connection security requirements, but granting the specific role required to the specific application user. We can build a procedure ...