Securing the Broker Pattern Patrick Morrison 12/08/2005

Presentation Outline Present Broker Discuss security issues with Broker Survey CORBA as a Broker implementation that addresses security Abstract these ideas into Secure Broker

Broker Pattern The Broker architectural pattern can be used to structure distributing software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions. [POSA1] (e.g. WWW, CORBA)

Problem Broker decouples communications from application concerns, but does not address security issues; un- addressed, these can compromise an application’s usefulness. In addition to Broker’s role in decoupling communications from applications, the Secure Broker must: –Protect Clients from illegitimate Servers and Brokers –Protect Servers from illegitimate Clients and Brokers –Protect Brokerss from illegitimate Clients and Servers

Problem in Stick Figures Forgery –Client: I’m Bill Gates, please give me $1M –Broker: I’m Bank of America, deposit your money here. –Server: I’m Wells Fargo, I can carry those money bags away for you. Betrayal (by Trusted Server) –Client: Give me my Bank –Broker: Here’s your Bank –Bank: (Actually the Bad Guy’s server) Denial (of Service) –Client: I’d like to speak to my Bank. –Broker: What Bank?

Forces The existing Broker pattern does not address security concerns. Broker will typically require security Security is difficult to ‘get right’ Implementations of Broker have addressed security concerns – CORBA, WWW

(One Possible) Solution Find implementations of Broker that address security concerns Evaluate their security attributes Factor lessons learned back in to the original pattern. Motto: “Prefer discovery to invention.”

Broker in Detail Class Diagram Sequence Diagrams Security issues in the Scenarios/Use Cases

Broker Class Diagram

Server Registration

Client Requests Service

Broker Forwards Request

Implementation Evaluation:CORBA CORBA in Broker terms Security Architecture Lessons Learned

CORBA in Broker Terms

CORBA Security Threats Addressed An authorized user of the system gaining access to information that should be hidden from him. A user masquerading as someone else, directly or through delegation. Security controls being bypassed. Eavesdropping on a communication line Tampering with communication Lack of accountability due, for example, to inadequate identification of users. Source: Corba Security Service v1.8, sect

CORBA Security Overview Principals are the primary actors Principals have credentials indicating what their permissions are Credentials are issued by a trusted intermediary (“Principal Authenticator”) Targets are the primary resources requested A given object may be Principal and Target Policies relate credentials to Principals

CORBA Security Overview Secure Object Invocation –Establish trust relationship between Principal and Target Authenticate each other Present Principal credentials to Target object Establish security context –Determine whether Principal may execute the requested Target operation –Audit the invocation –Protect request and response from tampering and eavesdropping

CORBA Security Overview Access Control Model –Object Invocation Access Policy Enforced by Proxies/ORB Enforced through Access Decision functions –Binary result: yes/no, allow/deny –At Principal: rules for invocation “Can I ask Johnny to come out and play?” –At Target: rules for accepting request “Not after 6.” Policies built on top of access decision framework

Current ORB Core Target ORB Security Security Association ORB Security Access control Secure Invocation Secure Invocation Access control Access Decision Policy Obj-Reference Client Credentials Current Credentials Security Association Policy Secure Inter- operability Big Picture

CORBA Invocation Security Client Application (Message Sender) ORB Security Enforcement Subsystem Execution Context Credential Identity Privileges Message Policy Enforcement Code Target Object Domain Domain Policy

CORBA Security Overview The Untold Story –Policies –Domains –Non-Repudiation

CORBA in UML: Credentials

CORBA in UML goes here Presentation status: The glue’s not quite dry. Mea culpa.

CORBA Lessons Security begins with Identity – Principals, authorization Implement access control in the proxies and Broker Implement mechanism, not policy Implement (optional) encryption when messages pass across bridges.

Secure Broker Intent: Provide secure interactions between distributed components. Example: Online Bank, Customer makes withdrawal – want to be sure that the Customer gives his account only to the Bank, and that the Bank distributes the Customer’s money according to the Customer’s wishes. Context: Distributed computing systems, homogeneous or heterogeneous.

Secure Broker Problem: Broker decouples communications from application concerns, but does not address security issues; un-addressed, these can compromise an application’s usefulness. In addition to Broker’s role in decoupling communications from applications, the Secure Broker must: –Protect Clients from illegitimate Servers and Brokers –Protect Servers from illegitimate Clients and Brokers –Protect Brokers from illegitimate Clients and Servers

Secure Broker Forces –Broker distributes objects, but distribution does not imply trust –Client access to Servers may need to be restricted –Server access to Clients may need to be restricted –Trust for an intermediary can be established

Secure Broker Solution: ‘Borrow’ CORBA security ideas for application to the Broker pattern –Identity –Credentials –Access Decisions

Secure Broker Structure

Next Steps Sequence Diagrams Other implementations Other patterns: Broker Revisited, Lookup