Session Materials - University of North Carolina


Making Custom Financial Apps Secure in BDM

Here is the latest strategic proposal on “Managing the Paperless Office”.

“The significant problems we face cannot be solved with the same level of thinking we were at when we created them.”


Albert Einstein


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.



• 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.



– refers to Banner INB security options for Financial applications. ECU only uses





• 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\


information. • Custom code was created to insert into EFKCUST, the Banner INB supplied user modifiable custom package to enforce FUND\


security. 5


• 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.


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 7

Fund Authority Project

• Security access is a major consideration for the


application. • The Institutional Trust Fund (


) office wanted selective administrative users across campus to have access to


with appropriate FUND\


security. • Custom code was copied from the BDM package


and inserted into the Banner INB supplied user modifiable custom package (


to enforce FUND\


security. • Users are only allowed to access documents they are authorized to view based on the FUND\


security assigned to them in Banner INB.



• 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.



• 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\


security within Banner INB to restrict access.

• There were no shipped applications that matched the needs of ITF.

• Solution for ITF required customization.



• The “easy” part.

• Naming the application: E-FS-FUNDAUTH • Seven fields or indexes were determined: –


– Fund Type –


(fund code) (fund type) (organization) –

Document Type

– Fund Title (fund authority drop down list) (title of the fund) – Scholarship Detail Code (scholarship code) –

Activity Date

(system generated time stamp) • Group Names and Access privileges.


Groups E-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 – E-FS-FUNDAUTH-PROC – E-FS-FUNDAUTH-VIEW Administrator Scanner/Indexer (no delete) Viewer (display only) • Privileges are assigned to each group that allow the user to preform specific activities.


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.


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.


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.



• 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





• It is a standalone BDM custom application. However, it is integrated with the standard FUND\


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\


security. • Users are only allowed to access documents they are authorized to view based on the FUND\


security assigned to them in Banner.

• Custom code was inserted in the EFKCUST Ellucian supplied user package to enforce FUND\




• Leon Gipson Enterprise Document Integration Services [email protected]

• Kaki McLeod Project Technical Lead [email protected]

Thank You…



Making 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\


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


Banner INB supplied user modifiable custom package to enforce FUND\




EFKCUST – Global Variables


EFKCUST (sample code)


- -- FILE NAME..: efkcus1.sql

-- RELEASE....: 7.1

-- OBJECT NAME: EFKCUST -- PRODUCT....: EXTSOL -- COPYRIGHT..: Copyright (c) SunGard 2006. All rights reserved.


/* 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 fz_ecu_UserName otgmgr.ae_dt603.field3%TYPE := NULL; ae_login.usrnam%TYPE

; FUNCTION f_AxSctDocAccess_t(v_AppId v_DocId NUMBER, v_UserName NUMBER, VARCHAR2, v_Locale v_SessionId VARCHAR2, 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 (


BEGIN RETURN TRUE; END; END IF; ) THEN 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 ErrMsg := AX_DENY; := 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; 24

Banner Interface

• Custom code was created in the Banner supplied EFKCUST package to allow application to use Banner FUND\


security. • Banner FUND\


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. 25

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 26

Core BANIMGR Tables for BDM


Core BANIMGR Objects for BDM

Banner INB

EXABCXT – FGITBAL (form interface)


Banner INB

EXABCXT – FGIBDST (form interface)


Making Custom Financial Apps Secure in BDM



Introduction to Security

• • • • A combination of authentication and authorization.


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.


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.

System Security Overview

• Oracle Enforced – Passwords – Defined Roles • Banner INB Enforced – HR Pay and Position Roles – Finance FUND\


Roles • BDM Enforced – – – User profiles Group profiles Document Level Security 33

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.



• 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).

Three Levels of ApplicationXtender Security

• Application • Functional/Group • Document 36


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.


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.



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.

Banner Finance


ORG Security

• When a query is performed, a user can view “metadata” for all documents that match the query criteria. • If FUND\


security is activated in Banner Finance, BDM enforces all FUND\


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 40

Contact Information

• Leon Gipson Enterprise Document Integration Services [email protected]

• Kaki McLeod Project Technical Lead [email protected]