• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Security Architecture For Business Applications

    July 7, 2015 Patrick Botz

    Developers can make it infinitely less complex to manage the security of a system and can significantly improve the security of any computer system by following a simple architecture in their applications. Conversely, not following a similar architecture makes it virtually impossible for any administrator to both maintain the best security possible and avoid failed and crashed applications.

    Nearly everyone in most IT shops assumes that it is the system (or security) administrator’s responsibility to manage access control for the data on the system. They also assume it is the administrator’s responsibility to fix any authority failure issues encountered by users. But when you think about this, it doesn’t really make sense for administrators to have this responsibility.

    Who knows more about which data an application uses and how and where within the application it gets used? I assert that few administrators have this kind of knowledge about the internals of any application. Thus, when encountered with an authority failure, they usually “fix” the problem by ensuring that nobody will ever encounter that same failure again. How? By making sure that everyone has the ability to create, read, change, and delete that data or file . . . by default! This, of course, makes it much easier for an attacker to access that data.

    But this can be avoided pretty easily without anyone–developers or administrators–having to manage access control for specific users while at the same time ensuring that others using the system but not running the application can’t access the application’s data. This scenario is the cheapest to manage, but it requires that applications be written with a certain set of assumptions that lead to a general security architecture.

    The assumptions developers should use when architecting any new application or program are:

    1. Administrators are only responsible for controlling which users are allowed to run the initial program of an application (or the program in the case of an application consisting of a single program).
    2. The application controls that users are allowed to perform the various business functions provided by the application.
    3. Developers implement their applications such that the applications and programs acquire the authority necessary for them to run to completion without a security failure.

    Using these assumptions when architecting and implementing an application makes it easier and faster to deploy the application from a security perspective, and makes it much easier and cheaper to manage access control and avoid authority failures over time. If an administrator can assume that the application controls that users are allowed to perform which business functions, then administrators only need to manage which users can use the initial program associated with the application. This makes it very easy to create a group for authorized application users. Add each user authorized to use that application to the group and then grant that group read or use authority to the initial program.

    Many business applications are architected with some sort of “business function and authorized users” table that the application uses to control which users are allowed to access which business functions, so that doesn’t represent any new or extra work on behalf of developers. All operating systems support mechanisms and APIs that allow programs to manipulate the authority under which they are executing at the time the program is built and even during execution. Programmers know what data objects they are accessing and what authority the program will need to be running under when it accesses those objects, so programmers can use the most appropriate API to ensure that the program has the required authority to the data at the time it accesses the data. This represents extra work for developers, but just is one time and extremely small (especially when compared to the effort required for an administrator to identify all of the data objects, determine what authority each user may need to those objects, and then attempt to manage that access control over time).

    I recently wrote an article for IBM Systems Magazine‘s AIXExtra newsletter that goes into more technical detail about the mechanisms and APIs available on AIX and IBM i–adopted authority and the user profile “swap” APIs being just two of them–developers can use to implement this security architecture. You can find it here. By exploiting these tools, developers can ensure their applications will not fail due to authority failures while administrators can focus only on controlling access for users allowed to run those applications.

    Patrick Botz is President and CTO of Botz & Associates. His expertise includes security strategy, security policy enforcement, password management, single sign-on (SSO), industry and government compliance, and biometrics. He is the architect of the SSO stat! service. Previously he worked as Lead Security Architect at IBM, and he founded the IBM Lab Services security consulting team. You can connect with Pat here.

    RELATED STORIES

    Security Policies Vs. Security Procedures

    EIM Identifier Naming

    Job User Name And Current Job User

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    Maxava

    Migrate IBM i with Confidence

    Tired of costly and risky migrations? Maxava Migrate Live minimizes disruption with seamless transitions.

    Upgrading to Power10, Power11, or cloud hosted system, Maxava has you covered!

    Book A Consultation Today

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Sponsored Links

    Fresche Legacy:  Optimize IBM i apps; Improve business processes; Deliver modernization success
    SystemObjects:  Send SMS, email & push messages from your IBM i applications!
    Four Hundred Monitor Calendar:  Latest info on national conferences, local events, & Webinars

    cozTools Brings Subscription Pricing To Software Licensing Manufacturing Automation At A ‘Crossroads’ For IBM i Shops

    Leave a Reply Cancel reply

Volume 15, Number 13 -- July 7, 2015
THIS ISSUE SPONSORED BY:

WorksRight Software
Robot
Fresche Legacy

Table of Contents

  • Looking For Stuff With iSphere
  • How To Create Updateable Views
  • Security Architecture For Business Applications

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • With Power11, Power Systems “Go To Eleven”
  • With Subscription Price, IBM i P20 And P30 Tiers Get Bigger Bundles
  • Izzi Buys CNX, Eyes Valence Port To System Z
  • IBM i Shops “Attacking” Security Concerns, Study Shows
  • IBM i PTF Guide, Volume 27, Number 26
  • Liam Allan Shares What’s Coming Next With Code For IBM i
  • From Stable To Scalable: Visual LANSA 16 Powers IBM i Growth – Launching July 8
  • VS Code Will Be The Heart Of The Modern IBM i Platform
  • The AS/400: A 37-Year-Old Dog That Loves To Learn New Tricks
  • IBM i PTF Guide, Volume 27, Number 25

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle