Presentation on theme: "Pennsylvania Banner Users Group 2008 Fall Conference Application Express Security BOF."— Presentation transcript:
Pennsylvania Banner Users Group 2008 Fall Conference Application Express Security BOF
General Announcements: Please turn off all cell phones/pagers If you must leave the session early, please do so as discreetly as possible Please avoid side conversations during the session Questions will be answered ….. Thank you for your cooperation
Swarthmore College Katie Bourne Frank Milewski Ed Siegle
APEX BOF Self-Service APEX authentication Securing APEX applications Workspace Management Open discussion and questions
Our Info Currently have approx 40 APEX apps in 15 of these are Self-Service Examples of what we are using APEX for Account Maintenance ITS Request Tracker Help Desk Call Center Faculty Services Finance Budget Reporting (Replaces Finance Self-Service) Freshman Portal Online directory on our college website (wouldnt even know its APEX) Various upload processes Surveys What about you?
Self-Service APEX Authentication Why use APEX to deploy Self-Service applications? 1) Much of the coding complexity is automatically taken care of 2) Able to provide functionality you currently are not using a) You can easily make a web form as robust as an Oracle Form b) You can use Banner Security – no need to reinvent the wheel 3) APEX eases/improves development, debugging,maintenance & security 4) Oracle is committed to APEX – lots of good things coming down the pike 5) Your users will notice the difference vs. flat PL/SQL pages 6) Easy to learn – was built with PL/SQL and Form developers in mind 7) You can find/get the answer to virtually any question
Self-Service APEX Authentication Banner Self-Service sets a session cookie named SESSID in the users browser. In order to validate our APEX apps we needed to capture this cookie in the database. ALTER TABLE TWGBWSES ADD (TWGBWSES_CUSTOM_SESSID VARCHAR2(50)) Modify package body TWBKWBIS custom_cookie varchar2(50) default 'no_cookie; Directly after this code: IF (NOT cp_integrated_mode) THEN OWA_COOKIE.send ('SESSID', twbkbssf.f_encode (webid || pidm)); ELSE OWA_COOKIE.send ( NAME => cp_cookie_name, VALUE => twbkbssf.f_encode (twbkauth.f_reconstructcpcookie (webid,pidm)), domain => cp_cookie_domain, PATH => cp_cookie_path); END IF; custom_cookie :=twbkbssf.f_encode (webid || pidm); UPDATE twgbwses SET twgbwses_swat_sessid = custom_cookie WHERE twgbwses_pidm = pidm; COMMIT; Every subsequent update of twgbwses where twgbwses_sessionid is set to a value set twgbwses_custom_sessid =custom_cookie. Conversely, every instance where twgbwses_sessionid is set to null set twgbwses_custom_sessid to null.
Self-Service APEX Authentication PROCEDURE pabug_demo IS pidm number(8); swat_sessid varchar2(50); BEGIN IF NOT twbkwbis.f_validuser (pidm) THEN RETURN; END IF; SELECT twgbwses_swat_sessid INTO swat_sessid FROM twgbwses WHERE twgbwses_pidm = pidm; htp.p(' window.location= "https://your schools apex url/f?p=174:901:::NO::MYSWAT_SESSID:'||swat_sessid|| '" '); END; Define in WebTailor
Self-Service APEX Authentication
Make DATABASE the current Authentication Scheme to bypass the login page
Self-Service APEX Authentication Two Authorization Schemes will be used MYSWAT ENTRY is set on the initial page entry (901). This will check the database to see if the cookie exists and verify that user has the applicable role associated with the application. If these conditions all return true the SESSID cookie passed from Self-Service is set in the APEX domain. The user is validated and allowed access into the application. MYSWAT COOKIE VERIFICATION is set on all subsequent application pages. This will check the cookie against twgbwses to validate that self-service web session has not exceeded your institutional time out value.
Self-Service APEX Authentication On your entry page (in this case 901)create an item to hold the SESSID. This item must have the exact name (in this case MYSWAT_SESSID) as the URL variable containing the Self-Service SESSID
Self-Service APEX Authentication Set the Entry Authorization Scheme and set the page Access protection to Unrestricted
Self-Service APEX Authentication Set the cookie (Before Header Process) BEGIN owa_util.mime_header('text/html', FALSE); owa_cookie.send( name=>'MYSWAT_SESSID', value=>lower(:MYSWAT_SESSID)); exception when others then null; END; Initialize PIDM and redirect BEGIN SELECT twgbwses_pidm INTO :PIDM_BEING_PROCESSED from twgbwses where twgbwses_swat_sessid = :MYSWAT_SESSID; :ENTRY_PIDM := :PIDM_BEING_PROCESSED; EXCEPTION WHEN NO_DATA_FOUND THEN :ENTRY_PIDM := null; :PIDM_BEING_PROCESSED := NULL; END; OWA_UTIL.REDIRECT_URL('f?p=&APP_ID.:1:'||:APP_SESSION);
Securing APEX Applications Use Session state protection to prevent URL tampering Always use bind variables to prevent SQL injection Control what the user enters 1) Security starts at the database 2) Use Validations for security and prettier error messages 3) Make objects conditional where applicable To prevent Cross-Site Scripting Make Standard Report Columns Display as text (escape special characters, does not save state) (This will be the default in 3.1 versions) Use Authorization Schemes
Securing APEX Applications Authorization Schemes You dont want just anyone with an account to access your app Authorization Schemes can be applied at the Application, Page, Region, Item levels and can be applied to virtually anything. Use an Authorization Scheme at the application level to restrict access to your app to a custom defined list of users select distinct 'x' from gwvsecr where form_process_name = 'FAAINVE' and user_id = :APP_USER Use Authorization Schemes on Items, Buttons and Processes to control who can update data and who has read only access select 'x' from gwvsecr where form_process_name = 'FAAINVE' and user_id = :APP_USER and role_granted = 'BAN_DEFAULT_M'
Workspace Management Self-Service requires WWW_USER to have applicable DB grants In APEX the workspace parsing schema is what needs to have the applicable DB grants APEX_PUBLIC user does not need any DB grants to Banner objects Developers do not need any DB grants to Banner objects End users do not need any DB grants to Banner This gives you a lot of flexibility in how you set up your development environment
Workspace Management Option #1 Create a master workspace, (ex: GLOBAL_APEX) along with a corresponding schema with the same name. Assign all the developers to GLOBAL_APEX. PROS All applications will be stored in one central repository and will be accessible to all developers. All database grants need only be given to the GLOBAL_APEX schema which will carry through to the workspace. Developers do not need any additional grants. CONS 1. GLOBAL_APEX, like WWW_USER, will end up having the keys to the kingdom. 2. The workspace will become large and difficult to determine what app is for what module.
Workspace Management Option #2 (If we knew then what we knew now) Create a workspace and corresponding schema for each module/area of responsibility (APEX_STUDENT, APEX_HR, APEX_FINANCE, etc). Assign developers only to the applicable workspaces matching their responsibilities. PROS 1. Applications will be located in their specific areas of responsibilities. Only the specific DB grants need to be given to the parsing schema, thus avoiding the WWW_USER scenario. 2. Since all DB grants are granted to the schema/workspace and not to the developer, developers can be reassigned areas of responsibilities simply by being removed from one workspace and added to another. 3. The auditors may actually like this.