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. 1.1.3

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

CurrentCurrent

ORB Core ORB Core

Target

ORB Security

Security Association

Security Association

ORB Security

Access control

Secure Invocation

SecureInvocation

Access controlAccess Decisio

n

Access Decisio

n

Access Decisio

n

Access Decisio

n

PolicyPolicyObj-

Reference

Obj-Reference

ClientClientCredentialsCredentials

CurrentCurrent

CredentialsCredentials

Security Association

Security Association

PolicyPolicy

Secure Inter-

operability

Big Picture

CORBA Invocation SecurityClient 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