Upload
robyn-floyd
View
217
Download
1
Embed Size (px)
Citation preview
1
Making Custom Financial Apps Secure in BDM
“The significant problems we face cannot be solved with the same level of thinking we were at when we created them.”
- Albert Einstein
Here is the latest strategic proposal on “Managing the Paperless Office”.
Making Custom Financial Apps Secure in BDM
Paul Leon Gipson
East Carolina University
Session Etiquette
• Please turn off all cell phones.
• Please keep side conversations to a minimum.
• If you must leave during the presentation, please do so as quietly as possible.
3
4
Housekeeping
• Terminology– API – Application Programming Interface– Banner INB – Internet Native Banner.– BDM – Banner Document Management.– AX – ApplicationXtender aka Xtender, a document imaging
application.– ITF – Institutional Trust Fund.– E-FS-FUNDAUTH – custom AX application created to meet the
needs of our ITF Department.– FUND/ORG – refers to Banner INB security options for Financial
applications. ECU only uses ORG security.
5
Introduction
• This presentation will discuss the process to create a secure custom Financial Services ITF application (Fund Authority) with full integration into Banner INB.
• Interface between Banner INB and BDM was modified to only allow users that were authorized to view specific FUND\ORG information.
• Custom code was created to insert into EFKCUST, the Banner INB supplied user modifiable custom package to enforce FUND\ORG security.
6
Background
• Current documents were being kept in notebooks on bookshelves in the ITF office.
• Need for a safe and secure storage location for fund authority documents.
• Documents date back to the 1970’s.• Fund Authority Numbers reused and forms filed in front
of the older set.• ITF physically controlled who had access to documents.• ITF wanted to improve processes with technology.
7
Background Information
• Banner and BDM Security• Custom versus Shipped• What documents are being stored and retrieved• Adding a non-vanilla API in EFKCUST • BDM-Banner INB Integration
8
Fund Authority Project
• Security access is a major consideration for the E-FS-
FUNDAUTH application.
• The Institutional Trust Fund (ITF) office wanted selective
administrative users across campus to have access to E-FS-
FUNDAUTH with appropriate FUND\ORG security. • Custom code was copied from the BDM package EFKIMG
and inserted into the Banner INB supplied user modifiable
custom package (EFKCUST) to enforce FUND\ORG security. • Users are only allowed to access documents they are
authorized to view based on the FUND\ORG security
assigned to them in Banner INB.
9
Considerations
• Secure storage and secure access to documents.• ITF retains control of documents.• Document imaging and management.• Identification of document types based upon forms.• Disposition of Active and Inactive Fund Authorities.• Keeping reused Fund Codes together.• Access through Banner INB.• Customization of Banner INB vanilla code.• Quality of older documents – highlighting, color of paper.
10
Customization
• Document Imaging is accessible through BDM – Ellucian supplied integration application that works with ApplicationXtender (AX).
• Ellucian ships sixteen AX applications that are not customizable.
• Finance applications use FUND\ORG security within Banner INB to restrict access.
• There were no shipped applications that matched the needs of ITF.
• Solution for ITF required customization.
11
ApplicationXtender
• The “easy” part.• Naming the application: E-FS-FUNDAUTH• Seven fields or indexes were determined:
– Fund (fund code)– Fund Type (fund type)– Organization (organization)– Document Type (fund authority drop down list)– Fund Title (title of the fund)– Scholarship Detail Code (scholarship code)– Activity Date (system generated time stamp)
• Group Names and Access privileges.– ADMN– PROC– VIEW
12
GroupsE-FS-FUNDAUTH application
• Specific groups are granted access to an application. • Users gain access to an application by being assigned to
a group. • Three groups:
– E-FS-FUNDAUTH-ADMN Administrator – E-FS-FUNDAUTH-PROC Scanner/Indexer (no
delete)– E-FS-FUNDAUTH-VIEW Viewer (display only)
• Privileges are assigned to each group that allow the user to preform specific activities.
13
Banner INB
• The “hard” part.• Ellucian ships a customizable BDM package –
EFKCUST.• Requires programmer skills and access to Oracle
Production tables.• Allows customized applications like E-FS-FUNDAUTH to
follow the same security criteria as shipped applications – in this case, B-F-DOCS.
14
I Want Access
• Must have an ECU PirateID.• Required to access and complete the Banner Security
Request Form through our Onestop portal application.• Request is routed to supervisor for initial approval.• Next, it goes to the Functional Area Approver or
Application Owner for approval.• Next, the AX Administrator reviews and if approved the
requestor is entered into the appropriate group for the application in Xtender.
• Final route is to IT Security for class assignment in Banner INB.
• But, there is more before you can get to the documents.
15
Yet Another Security Process
• You cannot log in until you synchronize your Banner INB password with ApplicationXtender.
• First, you must log into Banner INB.• Reply YES to all of the java prompts.• Change your Banner INB password if prompted.• Finally, click on the “magnifying glass” icon at the top of the
Banner INB GUAGMNU page.
• Now you will be able to log directly into ApplicationXtender rather than logging into Banner INB first.
16
Summary
• Custom BDM application created to securely store ITF documents in an organized retrievable format.
• Documents accessible through Banner INB and ApplicationXtender.
• Office space is less cluttered.• ITF still controls who has access to documents.• ITF is now able to “control” documents through BDM and
ORG security.
Summary
• It is a standalone BDM custom application. However, it is integrated with the standard FUND\ORG security in Banner.
• The Banner BDM interface can later be customized so the user may go directly from selected Banner forms to the E-FS-FUNDAUTH BDM application if desired by the user.
• Selected administrative users across campus will have access to E-FS-FUNDAUTH with appropriate FUND\ORG security.
• Users are only allowed to access documents they are authorized to view based on the FUND\ORG security assigned to them in Banner.
• Custom code was inserted in the EFKCUST Ellucian supplied user package to enforce FUND\ORG security.
18
Questions?• Leon Gipson
Enterprise Document Integration Services
[email protected]• Kaki McLeod
Project Technical Lead
Thank You…
19
20
CUSTOM CODEMaking Custom Financial Apps Secure in BDM
Banner Interface
• Interfaces between the Banner forms and the E-FS-FUNDAUTH application.
• This application uses the Banner FUND\ORG security. • Custom code is in the EFKCUST package supplied by
Banner for customer use. • Banner FUND\ORG security is invoked in the EFKCUST
package under the BANINST1 schema.• Custom code was created from EFKIMG and then
inserted in the EFKCUST Banner INB supplied user modifiable custom package to enforce FUND\ORG security.
22
23
EFKCUST – Global Variables
24
EFKCUST (sample code)CREATE OR REPLACE PACKAGE BODY BANINST1.EFKCUST AS---- FILE NAME..: efkcus1.sql-- RELEASE....: 7.1-- OBJECT NAME: EFKCUST-- PRODUCT....: EXTSOL-- COPYRIGHT..: Copyright (c) SunGard 2006. All rights reserved.
APPID_E_FS_FUNDAUTH CONSTANT INTEGER DEFAULT 603;
/* Constant variables definition */ AX_ALLOW CONSTANT INTEGER DEFAULT 0; AX_DENY CONSTANT INTEGER DEFAULT 1;
/* Cursors and modular-level variables */ ErrMsg VARCHAR2(1000) := NULL;
fz_ecu_Orgn otgmgr.ae_dt603.field3%TYPE := NULL; fz_ecu_UserName ae_login.usrnam%TYPE;
FUNCTION f_AxSctDocAccess_t(v_AppId NUMBER, v_DocId NUMBER, v_UserName VARCHAR2, v_Locale VARCHAR2, v_SessionId VARCHAR2, v_Success IN OUT NUMBER, v_InfoMsg IN OUT VARCHAR2, v_InfoMsgStyle IN OUT NUMBER) RETURN BOOLEAN IS BEGIN
fz_ecu_UserName := UPPER(REPLACE(v_UserName,'NULL\','')); v_Success := AX_ALLOW; v_InfoMsgStyle := 3; -- Informational message
IF v_AppId NOT IN ( APPID_E_FS_FUNDAUTH ) THEN BEGIN RETURN TRUE; END; END IF;
IF v_AppId = APPID_E_FS_FUNDAUTH THEN BEGIN select field3 into fz_ecu_Orgn from otgmgr.ae_dt603 where docid = v_DocId;
EXCEPTION WHEN OTHERS THEN v_Success := AX_DENY; RETURN FALSE; END; END IF;
IF fokutil.f_fund_org_security_fnc( 'E', null, -- Defaults to all funds fz_ecu_Orgn, null, -- Defaults to sysdate null, -- Defaults to Query fz_ecu_UserName ) = 'N' THEN BEGIN v_Success := AX_DENY; ErrMsg := G$_NLS.Get( 'EFKIMA1-0001', 'SQL', '**** You do not have proper Fund/Org security to access this document ****' ); v_InfoMsg := ErrMsg; -- Store the problem in the error / results table: eokrslt.p_insert_exrrslt('PACKAGE', 'EFKCUST.p_axsctdocaccess', 'AUTHORIZATION', SUBSTR(ErrMsg, 1, 200), fz_ecu_UserName, SYSDATE);
RETURN FALSE; END; END IF; RETURN TRUE; END;
25
Banner Interface
• Custom code was created in the Banner supplied EFKCUST package to allow application to use Banner FUND\ORG security.
• Banner FUND\ORG security is invoked in the EFKCUST package under the BANINST1 schema.
• Interfaces between the Banner forms and the E-FS-FUNDAUTH application can be created.
26
Banner INB
Fund Authority Security API
• BANINST1 Schema• EFKCUST – package supplied by Ellucian for Customer
Customization• Functions and Procedures
– f_AxSctDocAccess_t
• APPID_E_FS_FUNDAUTH
27
Core BANIMGR Tables for BDM
Core BANIMGR Objects for BDM
29
Banner INB
EXABCXT – FGITBAL (form interface)
30
Banner INB
EXABCXT – FGIBDST (form interface)
31
SECURITYMaking Custom Financial Apps Secure in BDM
Introduction to Security
• A combination of authentication and authorization.
• Authentication requires all users to enter a valid user name and password to
access BDM to ensure that each user is who he or she claims to be. (Oracle
enforced)
– Authentication credentials are exclusive to each data source.
• Logins for TEST and PROD are different.
– BDM requires password synchronization with Banner INB.
• Authorization is the granting of specific access privileges according to the
user name.
– Security profiles contain information pertaining to a user’s specific privileges within the
BDM content management system.
– Security profiles are configured following standard user and group security rules.
• Three levels of security (application, functional/group, and document) to
prevent unauthorized users from gaining access to sensitive information
stored within BDM.
33
System Security Overview
• Oracle Enforced– Passwords – Defined Roles
• Banner INB Enforced– HR Pay and Position Roles– Finance FUND\ORG Roles
• BDM Enforced– User profiles – Group profiles– Document Level Security
34
Security on Four Levels
• The system provides: – Oracle security – provides database security features and
auditing capabilities. – Banner security – provides form, report, and process level
security across Banner applications. – Finance system security –establishes security by user IDs,
rule groups and rule classes, forms and process for rule groups, fund and fund types, and organizations.
– BDM security – enables security though application, group and document level privileges.
Security
• Access to personal information in BDM is restricted through application level, group level and document level security.
• Each user has a defined functional role (group) within an application.
• Within the application an individual or group can be further restricted in their access by document type.
• Additional security comes through Banner INB for Finance via security classes.
• When users are removed from Banner INB they are also removed from BDM (manual process).
36
Three Levels of ApplicationXtender Security
• Application • Functional/Group• Document
BDM
Application Level Security
• Application level security grants users/groups access to applications.
• Profiles can be created to grant access to all applications or to specific applications.
• When a profile is application-specific, the privilege settings of one application are not carried over to a new application when it is created. – Example: If a group of users has an application-specific profile
for a certain application, and no global profile, then members of the group will not be able to access a new application when it is created.
38
BDM
Functional/Group Security
• One group may have index privileges in the FINANCE application, for instance, but only display privileges in the PAYROLL application.
• When a profile is application-specific the privilege settings are not carried over to a new application when it is created.
• If a group of users has an application-specific profile for a certain application, and no global profile, then members of the group will not be able to access a new application when it is created.
BDM
Document Level Security
• Document level security is used to enable or disable access to specific information within an BDM application.
• Protects specified documents in an application from access by unauthorized users.
• Or, can allow users access to only particular documents in an application.
• That is, document level security can be either accessible (allow) or inaccessible (deny).
• Can restrict based upon keywords (by user name or workstation) or by index field criteria.
• Document Type is the most common field used for DLS.• Not implemented in E-FS-FUNDAUTH.
40
Banner Finance
FUND/ORG Security
• When a query is performed, a user can view “metadata” for all documents that match the query criteria.
• If FUND\ORG security is activated in Banner Finance, BDM enforces all FUND\ORG security strategies that are defined in Banner.
• In this situation, a user can access a Banner Finance document only if he/she has the appropriate access rights.
• If the user fails the security tests, a “fund organization” security message is displayed in ApplicationXtender Document Manager or Xtender Web Access.
• This now applies to the custom application: E-FS-FUNDAUTH
41
Contact Information
• Leon Gipson Enterprise Document Integration Services [email protected]
• Kaki McLeod Project Technical [email protected]