1 / 30

Securing the Broker Pattern

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.

miracle
Download Presentation

Securing the Broker Pattern

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Securing the Broker Pattern Patrick Morrison 12/08/2005

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

  3. 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)

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

  5. 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?

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

  7. (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.”

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

  9. Broker Class Diagram

  10. Server Registration

  11. Client Requests Service

  12. Broker Forwards Request

  13. Implementation Evaluation:CORBA • CORBA in Broker terms • Security Architecture • Lessons Learned

  14. CORBA in Broker Terms

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

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

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

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

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

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

  21. CORBA Security Overview The Untold Story • Policies • Domains • Non-Repudiation

  22. CORBA in UML: Credentials

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

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

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

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

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

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

  29. Secure Broker Structure

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

More Related