Transcript 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
1
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
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.
4
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.
5
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.
6
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 E-FSFUNDAUTH application.
• The Institutional Trust Fund (ITF) office wanted selective
administrative users across campus to have access to E-FSFUNDAUTH 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.
8
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.
9
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.
10
ApplicationXtender
• The “easy” part.
• Naming the application: E-FS-FUNDAUTH
• Seven fields or indexes were determined:
–
–
–
–
–
–
–
Fund
Fund Type
Organization
Document Type
Fund Title
Scholarship Detail Code
Activity Date
(fund code)
(fund type)
(organization)
(fund authority drop down list)
(title of the fund)
(scholarship code)
(system generated time stamp)
• Group Names and Access privileges.
– ADMN
– PROC
– VIEW
11
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.
12
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.
13
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.
14
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.
15
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.
16
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-FSFUNDAUTH 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.
Questions?
• Leon Gipson
Enterprise Document Integration Services
[email protected]
• Kaki McLeod
Project Technical Lead
[email protected]
Thank You…
18
19
Making Custom Financial Apps Secure in BDM
CUSTOM CODE
20
Banner Interface
• Interfaces between the Banner forms and the E-FSFUNDAUTH 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
EFKCUST – Global Variables
23
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.
IF v_AppId = APPID_E_FS_FUNDAUTH THEN
BEGIN
select field3
into fz_ecu_Orgn
from otgmgr.ae_dt603
where docid = v_DocId;
EXCEPTION
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;
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;
24
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-FSFUNDAUTH 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
27
Core BANIMGR Objects for BDM
Banner INB
EXABCXT – FGITBAL (form interface)
29
Banner INB
EXABCXT – FGIBDST (form interface)
30
Making Custom Financial Apps Secure in BDM
SECURITY
31
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.
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
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.
34
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).
Three Levels of ApplicationXtender Security
• Application
• Functional/Group
• Document
36
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.
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.
38
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.
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
40
Contact Information
• Leon Gipson
Enterprise Document Integration Services
[email protected]
• Kaki McLeod
Project Technical Lead
[email protected]
41