11.07.2015 Views

Borland VisiBroker® 7.0 - Borland Technical Publications

Borland VisiBroker® 7.0 - Borland Technical Publications

Borland VisiBroker® 7.0 - Borland Technical Publications

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Context PropagationContext PropagationPluggable AuthorizationVisiSecure provides the ability to plug-in an authorization service that can map users toroles. The implementer of the Authorization Service provides the collection ofpermission objects granted access to certain resources. A new class, RolePermission isdefined to represent “role” as permission. The Authorization Services Provider in turnprovides the implementation on the homogeneous collection of RolePermissionscontained for an association between given privileges and a particular resource.The Authorization Service is tightly connected with the concept of Authorizationdomain—each domain has exactly one Authorization Services Providerimplementation. The Authorization domain is the bridge between VisiSecure systemand the authorization service implementation. During the initialization of the ORB itself,the authorization domains defined by the property vbroker.security.authDomains areconstructed, while the Authorization Services Provider implementation is instantiatedduring the construction of the Authorization domain itself.The Authorization Domain defines the set of rules that determine whether a userbelongs to a logical “role” or not.For more information, see Chapter 4, “Authorization.”In addition to ensuring the confidentiality and integrity of transmitted messages, youneed to communicate caller identity and authentication information between clients andservers. This is called delegation. The caller identity also needs to be maintained in thepresence of multiple tiers in an invocation path. This is because a single call to a midtiersystem may result in further calls being invoked on other systems which must beexecuted based on the privileges attributed to the original caller.In a distributed environment, it is common for a mid-tier server to make identityassertions and act on behalf of the caller. The end-tier server must make decision onwhether the assertion is trusted or not. When propagating context, the client transfersthe following information:■■■Authentication token—client's identity and authentication credentials.Identity token—any identity assertion made by this client.Authorization elements—privilege information that a client may push about thecaller and/or itself.Identity assertionsIdentity assertion occurs when several servers with secure components are involved ina client request. At times, it is necessary for a server to act on behalf of its clients—when a client request is passed from one server to another. This is typical in the casewhere a client calls a mid-tier server, and the server further needs to call an end-tierserver to perform a part of the service requested by the client. At such times, the midtierserver typically needs to act on behalf of the client. In other words, it needs to letthe end-tier server know that while it (the mid-tier server) is communicating with theend-tier server, access control decisions must be based on the original caller'sprivileges and not its privileges.Chapter 2: Getting Started with Security 19

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!