“When is it appropriate to use an ‘application ID’ to authenticate with the back end application or database engine?” This is a question that I periodically receive from application designers and developers. Working in financial services, the answer continues to seem obvious to me…Make use of the authenticated user’s identity end-to-end — using alternatives only where there are material financial disincentives and where those alternatives comply with all applicable laws, regulations, and contracts.
When the other variables remain the same, increasing complexity of an application, system, or process tends to introduce more defects. And a certain portion of those defects will result in risk-enhancing vulnerabilities. As a result, simplicity still ranks high on my list of architectural “ilities.”
In the financial services industry, “compliance” on many fronts requires that individuals are held accountable for their behaviors. In general, application infrastructure is responsible for generating the trail of individual’s activities. Applications must do so in a manner that delivers that trail at a fairly high level of integrity. This is sometimes called an “audit trail,” but I believe it is often more accurately a “compliance trail.”
Surely, there are other related tasks such as real-time or periodic monitoring for indicators or evidence of unauthorized activity or outright attack, and generating alerts as is risk-appropriate. Sometimes the “compliance” and “monitoring” activities can be served via one code-base. But in other instances, the tasks are so different that it would be unbusinesslike to attempt their combination.
The implementation details will vary depending on the nature of the business process, the type of business activity, along with the applicable laws, regulations, policies, standards, and customer expectations. The rigor used to secure a system that dispenses public documentation — maintaining authentication and access information only for demographic and marketing purposes — will generally be radically different from one that enables large-scale wire-transfers — where movement of sums greater than $100M US. would be routine.
So, I add this up and what results is my “rule of thumb” for authenticating with back end or database systems:“Make use of the authenticated user’s identity end-to-end — using alternatives only where there are material financial disincentives and where those alternatives comply with all applicable laws, regulations, and contracts.”
It is often more difficult to maintain the integrity of the activity trail when alternative IDs are employed. And that translates into increased complexity, defects, and vulnerabilities. In the long run, I believe that this too-often results in unplanned and unproductive expenses.
Sure, there are situations where this rule may not apply. Consider application interactions that are part of a periodic “batch.” There is no “authenticated user.” This situation will appear in a number of “automation” systems and “workflow.” Sometimes this requires using an “application ID,” or a credential used by one application to authenticate to another, or to a database engine. Permissions can be checked for that identity and access to resources as permitted. This is often, although not always, a relatively straight-forward effort.
There are also situations where an application requires elevated rights at a certain stage of execution. Again, it may be useful to employ an “application ID” here as well. But use caution, ineffective application architecture or design may be the root cause here. There may be situations where another application design may not require the elevated rights.
When application architects or designer want to employ an alternative identity, have a discussion about the details of their problem-set. It might be more appropriate to re-design the application.