Your SlideShare is downloading. ×
Field Level Security
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Field Level Security

190
views

Published on

A brief outline of how to set up field level security in Millennium fund-raising software using views created in SQL.

A brief outline of how to set up field level security in Millennium fund-raising software using views created in SQL.


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
190
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Field Level Security John M. Allen Temple University
  • 2. Introduction
    • We use Social Security Number as the key for our student and financial interfaces. Anyone who creates or maintains records needs to be able to update and insert the Social Security Numbers, yet we wanted to hide them from everyone else.
  • 3. The Solution
    • Millennium uses views to restrict access to records and tables.
    • We used the same approach to restrict access to fields.
  • 4. SSN Access Rights
    • Granted
    • Administrators
    • Bookkeepers
    • Records
    • Denied
    • Directors
    • Secretaries
  • 5. Granted Access
    • This was the easy part. Use the corebio_full view that is installed.
  • 6. Denied Access
    • Create a new view
      • Hide coressnum
    • Add the view to Millennium
    • Assign view to groups
  • 7. Create a New View
    • Every field in the table must have a field with the same name in the view
    • Field names must be unique
    • When the table structure changes, you MUST change the view
    • CREATE VIEW V_core_no_ssnum
    • AS
    • SELECT
    • corekey,
    • coreid,
    • coredoc,
    • corelook3,
    • coretext
    • FROM corebio
  • 8. Hide coressnum
    • You need a field called coressnum, but it doesn't have to contain the data from the corebio table.
    • You can put any text you want up to the length limit. It will be formatted with dashes.
    • CREATE VIEW V_core_no_ssnum
    • AS
    • SELECT
    • corekey,
    • coreid,
    • coredoc,
    • '*********' AS coressnum,
    • corelook3,
    • coretext
    • FROM corebio
  • 9. Varying the Text
    • You can even vary the text
    • Display nothing when the underlying Social Security number is NULL or blank.
    • Display '***-**-****' when the Social Security number contains data.
    • CASE Coalesce(coressnum, '')
    • WHEN '' THEN ''
    • ELSE '*********'
    • END AS coressnum
  • 10. Add the view to Millennium
    • Millennium's View Generator (V7.01) doesn't allow you to pick an existing view.
    • You have to add the view manually.
    • vlist_code is the key and must be unique.
    • INSERT INTO viewlist
    • (vlist_code, vlist_tnum, vlist_name)
    • Values('cor001', '00', 'V_core_no_ssnum')
  • 11. Assign View to Groups
    • Using the User Security tool, assign the view to the appropriate groups.
  • 12. Results—Null or Blank SSN Granted Denied
  • 13. Results—Contains Data Granted Denied
  • 14. Caveats
    • You cannot use "SELECT *" because "coressnum" would not be a unique name.
    • Every time the table structure changes, you have to alter the view
    • You can only use it with SELECT or DELETE rights. You cannot use it with INSERT or UPDATE rights.
  • 15. Conclusion
    • This allows us to :
      • Store Social Security Number for our interface
      • Maintain Social Security Number
      • Grant access to specific user groups and deny access to other user groups

×