Tried and True: Oracle EBS File Transfer Integration Part 1
One of my team’s major concentrations is the management of Oracle EBS – including the many fringe applications that allow customers to evolve and keep up with growing business needs.
We’ve been doing this for a long time and, based on our experiences, have developed a number of specialized tools that help us work more quickly and efficiently. In this post, we’re going to talk about our file transfer management solution – I’ll give you some guidance into its requirements, solution design and value proposition. For the purposes of this documentation we’ll call the manage file transfer solution SFTP under the assumption that you can create the same functionality using other protocols like HTTPS, FTPS, and AS2.
We’ve seen an influx of requests for a low-cost SFTP solution that maintains versatility and security compliance. Oracle recommends the deployment of SOA (service-oriented architecture)-based solutions to meet the integration needs of the Oracle application stack. While these solutions work great, they can often be expensive to deploy, difficult to design, and even harder to manage. In many cases a simple file transfer solution meets the basic needs, but it must be designed with the following things in mind:
- The solutions must provide a way to process incoming file transfers via a mix of automated and human-initiated processes.
- The accounts used to authenticate these transfers must be auditable and must meet both security protocols as well as market best practices.
- The account control must be granular in nature to limit access capabilities to only what is needed.
This solution typically meets customers’ basic integration needs with their Oracle applications.
Oracle Application Requirements
Let’s cover some of the technical requirements of interfacing with Oracle EBS. We’ve found that these standards will be universal for most of the Oracle application stack.
Assumptions: We deploy Oracle EBS on Oracle Linux, so we’re going to assume it’s integrating with the Linux-based Oracle platform. This will be identical if your system is deployed on Red Hat Linux.
This is probably the most complicated requirement to satisfy for a few reasons. We are attempting to integrate a single SFTP entry point with multiple application instances. Whether that’s your production, test, dev or other application suites like EPM or Agile, the same issue still exists. When using a Linux-based environment UID/GID (User ID/Group ID), mapping is key to success. This problem has been around for 30 years but is made more difficult when integrating with multiple application environments. Here are your actual requirements:
Security compliance and best practices are where most IT departments fail to meet the required standards; usually there is no malicious intent but instead operational staff attempting to “help” the end-user who is having an environment issue. Commands like chmod 777 (this changes modification rights to allow all users to read/write/execute functionality) are used to improperly resolve ownership issues. This must be stopped but can only be done by proper training, documentation and communication of standards.
There are some additional requirements that had to be taken into account. The system must be accessible for external use as it will often be used to interface with vendors in an automated fashion, and it must at least support SFTP and FTPS protocols. (Additional protocol support is better.)
With the requirements set forth above, it’s necessary to develop a system that authenticates people meeting a strict set of security guidelines but also allows for granular control over access. Below is an overview of the design we’ve chosen to meet these requirements.
Linux User-mapping Issues
This configuration works only if you spend a little time designing a user/group mapping, which is where most operations staff fail to meet the requirements. Common mistakes include:
- Linux umask configurations: The default configuration of the Linux umask per user is 022 – this basically means that the application user on the SFTP system and the Oracle EBS systems will create new folders and files that are NOT editable by users in the same group. Using group IDs to allow for multiple application users to adjust the files will require that we modify the umask of each user to 002, which will allow all accounts in the proper group to adjust files after creation.
- Infmft user creation: When the infmft user is created, the user ID, should be one that is identical throughout the Linux footprint, and its shell should be configured as ” /bin/false”
- Inf group creation: When the inf group is created systems administrators should be consulted to guaranteed that no SSH access is granted accidentally, and that its group ID is identical throughout the Linux footprint.
User password management
Password management can take hours of operations time, especially while the adoption of this shared resource grows. With this in mind, time was spent looking for an application, which allowed for the end user to manage password resets.
- Stringent password policies that meet corporate standards must be set
- Accounts should be disabled once a set number of failed passwords has been reached
User access management
When accounts are created within the SFTP application, the following layers of access are available, allowing for only the needed access to be granted on a user-by-user basis.
High Availability Configurations
- SFTP and FTPS are non-statefull transfer protocols – this means that even if the system becomes unavailable, the client side will re-try the file transfer and its termination point will not matter.
- https and as2 are more difficult and will require the application layer to have fault-tolerance to ensure that a failure will not occur when a system failure happens.
The provisioned system from above allows for integration of these protocols with any Unix-based application – and while we can’t take all security requirements into account, there should be enough flexibility within this design to meet even the most stringent security policies.
Stay tuned for part 2; in the following weeks I will post a solutions overview and architecture guide, taking an in-depth look into our shared system which has been running for almost 2 years with a 99.95% up-time, including 2 separate patching cycles. As always please feel free to share comments, thoughts and questions
« Back to blog