Borland VisiBroker® 7.0 - Borland Technical Publications

Context PropagationTrusting AssertionsA server (end-tier) may choose to accept or not accept identity assertions. In the casewhere it chooses to accept identity assertions, there are trust issues that presentthemselves. While the server may know that the peer is authentic, it must also confirmthat the peer has the privilege to assert another caller or act on behalf of the caller.Since the caller itself is not authenticated by the end-tier, and the end-tier accepts themid-tier's assertion, the end-tier needs to ensure that it trusts the mid-tier to haveperformed proper authentication of the original caller. It, in turn, trusts the mid-tier'strust in the authenticity of the caller.There may be many peers to an end-tier system, some who are trusted as mid-tiers,and some that are just clients. Therefore, the privilege to speak for other callers mustbe granted only to certain peers.Trust assertions and plug-insWhen a remote peer (server or process) makes identity assertions while acting onbehalf of the callers, the end-tier server needs to trust the peer to make suchassertions. The Security Provider Interface (SPI) allows you to plug in a Trust ServicesProvider to determine whether the assertion is allowed (trusted) for a given caller and agiven set of privileges for the asserter. Specifically, you use the TrustProvider class toimplement trust rules that determine whether the server will accept identity assertionsfrom a given asserting subject. For more information, see sec-api-doc in the Helpsytem, and the Chapter 12, “Security SPI for C++.”Backward trustBackward trust is provided “out of the box”, and is the form of trust where the serverhas rules to decide who it trusts to perform assertions. With backward trust, the clienthas no say whether the mid-tier server has the privilege to act on its behalf.Forward trustForward trust is similar to delegation in that the client explicitly provides certain mid-tierservers the privilege to act on its behalf.Temporary privilegesAt times, a server needs to access a privileged resource to perform a service for aclient. However, the client itself may not have access to that privileged resource.Typically, in the context of an invocation, access to all resources are evaluated basedon the original caller's identity. Therefore, it would not be possible to allow thisscenario, as the original caller does not have access to such privileged resource. Tosupport this scenario, the application may choose to assume an identity different fromthat of the caller, temporarily while performing that service. Usually, this identity isdescribed as a logical role, as the application effective requires to assume an identitythat has access to all resources that require the user to be in that role.Chapter 2: Getting Started with Security 21