I have some questions about wwv_flow.show and wwv_flow.accept securities. If we use a Single Sign On WAM product that sits in front of our APEX environment, we can use the HTTP Header authentication scheme to authenticate to the app and it works great. We've had no problems with that. This would be great for internal use, however, what if we want to expose just a single application externally to our network. We could essentially whitelist exactly what that app needs available externally and leave every other application unaccessible. We probably need to whitelist based on url these:
But I'm stumped by the rest. I know plugins that use AJAX calls hit wwv_flow.show using a POST method and pass in the variables, plugin id, application id and workspace id. However, if we were to whitelist the entire wwv_flow.show, couldn't someone actually access data in a different application than the one whitelisted based on input parameters to wwv_flow.show? I wonder if that is the same with wwv_flow.accept? I also tested using wwv_flow.show with GET variables to request a page in the app and it looks like doing so simply redirects to the f?p=<app_id> syntax. Is this always the case?
The last concern I have is wwv_flow_file_mgr.get_file which can be used to get static files in the workspace. Opening that up potentially allows all files in every app in the APEX env to be accessible. We could potentially add to the whitelist only the wwv_flow_file_mgr.get_file*p_security_group_id=<workspace_id> so at least it can only access files in the specific workspace my app is in.
Any thoughts on this? wwv_flow.show and wwv_flow.accept are not very visible and from a security standpoint seem kinda insecure.
The APEX listener can be configured to allow/deny access to applications;
You should also consider a separate DB and a runtime only APEX environment to handle high-risk security domains such as the Internet.
Thanks all! Still a little vague as far as how wwv_flow.show and accept work, however will do a workaround suggested. I think the best option based on information is to have a separate externally available db. We can use the same app servers and have a different context for the externally available database. That context along with the /i/ images directory can be whitelisted as the only paths on the server available externally. This is probably a more trusted solution than trying to mess with rules at the same apex instance database level.