Page 211 - DCAP309_INFORMATION_SECURITY_AND_PRIVACY

Unit 14: Web Services and Privacy

Parties within the similar trust zone can consider they do not need to authenticate each other, Notes
while for all sensitive communication across trust boundaries, authentication is needed.
Where the trust zone is a useful concept, it does not fulfill all requirements. Trust zones are
frequently hierarchical, and some interaction with external parties can be completed without
requiring to authenticate the incoming party. A business might see itself as a single trust zone
in the sense that no one apart from employees can use network resources inside the firewall.
Though, a single-zone picture like this will be misleading if, as generally happens, there is also
a trust zone separating the ERP (Enterprise Resource Planning) and CRM (Customer Relationship
Management) applications, as each of these executes and maintains its own application-level
security. The business might also view itself as a member of an external trust zone via its
membership of a trading extranet. In this concern, we suggest that trust and authentication are
explicit, yet overlapping, intents that can be accessed to a collaboration model.
This domain is initially accountable for making sure that, once we understand who you are, we
can limit your choices to only those functions you are authorized to execute. This needs the
potential to perform authentication, since we must know who you are before we can judge what
you are efficient to do. The business stakeholder would like to recognize those functions that
require to be made protected, in the sense that we know who might execute them and we know
(via audit) when they were executed. There are obviously functions that do not need
authorization, either as we want them to be usable to everyone, or since, for performance
reasons, we have recognized a trust zone inside which services can securely assume the requester’s
right to use them.
This trust zone thought becomes imperative when we think of performance as another, sometimes
competing, issue, and since there is a cost related with implementing security, and sometimes
that price is pretty high. Consider a function to return the number of marvelous orders for a
customer — a very simple query from a database. If we query for authentication, authorization,
and privacy we are forced to accept imperative costs:

1. We have to ask the requester to offer credentials.
2. We have to verify those credentials, probably with a remote service.
3. We have to encrypt the returned information.
If we understand that the requester and provider are both services of the similar application, we
can recognize them as a single trust zone, dispense with the overhead, and reap the advantage in
increased performance. From an architectural standpoint it is also significant to recognize all
the communication that occurs on within trust zones. This kind of communication should be
minimized and handled as much as possible as it displays the most likely point of failure in the
overall security execution.
In views of execution, there are two main approaches to authorization that are appealing to note
here:
1. Authorization of Individual Parties: Every party can be allocated an explicit set of access
rights to functions (even though to optimize the process, we might agree to consider the
absence of an explicit access right as either and implicit approval or disapproval of that
access right).

2. Authorization through Roles: Numerous roles can be generated for each application, and
access rights allocated as described above to those roles rather than to individual parties.
When every party is authenticated, the credentials supplied for the party involve the
party’s role, which then identifies whether the party is authorized to access a specific
function.

LOVELY PROFESSIONAL UNIVERSITY 205