Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Service-Oriented Architectures/Middlware CSE 333 Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155 [email protected] http://www.engr.uconn.edu/~steve (860) 486 - 4818 † Special Thanks to Prof. Alex Shvartsman, Keith Bessette, Scott Craig and Prior CSE333 students for providing portions of this material. SOA+MW-1.1 What is a Distributed Application? CSE 333 Distributed Computing/Applications are … Systems of Systems Interoperation of New & Existing Applications Legacy, Databases, COTS, New Clients, etc. Network Centric Environment Distributed Computing Applications must … Manage, Control, Access, and Modify Data Allow Humans to Interact with Data Provide High-Availability and Performance Evolvable Over Time Present & Future Army Systems Exhibit All of These Characteristics and More! SOA+MW-1.2 What is a Distributed Application? CSE 333 System of Systems Heterogeneity Hardware OS, PLs Network Centric Environment DB Client Legacy Client Legacy Database COTS Dynamic Environment High-Availability Performance Java Client Server Server Legacy Java Client Database COTS COTS Client Increase Productivity New/Innovative Transparent Interoperation Information Use SOA+MW-1.3 Another View – Today’s Reality CSE 333 Premise: Artifacts - set of DB, Legacy, COTS, GOTS, Each w/ API Premise: Users New and Existing Utilize Artifact APIs Distributed Application, DA Artifacts + Users What are the Issues? How Do they Interact? Heterogeneity Security Concerns Different Programmatic Models Etc. Etc. Etc. Database COTS Legacy Legacy Client Java Client GOTS NETWORK GOTS Client Legacy Database Database Client COTS Client SOA+MW-1.4 Why is Distributed Computing Needed? CSE 333 Today’s Environments Contain Applications … Created with Multiple Prog. Languages Executing on Heterogeneous Platforms Locally and Geographically Distributed Distributed Computing Applications Must … Allow Seamless and Transparent Interoperation Provide Tools for Engineers and Users Result: Inter-Operating Environment Utilize Information in New/Innovative Ways Leveraged to Increase Productivity Support Diverse User Activities Dynamically Respond to Changes SOA+MW-1.5 Striving for New Techniques/Technologies CSE 333 We Must Diverge from Business as Usual C Programming with RPC Customized Development without Reuse Solutions that Aren’t Extensible and Evolvable Cobbling Together Solutions w/o Method or Reason is Unacceptable and Doomed to Fail! We Must Face Today’s Realities Legacy Code is Fact of Life New Technologies Offer New Challenges Adopt to Leverage Their Benefits We Must Draw Careful Balance to Opt for Mature Technologies While Targeting Emerging Technologies with Potential! SOA+MW-1.6 Who are the Players? CSE 333 Stakeholders Software Architects (Requirements) System Designers (Solutions) Application Builders (Implementation) Stakeholders Striving to Provide … System Interaction and Information Exchange Utilization of Existing Applications in New and Innovative Ways End-Users at Various Skill Levels and with Specific and Limited Access Requirements Novice vs. Adept vs. Expert Who Uses What When and for How Long? SOA+MW-1.7 Why a Distributed Application? CSE 333 Reasons: Data used is Distributed Computation is Distributed Application Users are Distributed 2 Key Issues for Solution: Platform-Independent Models and Abstraction Techniques Hide Low-Level Details Provide a Well-Performing Solution Works Today and Tomorrow! Shared Objects • Easy to Re-use • Easy to distribute • Easy to maintain SOA+MW-1.8 Distributed Systems Fundamental Realities of Distributed Systems CSE 333 Co-located Distributed Fast Slower Failures Objects fail together Objects fail separately, Network can partition Concurrent Access Only with multiple threads Yes Yes Not Inherently Often Add-On Capability Communication Secure SOA+MW-1.9 What is a Service Oriented Architecture? CSE 333 Solutions that Focus on Services that Need to be Available to Meet Need of Users (Entities) Users are Assumed to be Interacting via Client Applications (Browser or Standalone) Interactions with Services Transparent to Users (Integrated into Software) Interactions Between Entities Occur via a Message Exchange - Conceptual Resources are Software Artifact Accessible via API Consisting of Services Services are Logical Grouping of Methods (Functions) that are Available for Use Services are Utilized When Messages are Invoked Against Them by Outside Users Both Web-Based and Middleware Settings SOA+MW-1.10 Service Oriented Architectures (SOA) CSE 333 An SOA is often Cast in a Web-Based Setting Possible Services include: Data Transfer (e.g. FTP) or Storage Service Troubleshooting Service Service Operations (Messages) are Encapsulated Behind a Message-Oriented Service Interface Hides Details of Service Implementation/Location Assumes an Architecture for Access Provides a Logical View that is Message-Oriented Available Service/Messages are Descriptively Supplied for Purpose of Discovery/Lookup Network-Oriented Scalable – Add New Services/Extend Existing Services for New/Improved Functionality SOA+MW-1.11 Middleware-Based SOA CSE 333 Distributed Object Computing Platforms are Well Established in the Field - Historically DCE (Distributed Computing Environment) COM/OLE (Component Object Model/Object Linking and Embedding) Modern Middleware (JINI, CORBA, .NET): CORBA –Standards Committee (OMG) Controls Technology – Many Programming Languages JINI – Sun-Based Product – The Poor Mans CORBA – Java .NET – Microsoft’s Forward into the Modern Market – C# SOA+MW-1.12 Web-Based SOAs CSE 333 While Not our Focus – Important to Understand their Role in SOA From Web Services Architecture, W3C A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Webrelated standards. SOA+MW-1.13 Web Services Architecture from W3C CSE 333 Complex Architecture with Many Different Capabilities and Features Open Ended (Like Web) Target Multiple Domains/Usages Current Web and Future (Emerging?) Semantic Web SOA+MW-1.14 What Must All SOA Provide? CSE 333 Both Middleware & Web-Based SOAs Must Provide Middle Layer Infrastructure that Provides Bridge Between Software Artifacts Clients and Resources in Middlware Setting Clients (Browsers) and Resources in Web Setting Allow Software Artifacts (Resources) to Register/Publish their APIs (Services and Methods) for use by Clients/Other Resources Lookup Service: Middleware that Provides Means for Software Artifacts (Resources and/or Clients and/or Other Resources) and to Interact Support Dynamic Discovery – Find Services Based on Attributes and Values Location Transparency to Service Requestors SOA+MW-1.15 Objectives of SOA CSE 333 Can SOAs Support Highly-Available Distributed Applications? Can Replicated Services be Registered and Available for Use by Clients? Can SOAs Support a Network-Centric Environment with Dynamic Clients and Services? Will Clients Continue to Operate Effectively if a Replicated Service Fails? Can SOAs be Utilized to Maintain Data Consistency of Replicas? Are SOAs Easy to Learn and Use? What is Maturity Level of SOAs Technology? SOA+MW-1.16 Overview of Presentation CSE 333 Objective is to Explore CORBA, JINI, and .NET Various Aspects of Three Technologies A B C D Comparison of CORBA, J2EE (Java), and .NET from Security Perspective What Does Each Support? Limits and Capabilities of Security Models Multi-Tier Architectural Solutions Examples of Various Architectures Interplay and Interactions of Technologies SOA+MW-1.17 What is CORBA? CSE 333 Common Object Request Broker Architecture Architecture to Allow: Existing COTS, GOTS, Legacy, DB, etc. to Interact with One Another Integrate These with New Clients/Servers/Etc. Consists of Following Major Components Object Request Broker (ORB): Arbitrate and Interact Role of Lookup for Service Discovery Interface Definition Language (IDL): Common Definitional Format Means for Different “Software” written in Different Languages to Interact with One Another SOA+MW-1.18 What is CORBA? CSE 333 CORBA is a Specification for Interoperability OMG (Object Management Group) Supplies a Set of Flexible Abstraction and Concrete Services Vendors Must Follow Standard CORBA Language Mappings Ada C and C++ COBOL Java to IDL Lisp CORBA Scripting Language Smalltalk Others Perl Haskell Python Eiffel PHP/ORBit SOA+MW-1.19 What is CORBA? CSE 333 Differs from Typical Programming Languages Objects can be … Located Throughout Network Interoperate with Objects on other Platforms Written in Ant PLs for which there is mapping from IDL to that Language Application Interfaces Domain Interfaces Object Request Broker Object Services SOA+MW-1.20 What is CORBA? CSE 333 CORBA Provides a Robust set of Services (COS) Services to Support Integration and Interoperation of Distributed Objects Services Defined on top of ORB as standard CORBA Objects with IDL interfaces Vendors Must Implement CORBA Services (COS) Factory Naming Context Object Request Broker Event Channel Object Life Cycle Naming Events Relationships Externalization Transactions Trader Query Property SOA+MW-1.21 What is CORBA? CSE 333 Allow Interactions from Client to Server CORBA Installed on All Participating Machines Client Application Static Stub DII Server Application ORB Interface ORB Interface Skel eton DSI Object Adapter Client ORB Core Network IDL - Independent Same for all applications Server ORB Core There may be multiple object adapters SOA+MW-1.22 CORBA: Architectural Goals CSE 333 Simplicity Consistency Scalability Usability for End Users Usability for Administrators Usability for Implementers Flexibility of Security Policy Independence of Security Technology Application Portability Interoperability Performance Object Orientation SOA+MW-1.23 Role of an Object Request Broker (ORB) CSE 333 ORB Provides the Underlying Infrastructure for Supporting Interoperating Software Systems (Applications) Composed of Distributed Objects ORB Provides the Basic Request Delivery ORB Provides Interface Definitions Location is Transparent to the Caller and Object Implementation Caller and the Object Implementation Can be in the Same Process thru Opposite Sides of the World ORB Manages Local Location and Optimization ORB Clie nt Obje ct Application Imple me ntation SOA+MW-1.24 Interface Definition Language, IDL CSE 333 Key Component of CORBA Is the Interface Definition Language, IDL Mapping is Available in C, C++, Java, Ada, Etc. IDL Is Independent of Any Language/Compiler Multiple Inheritance Public Interface Oriented Not for Implementation Primary Support for Interoperability Between Static and Dynamic Request Mechanisms Advantage: Modification of Client Code without Impacting of Server Code, and vice-versa Disadvantage: A complete new language with C++ like Syntax Programmers Must Prepare IDL Modules SOA+MW-1.25 ORB and High Level View of Requests CSE 333 The Request Consists of Target Object Operation (Method) Parameters Request Context (Optional) Clie nt Application Obje ct Imple me ntation Object Call IDL Boundary Object reference Methods and D ata ORB Request IDL Boundary Object dispatcher SOA+MW-1.26 CORBA Components and Interfaces CSE 333 Client Stub: Client Invokes a Particular Object Op. Dynamic Invocation: Run-Time-Construction of Operation Invocations Implementation Skeleton: Interface Through Which a Method Receives a Request Object Adapter: Provides (De)activation, Object Creation/Reference Mgmt. for Implementations ORB Interface: Common ORB Operations Client Dynamic Invoke Client Stubs Object Implementation ORB Interface Implementation Skeletons Object Adapter ORB Core One interface One interface per object adaptor One interface per object operation ORB internal interface SOA+MW-1.27 Interfaces CSE 333 Objects are Defined in IDL via Interfaces Object Definitions (Interfaces) are Manifested as Objects in the Interface Repository, as Client Stubs, and as Implementation Skeletons Descriptions of Object Implementations are Maintained as Objects in the Impl. Repository IDL Interface Definitions Interface Repository Access Client Stubs Includes Client Implementation Installation Implementation Skeletons Includes Implementation Repository Describes Object Implementation SOA+MW-1.28 CORBA: Repositories CSE 333 Interface Repository Client access to definitions Type checking for signatures Traversal of inheritance graphs Implementation Repository IDL Interface Definitions Interface Repository Location of implementation Activation information Administration control Security Resource allocation Implementation Installation Client Stubs Implementation Skeletons Implementation Repository Access Includes Client Describes Includes Object Implementation SOA+MW-1.29 Client Side CSE 333 Clients Perform Requests Using Object References Clients Issue Requests through Object Interface Stubs (Static) or DII (Dynamic Invocation Inter.) Clients May Access General ORB Services: Interface Repository (IR) Context Management Request Management Client Object Repository Object Implementation Dynamic Invoke Client Stubs ORB Interface Implementation Skeletons Object Adapter ORB Core SOA+MW-1.30 Object Implementation Side CSE 333 Implementations Receive Requests Thru Skeletons Object Adapter Adapts to Specifics of Object Implementation Schemes Basic Object Adapter (BOA) Provides: Management of References Method Invocation Authentication Implementation Registration Activation / Deactivation Object Implementation Client Dynamic Invoke Client Stubs ORB Interface ORB Core Implem. Skeletons Implementation Repository Object Adapter SOA+MW-1.31 CORBA CSE 333 Basic Object Adapter (BOA) Provides Basic Services to Allow Variety Of CORBA Objects to be Created – Ambiguous Portable Object Adapter (POA) Allow Developers yo Construct Object Implementations that are Portable Between ORBs Mediator Between ORB And Server Server Applications Servants Client ORB POA Incoming Request SOA+MW-1.32 CORBA: POA Policies CSE 333 Provided to Programmer for Control Over an Object’s Identity, State, Storage and Life-cycle 7 Different Policies Thread Policy Life-Span Policy Object ID Uniqueness Policy ID Assignment Policy Servant Retention Policy Request Processing Policy Implicit Activation Policy We Briefly Review each in Turn SOA+MW-1.33 CORBA: POA Policies CSE 333 Thread Policy - Depends on Number of Objects the Application Will Have Depends on Operating System Expected Load on System ORB_CTRL_MODEL/SINGLE_THREAD_MODEL Life Span Policy - Transient object cannot live beyond the process which created it Persistent object can live beyond the process which created it TRANSIENT / PERSISTENT Object ID Uniqueness Policy UNIQUE_ID / MULTIPLE_ID SOA+MW-1.34 CORBA: POA Policies CSE 333 ID Assignment Policy - To specify whether Object ID was generated by the application or ORB USER_ID / SYSTEM_ID Servant Retention Policy: States if POA retains active servants in object map RETAIN / NON_RETAIN Request Processing Policy: States how request processed by the POA USE_ACTIVE_OBJECT_MAP_ONLY / USE_DEFAULT_SERVANT / USE_SERVANT_MANAGER Implicit Activation Policy: Indicates if Implicit activation of servants is supported by POA IMPLICIT_ACTIVATION / NO_IMPLICIT_ACTIVATION SOA+MW-1.35 Dynamic Invocation Interface (DII) CSE 333 DII Allows Clients to Dynamically: Discover Objects Discover Objects’ Interfaces Create Requests Invoke Requests (-> Methods) Receive Responses Major DII Features: Requests Appear as Objects Requests are Reusable Invocation May be Synchronous or Asynchronous Requests Can be Generated Dynamically, Statically or Using Both Approaches SOA+MW-1.36 Request Components CSE 333 Object Reference -- Identifies the Target Object Operation -- Identifies Which Operation to Invoke (Which Method Will Be Executed) Parameters -- Input, Output or Inout Method Arg-s Context Object -- the Context Within Which the Request Is to Be Performed Results -- the Result Value(s) Returned Environment -- the Exec-n Env-t and Exception Info. Request Handle -- the Id. For This Request Instance SOA+MW-1.37 Repositories: Interface and Implementation CSE 333 Interface Repository Dynamic Client Access to Interface Definitions to Construct a Request Dynamic Type Checking of Request Signatures Traversal of Inheritance Graphs Implementation Repository Location of Implementations and Methods Activation Information Administration Control Resource Allocation Security SOA+MW-1.38 Three Types of ORBs Single Process Library Resident CSE 333 Client ORB Object ORB and implementations implemented as libraries (routines) resident in the client. Request Client and Implementation Resident Client ORB Object ORB implemented as libraries (routines) resident in the clients and in the implementations. Request SOA+MW-1.39 Three Types of ORBs Server or Operating System Based CSE 333 Client ORB Object Request ORB is implemented as a server (separate process) which brokers requests between client and implementation processes. ORB is part of the operating system. SOA+MW-1.40 Three Types of Implementations CSE 333 Single Process “one shot” Object Object Implementation Single Process Single method invocation Implementation is a single process that is activated upon the request delivery Multi-Threaded “resident” Object Object Implementation Single Process Implementation is a permanent or resident multi-threaded process Method C Method B Method A SOA+MW-1.41 Three Types of Implementations CSE 333 Multi-Process Object Object Implementation Process 1 Method A Process 2 Method B Implementation is a set of processes dedicated to a particular (group of) method(s) Process 3 Method C Processes can be distributed SOA+MW-1.42 System Design with CORBA CSE 333 Scott A. Craig Computer Science & Engineering Department The University of Connecticut Storrs, Connecticut 06269-3155 [email protected] SOA+MW-1.43 Overview of Presentation CSE 333 Introduction to OMG IDL Object Management Architecture CORBAservices Naming Service Event Service Typed Event Example References Concluding Remarks SOA+MW-1.44 Interface Definition Language, IDL CSE 333 Language used to describe the interfaces that client objects call and object implementations provide. Obeys the same lexical rules as C++, but introduces some new keywords. Supports standard C++ preprocessing features. Interfaces can have operations and attributes. Operation declaration consists of a return type, an identifier, a parameter list, and an optional raises expression (exceptions). Attribute declaration is logically equivalent to declaring a pair of accessor operations. May be declared as readonly. Interface specifications are placed in a source file having the extension “.idl” SOA+MW-1.45 IDL: Modules and Interfaces CSE 333 Module: Used to scope IDL identifiers. Mapped to C++ namespace with the same name. Mapped to a C++ class if the namespace construct is not supported. Mapped to Java package with the same name. IDL declarations not enclosed in any module have global scope when mapped. Interface: Description of set of operations that a client may request of an object. Multiple inheritance supported Interface body may contain the following kinds of declarations: constant, type, attribute, and operation. SOA+MW-1.46 IDL: Basic Types CSE 333 Type Range short -215 .. 215-1 (16-bit) unsigned short 0 .. 216-1 (16-bit) long -231 .. 231-1 (32-bit) unsigned long 0 .. 216-1 (32-bit) float IEEE single-precision floating point double IEEE double-precision floating point char 8-bit quantity boolean TRUE or FALSE octet 8-bit (guaranteed during transmission) any values that can express any IDL type SOA+MW-1.47 IDL: Complex Types CSE 333 Structures: struct FixedLengthStruct { long field1; // 32-bit short field2; // 16-bit }; struct VariableLengthStruct { long field1; // 32-bit string field2; }; Discriminated Unions: Cross between the C union and switch statements. Enumerations: Ordered list of identifiers. enum quality_t { Poor, Fair, Good, Excellent}; SOA+MW-1.48 IDL: Complex Types (cont.) CSE 333 Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run time). Unbounded Sequence: typdef sequence<long> longSeq; Bounded Sequence: sequence<long,10> fieldname; Strings: Declared using keyword string. May be bounded or unbounded. string name<32>; //bounded Arrays: Multidimensional, fixed-size arrays of any IDL data type. SOA+MW-1.49 IDL Example: GUI CSE 333 /* * File Name: */ GUI.idl #ifndef GUI_IDL #define GUI_IDL module GUI { struct timespec_t { long tv_sec; long tv_nsec; }; interface Dialog1 { void update(in Dialog1Data_t val); }; interface Dialog2 { void update(in Dialog2Data_t val); }; }; #endif // GUI_IDL struct Dialog1Data_t { timespec_t DataTime; float val; }; struct Dialog2Data_t { timespec_t DataTime; long val; }; interface MainWindow { void logEvent(in timespec_t timestamp, in string val); }; SOA+MW-1.50 IDL Example: Server CSE 333 /* * File Name: */ Server.idl #ifndef SERVER_IDL #define SERVER_IDL #include "GUI.idl" interface Server { enum reason_t { NotInitialized, ErrorDetected }; exception NotAvailable { reason_t reason; }; exception OperationTimeout {}; void registerMainWindow( in GUI::MainWindow val, in boolean flag) raises (OperationTimeout); void setMainWindowEnabled( in boolean flag) raises (OperationTimeout); void registerDialog1( in GUI::Dialog1 val, in boolean flag) raises (OperationTimeout); void setDialog1Enabled( in boolean flag) raises (OperationTimeout); GUI::Dialog1Data_t getDialog1Data() raises (OperationTimeout, NotAvailable); void registerDialog2( in GUI::Dialog2 val, in boolean flag) raises (OperationTimeout); void setDialog2Enabled( in boolean flag) raises (OperationTimeout); GUI::Dialog2Data_t getDialog2Data() raises (OperationTimeout, NotAvailable); }; #endif // SERVER_IDL SOA+MW-1.51 Object Management Architecture CSE 333 The Object Management Group, Inc (OMG) has established the Object Management Architecture (OMA), upon which OMG specifications are based Components of the OMA Reference Model: Object Request Broker (CORBA): Provides communications infrastructure. Object Services (CORBAservices): Collection of fundamental services (interfaces and objects) for using and implementing objects. Common Facilities (CORBAfacilities): Services such as system management. Application Objects Not standardized. SOA+MW-1.52 CORBAservices CSE 333 OMG specification for Object Services Collection of 15 services (interfaces and objects) that support basic functions for using and implementing objects. Interfaces specified using IDL Will focus on two services: Naming Service Event Service Security Service: Addresses identification and authentication, authorization and access control, security of communication between objects, etc. Beyond scope of this presentation (specification is 386 pages in length) SOA+MW-1.53 Naming Service CSE 333 Facilitates locating objects in a distributed system. A name binding is a name-to-object association and is always defined relative to a naming context. A naming context is an object that contains a set of name bindings in which each name is unique. Multiple names may be bound to an object. Servers bind names to objects and clients resolve names to objects. A naming context may be bound to a name in another naming context creating a naming graph. Directed graph with labeled edges in which nodes are objects. Compound names are formed by the sequence of names along a path from the root to the leaf. SOA+MW-1.54 References CSE 333 Object Management Group, Inc. (OMG), http://www.omg.org OMG, A Discussion of the Object Management Architecture, 01/97 OMG, The Common Object Request Broker: Architecture and Specification, Rev. 2.2, 02/98 OMG, CORBAservices: Common Object Services Specification, 12/98 T. J. Mowbray and R. Zahavi, The Essential CORBA: Systems Integration Using Distributed Objects, John Wiley & Sons, Inc., 1995 G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, AWL, Inc. 1999 SOA+MW-1.55 JINI CSE 333 SOA+MW-1.56 What is JINI? CSE 333 An Infrastructure for Network Centric Applications in Spontaneous Environment Clients Enter/Leave Network Unpredictably Resources and Services Enter/Leave due to Failure, Redundancy, Topology Change Both Typify Present/Future Army Systems Goals of JINI Plug-and-Play of Clients and Services Erasing Hardware/Software Distinction: Everything is a Service Enable Spontaneous Network Applications Architecture where Services Define Function Strive for Easy to Use/Understand Technology SOA+MW-1.57 Sun’s JINI Technology CSE 333 JINI is a Sophisticated Java API Construct Distributed Applications Using JINI by Federating Groups of Users Resources Provide Services (Database Access, Printing, Real-Time Sensor) for Users JINI and Stakeholders Core of Technologies to Architect, Design, Implement, and Test Distributed Applications Construct Software “Resistant” to Failure JINI and Users High Availability Through Redundancy Dynamic Responses to User Requests Regardless of Network & Resource Changes SOA+MW-1.58 Java Computing Architecture and JINI CSE 333 SOA+MW-1.59 JINI Components and Dependencies CSE 333 Base Java Infrastructure Programming Model Services Java VM Java APIs JNDI RMI JavaBeans Enterprise Beans Java Security JTS JMS Java + JINI Discovery/Join Leasing Distributed Security Lookup Transactions Transaction Manager JavaSpaces Events Lookup service SOA+MW-1.60 How Does JINI Work? CSE 333 Distributed Application Constructed Using One or More Lookup Services Lookup Service Support Interactions by Resources: “Advertise” Services Discover, Register Services, Renew Lease Client: “Locate/Utilize” Services Discover, Search for Services, Invocation Multiple Lookup Services Resources Responsible for Registering All Clients Interact with Multiple Lookups Stakeholders Must Write “Apropos” Code Discovery Initiates Process for Client or Resource SOA+MW-1.61 Discovery by Resource & Client CSE 333 JINI Lookup Service Discovery to Locate Services JINI Lookup Service Discovery to Register Services Resource Client Service Object Service Attributes SOA+MW-1.62 Basic JINI Concepts CSE 333 JINI Lookup Service Maintains Registry for Available Services of Distributed Application Resources Provide Services that Register and Join with JINI Lookup Service Clients Discover and Utilize Services Based on Interface of Services Ask Lookup for RegisterForCourse(CSE900) Return Proxy for Execution of Service Location of Service Transparent to Client Locations of Clients, Services, Lookup Service, etc., can Change over Time Conceptually, JINI Similar to Distributed OS with Dynamically Definable/Changeable Resources SOA+MW-1.63 Basic JINI Concepts CSE 333 A Resource Provides a Set of Services for Use by Clients (Users) and Other Resources (Services) A Service is Similar to a Public Method Exportable - Analogous to API Any Entity Utilized by Person or Program Samples Include: Computation, Persistent Store, Printer, Sensor Software Filter, Real-Time Data Source Anything that is Relevant for Your Domain! Services: Concrete Interfaces of Components Services Register with Lookup Service Clearinghouse for Resources to Register Services and Clients to Locate Services SOA+MW-1.64 JINI Resources & Services CSE 333 JINI Lookup Service Register Services Printer Resource Service Object Service Attributes Sun’s Initial Perspective JINI for Hardware Class and Methods Printers, Digital Define Cameras, etc. Services Plug-and-Play on to be Network PrinterActions Class Defines Registered the “Component” that is Registered with JINI PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob SOA+MW-1.65 Objectives and Utility of JINI CSE 333 For Users, JINI Offers Sharing of Resources (Services) over Network Location Transparency of Users and Services Both Critical for “Moving” Personnel For Stakeholders, JINI Provides Infrastructure for Federating Services in Distributed Setting Programming Model to Register & Discover Services Availability of Services Throughout Distributed Setting Leading to Ease in Constructing, Maintaining, and Evolving Network Centric Applications SOA+MW-1.66 How Does JINI Work? CSE 333 Resources Discover and Join Lookup Service When Resources Leave or Fail to Renew Leases Lookup Service Must Adjust Registry Time Lag Between Departure and Removal of Services from Registry What Happens When Client Receives Service Just Prior to Failure? Utilization of Java Exception Handling Client Code Written to Dynamically Adapt Resource Register Services on Class-by-Class Basis Service Object (Java API - Method Signatures) Optional Descriptive Service Attributes SOA+MW-1.67 JINI Concepts and Terms CSE 333 Registration of Services via Leasing Mechanism Resource Leases Services to Lookup Service Resources Renew Services Prior to Expiration If not, Services Become Unavailable Lookup Service Maintains Registry Limit Availability of Services Based on Time, Workload, User Requirements, etc. Services as Available “Components” Leasing Supports High-Availability Registration and Renewal Process Upon Failure, Services Removed from Registry Clients, Resources, Lookup Can Occupy Same or Different Computing Nodes SOA+MW-1.68 Registration & Leasing CSE 333 FOREVER or EXPIRATION DATE (millisecs) Renewal Must Occur Prior to Expiration JINI Provides Lease Renewal Manager to Allow Resource to Delegate Renewal Responsibility JINI Lookup Service Leasing/Lease Renewal Lease for 5 minutes (3000000 msec) Must Renew Before 5 Minutes Expire If Not Renewed, Lookup Removes If Failure, Lookup May Still Supply Service Until Expiration (5 mins) Client MUST be SMART! Printer Resource Service Object Service Attributes Class and Methods Define Services to be Registered PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob SOA+MW-1.69 JINI Support for Distributed Computing CSE 333 Clients Using Services JINI Lookup Service Redundant Lookups Java Client Database Legacy Resources Provide Services COTS Java Client Legacy Legacy Client COTS Database Client COTS Client Database JINI Lookup Service Legacy COTS SOA+MW-1.70 Component Perspective and JINI CSE 333 Resources as Components Resources Provide Services What Service Provides: Component Interface Clients, Servers, Resources, Use Component Interface to Design/Construct Functionality Java Client Constructed via Services of Legacy, COTS, Database, etc. Lookup Registered Services Functionality via Service Reuse Services as Component APIs Legacy COTS JINI Lookup Service Database Legacy COTS SOA+MW-1.71 Two Example Resources CSE 333 University Application Students can Register/Drop Courses and Check the Schedule/Catalog Faculty can Alter Course DB and Check the Schedule/Catalog Military Application - Database of Parts Ability to Requisition/Add/Delete Parts Different User Authority Based on Rank For Both: Client to JINI to Discover Services Client to Resource for Method Invocation (Resembles RMI) SOA+MW-1.72 What Does an Actual System Look Like? CSE 333 Java GUI UDB Client UDBServer Service GetClasses(); PreReqCourse(); GetVacantClasses(); EnrollCourse(); AddCourse(); RemoveCourse(); Java GUI MDB Client JINI Lookup Service MDBServer GetParts GetRequisition GetReqParts WriteParts WriteRequisition DeletePart DeleteRequisition AddParts RemovePart AddRequisition University DB Resource (UDB) Military Requisition DB Resource SOA+MW-1.73 Join, Lookup, and Service Invocation CSE 333 Request Service AddCourse(CSE900) Lookup Service Registry of Entries Return Service Proxy to AddCourse( ) Client Service Object Service Attributes J Register & Lease Services CourseDB Class o i Contains Method AddCourse ( ) n Service Invocation via Proxy by Transparent RMI Call Resource Service Object Service Attributes 1. Client Invokes AddCourse(CSE900) on Resource 2. Resource Returns Status of Invocation SOA+MW-1.74 Services of Military Application CSE 333 Query Service: GetParts: Queries DB for Parts GetRequisition: Queries DB for Requisition GetReqParts: All Requisition Details for a Particular Part Update Service: WriteParts: Store Part to DB WriteRequisition: Requisition Changes to DB DeletePart: Deletes Part from DB DeleteRequisition: Deletes Requisition from DB Other Services/Methods Omitted Notice: These are Just Public Methods Organized into Logical Groupings JINI Allows Searching of Groupings by Service SOA+MW-1.75 Execution Process of Client using JINI CSE 333 1 Register_Client(Harris,Security Off., Military) Military Client 4 Return Result,Create_Token(Security Off., Token) 2 Verify_UR(Harris, Security Off.) 5. Discover/Lookup(MilitaryDb,Modification, CreateRequisition) Returns Proxy to Military Client 6 CreateRequisition(Token, Tank Details, Harris) 11 Return Result,CreateRequisition(…) Lookup Service Security Registration Services 3 Client OK? USR Security Authorization Services 7 IsClient_Registered(Token) 9 Check_Privileges(Token, MilitaryDb, Modification, CreateRequisition, [Tank Details, Harris]) MilitaryDB Resource 8 Return Result of IsClient_Registered(…) Security Policy Services 10 Return Result of Check_Privileges(…) SOA+MW-1.76 Services Console CSE 333 SOA+MW-1.77 Services GUI CSE 333 SOA+MW-1.78 Microsoft’s .NET CSE 333 SOA+MW-1.79 .NET Framework Architecture CSE 333 SOA+MW-1.80 .Net CSE 333 CTS (Common Type System) Defines Common standard that languages should adhere to. CLR (Common Language Runtime) Manages the execution of a .Net application, provides cross platform support by ensuring type safety, code verification, exception handling, garbage collection and memory management ASP.NET This component provides a layer of classes for Web services SOA+MW-1.81 CSE 333 .Net Windows Forms Provides a layer of classes for the windows user interface ADO.NET Provides classes for data access including database and XML Base Class Library Provides the low level classes on which most of the .Net functionality and other >net Framework classes are built SOA+MW-1.82 Remoting CSE 333 Remoting makes an object in one process available to an application in another process Marshalling enables a controlled data communication between the 2 processes Marshalling an object can be done in 2 ways Marshall by value:Server creates a copy of the object and passes the copy to the client Marshall by reference: The server creates a reference of the object ans send this reference to the client SOA+MW-1.83 Remoting CSE 333 When a client calls an object marshalled by reference of the object in the client’s application domain and the client uses that proxy to access that original object on the server SOA+MW-1.84 Remoting CSE 333 When a client calls an object marshaled by value the server creates and exact copy and sends that copy to the client. The client then uses the data of the object and executes the required functionality directly within the client’s own process without making any additional calls to the server SOA+MW-1.85 .NET Framework Architecture CSE 333 SOA+MW-1.86 .Net CSE 333 CTS (Common Type System) Defines Common standard that languages should adhere to. CLR (Common Language Runtime) Manages the execution of a .Net application, provides cross platform support by ensuring type safety, code verification, exception handling, garbage collection and memory management ASP.NET This component provides a layer of classes for Web services SOA+MW-1.87 CSE 333 .Net Windows Forms Provides a layer of classes for the windows user interface ADO.NET Provides classes for data access including database and XML Base Class Library Provides the low level classes on which most of the .Net functionality and other >net Framework classes are built SOA+MW-1.88 Remoting CSE 333 Remoting makes an object in one process available to an application in another process Marshalling enables a controlled data communication between the 2 processes Marshalling an object can be done in 2 ways Marshall by value:Server creates a copy of the object and passes the copy to the client Marshall by reference: The server creates a reference of the object ans send this reference to the client SOA+MW-1.89 Remoting CSE 333 When a client calls an object marshalled by reference of the object in the client’s application domain and the client uses that proxy to access that original object on the server SOA+MW-1.90 Remoting CSE 333 When a client calls an object marshaled by value the server creates and exact copy and sends that copy to the client. The client then uses the data of the object and executes the required functionality directly within the client’s own process without making any additional calls to the server SOA+MW-1.91 Web Services ASP.NET Communication based on open protocols - Data XML -Schema XSD UDDI DISCO WSDL SOAP Security CSE 333 SOA+MW-1.92 ADO.NET CSE 333 SOA+MW-1.93 Security in Middleware - Motivation CSE 333 Distributed Computing Applications are Constructed From Legacy, COTS, Database, and Client/Server Applications Solutions Facilitate the Interoperation of Applications in a Network Centric Environment CORBA, DCOM/OLE, J2EE/EJB, JINI, and .NET have Enabled the Parallel and Distributed Processing of Large, Computation-intensive Applications Security has Historically Often Been an Afterthought Dramatic Turnaround in Support of Security within these Modern Middleware Platforms Thanks to Keith Bessette… SOA+MW-1.94 Overview CSE 333 Focus on the Attainment of Security within CORBA .NET J2EE Represent Three Dominant Middlware Platforms Emphasis on Exploring the RBAC/MAC Capabilities of Each What Can Each Offer in Support of Security? How do the Different Technologies Compare? Later - Focus on Using Middlware (e.g., CORBA, JINI) to Attain MAC/RBAC for Distributed Setting SOA+MW-1.95 Security in CORBA, .NET, and J2EE CSE 333 The CORBA Security Specification is a Meta-model, Similar in Concept to the UML Meta-model with Implementations (e.g., Together, Rational, etc.) Offers Wide Variety of Security Capabilities at the Model Level - RBAC, MAC, Encryption, Etc. Language Independent (Not Tied to Java, C++, .NET, Etc.) In Contrast, .NET and J2EE are Commercial Products Characterizable as Implementations or Instances of the CORBA Security Meta-model Transition Concepts into Platform Specific Implementations SOA+MW-1.96 CORBA Security Capabilities CSE 333 The CORBA Security Service Specification Focuses on Four Keys Aspects of Security Confidentiality: Concerned with Access to Information Limit Access to Those Individuals (Programs) That Have Been Given Explicit Permission Integrity: Only Authorized Users are Allowed to Modify Information Delegation of this Authorization Between Users is Tightly Controlled SOA+MW-1.97 CORBA Security Capabilities CSE 333 Accountability: Users Must be Responsible for All of their Actions Security Mechanisms Must be able to Monitor and Track the Accountability Availability: If Users have Been Appropriately Authorized, then their Authorizations Require the System's Availability SOA+MW-1.98 CORBA Security Capabilities CSE 333 Collectively, These Four Features Underlie the Security Offered in the Meta Model for Identification and Authentication of Users Authorization and Access Control of Users to Objects Security Auditing for Accountability Security of Communication Between Users and Objects Non-repudiation to Provide Proof of Access Administration of All of the Security Requirements SOA+MW-1.99 The CORBA Security Model CSE 333 The Structural Model of CORBA is Comprised of Different Levels used to Facilitate Secure Object Invocation by Clients Application Components: Client Request Services and a Target Object Providing Services ORB Security Services: Access Control Service - If the Operation Being Requested Is Permitted Secure Invocation Service - Protect the Target Object in Its Interactions With the Client Implementation of Security Services: Available in actual CORBA Implementations Platform Specific, must Interact with Security supported by OS and Hardware SOA+MW-1.100 The CORBA Security Model CSE 333 SOA+MW-1.101 Access Control in CORBA CSE 333 Must Verify the Characteristics of a Subject's Permissions (via Privilege Attributes) Against the Target Objects Target Objects Are Managed via Control Attributes (Grouped As Domains) and Operations (Grouped as Rights) Combination of Privilege Attributes, Control Attributes, and Domains Provides Means to Define Security Requirements Basis for Enforcing Those Requirements by Actual Clients Against Target Objects SOA+MW-1.102 Access Control in CORBA CSE 333 Privilege Attributes are Associated with the Client, Referred to as the Principal Privilege Attributes are Used to Capture All of the Various Security Permissions for Access Control Security Permissions: Identity (e.g., User Id) of the Principal Role(s) of the Principal Group(s) That the Principal Belongs to in the Organization Security Clearance (e.g., Secret, Classified, Etc.) Of the Principal Target Objects and Operations to Which the Principal Has Been Granted Access, and Any Other Enterprise-wide Privileges. SOA+MW-1.103 Access Control in CORBA CSE 333 Control Attributes are Associated with Each Target Object, to Track the Security Privileges from an Object's Perspective Control Attributes can also Track Security Information on the Target Object Itself Control Attributes Track All of the Principals on a Target-Object-by-Target-Object Basis List of all Principles for an Object Privilege Attributes Focus on Capabilities of Individual Principals SOA+MW-1.104 Access Control in CORBA CSE 333 Rights of a Target Object are the Set of Operations That Are Available for Assignment to Each Principal Examples: An Access Control List Entry for Each Target Object would Track the List of Principals Who Have Been Authorized the Role(s) of the Principal A Target Object Itself Might have a Security Classification (e.g., Secret, Classified, etc.) May Be Limited in Access to Certain Time Periods SOA+MW-1.105 Access Control in CORBA CSE 333 To Assist in the Security Definition Process of Principles and Objects for an Organization, Domains can be Utilized Domain: Provides a Context to Define Common Characteristics and Capabilities Related to Security Security Policy Domain Represents the Scope Over Which Each Security Policy is Enforced An Organization May Have Multiple Policies Security Policy Domain Permits the Definition of Security Requirements for a Group of Target Objects Group Can Be Managed As a Whole, Thereby Reducing the Needed Administrative Effort SOA+MW-1.106 Access Control in CORBA CSE 333 Policy Domain Hierarchies: Allows a Security Administrator to Design a Hierarchy of Policy Domains Delegate Subsets of the Hierarchy (Sub-domain) to Different Individuals Example: a Health Care Organization Sub-domains for Patient Objects, Test-result Objects, Employee Objects, Etc. Security for These Sub-domains Delegated to Different People in Hospital Administration SOA+MW-1.107 CORBA Security User Views CSE 333 Views to Provide a Hierarchical Structure of the Security Requirements for an Organization Enterprise Management View Organization-wide Perspective on the Treatment of Security Requirements Risk Assessment, Protection Against Malicious & Inadvertent Security Breaches, Countermeasures End Result Will Be the Definition of Security Policies, As Appropriate, for Different Portions of an Organization End User View Involves the Privilege Attributes (E.G., User Id, Role, Clearance, Etc.) Focus on the Privileges That Are Authorized, and Action Authentications of Users SOA+MW-1.108 CORBA Security Views CSE 333 Application Developer View Security Definitions Maybe Transparent to the Majority of Stakeholders (Programmers, Developers, Etc.) Security May Be the Strict Responsibility of All Stakeholders (Programmers, Developers, Etc.) Administrator’s View Security Management Perspective Creating and Maintaining the Domains Assigning the Privilege Attributes to End Users, Administrating the Security Policies, Monitoring the Control Attributes of Target Objects, Etc. SOA+MW-1.109 CORBA Security Execution Model CSE 333 Client Makes a Request to Access the Target Object. Must Obtain a Binding to the Target Object Requires a Check to See If the Client Has the Permissions (Via the Privilege Attributes) to Invoke an Operation on the Target Object (Via the Control Attributes) The Binding is Established, and a Reference to the Target Object is Returned, Allowing the Invocation The Ability to Obtain an Object Reference May Involve Interaction with a Policy Object and the Domain Manager SOA+MW-1.110 Security Binding in CORBA CSE 333 SOA+MW-1.111 Domain Objects in CORBA CSE 333 SOA+MW-1.112 CORBA: Security Considerations CSE 333 Threat to CORBA System Authorized user gaining access to data that should be hidden from him User masquerading as someone else; so that actions are attributed to the wrong person Security controls being by-passed Eaves-dropping on communication line – gaining access to confidential data Tampering with objects Lack of accountability SOA+MW-1.113 CORBA: Security Considerations CSE 333 Security Reference Model (SRM) Security Specification is meta-model Specification that is comprehensive (MAC, Encryption) Language Independent (C++, Java….) SOA+MW-1.114 CORBA: Security CSE 333 Encapsulated within IDL modules: Security: basic interface and data types SecurityLevel1: most basic, provides security feature to all app. SecurityLevel2: permits access to credentials & policies SecurityAdmin: permits manipulation of administrative features API Which implements abstraction defined in the reference model Security Technology Constitutes mechanisms like encryption, validation SOA+MW-1.115 CORBA: Security Specifications CSE 333 4 key aspects of security Confidentiality User Sponsor Authenticate – use principal authentication Object Security Service Integrity Prevents undetected, unauthorized modification of messages Detects message addition, deletion or change of order Client Application ORB Core Security Technology User Sponsor Accountability Availability Principal Authenticator Object Client Application Security Current Object ORB Credentials Object SOA+MW-1.116 CORBA: Security Specifications CSE 333 Security Conformance Level Applications unaware Applications aware User Sponsor Policy controlling Policy enforcing Client Application Security Service ORB Core Security Technology User Sponsor Principal Authenticator Object Client Application Security Current Object ORB Credentials Object SOA+MW-1.117 CORBA: Security CSE 333 Client Application Target Object (Message Sender) Execution Context Credential Identity Privileges Message Domain Policy Enforcement Code Domain Policy Security Enforcement Subsystem ORB SOA+MW-1.118 CORBA: Understanding CSE 333 Will run on any platform as long as ORB implementation exist. Provides extensibility, but is difficult Does not provide cross-language inheritance and exception capabilities Responsibility of locating an object implementation is on ORB Parameters between client and remote objects: interface types are passed by reference; others by value SOA+MW-1.119 CORBA: Understanding CSE 333 Does not attempt to perform general-purpose distributed garbage collection Exception handling is taken care by the Exception object Provides location independence SOA+MW-1.120 Microsoft’s .NET CSE 333 .NET is Microsoft’s Solution to Enterprise Computing and Interoperability Aimed to Compete with Java/J2EE Interoperability with Old (CORBA, COM) and New (RMI) Provide Uniform Programming Environment Extension of C - C# We’ll Briefly Compare/Contrast/Introduce .NET SOA+MW-1.121 Security in .NET/Java CSE 333 Secure Development and Execution Environments via a Number of Different Capabilities: Code-Based Access Control - CBAC: Permission for Code to Access Resources Role-Based Access Control - RBAC: Permission for Users/roles to Access Resources Code Verification and Execution: Semantics, Bytecode, Safe Execution Environment Secure Communication: Pass Data/messages Securely Code and Data Integrity: No Unauthorized Code Modification, Cryptography Our Objective - Explore their Attainment in .NET Apply Similar Framework to J2EE for Comparison SOA+MW-1.122 .NET Security Capabilities CSE 333 Important Initial Definitions Assembly: Refers to Compiler Generated Code, Specifically, Microsoft Intermediate Language (MSIL) Evidence: Refers to the “Proof” that is Supplied Regarding Identity Permissions: Refers to a Privilege that is Given to Perform an Operation on a Resource In the Case of an Assembly, the Permission Set for All Allowable Privileges on All Required Resources We’ll Revisit in Later Slides in more Detail SOA+MW-1.123 .NET Security Execution Model CSE 333 Three Components: Hosting Environment is Attempting to Execute an Application Must Provide Both the Code (Via Assembly) and Its Identity (Via Evidence) in Its Interactions With CLR Common Language Runtime (CLR) Provides a Secure Execution Environment Through Managed Code and Code Access Security CLR Contains the Security System That Realizes Policy Files Comprised of Rules Defined by a Security Administrator (Security Setting) The Rules Allow Permission Sets to Different Types of Code or Users Based on Evidence SOA+MW-1.124 .NET Security Execution Model CSE 333 SOA+MW-1.125 C# vs. Java - Differences/Similarities CSE 333 Class Hierarchies Both have Single Rooted Class Hierarchies System.Object and Java.Lang.Object Both Classes have Methods Sharing Some Similarities and Difference Execution Environment JAVA Compiled to Bytecodes Interpreted or Natively Compiled and Run in Managed Execution Environment JVM C# Code Gets Compiled to MSIL (Microsoft Intermediate Language) which Runs in CLR C# Code is Never Interpreted, it is Always Natively Compiled C#’s MSIL is More Type Neutral SOA+MW-1.126 C# vs. Java - Differences/Similarities CSE 333 Access Modifiers C# access modifier (Continued) Private Public Internal protected internal protected Java access modifier Private public protected N/A N/A Serialization and Documentation C# supports XML format as well as binary format for serialization while Java only supports binary format by default. JAVA uses Javadoc while C# uses XML for documentation SOA+MW-1.127 .NET Security Capabilities CSE 333 Code-based Access Control - CBAC: Giving Permissions at the Code Level to Access Resources Based on the Application Domain That the Code is Assigned to (Information in Evidences) Role-based Access Control - RBAC: Giving Permissions to a User to Access Resources Based on the User’s Role in the System Secure Code Verification & Execution: Similar in Concept to Bytecode Verification in Java, MSIL in .NET Insures That the Executing Code is Staying Within Its Allowed Domain SOA+MW-1.128 .NET Security Capabilities CSE 333 Secure Communication Provides the Ability to Pass Data and Messages Locally or Remotely in a Secure Manner Avoids Both Intentional and Inadvertent Data/message Modification Secure Code and Data Protection: Insures That Code Hasn’t Been Modified Without Authorization Utilizes Cryptographic Solutions and Signed Distribution Files SOA+MW-1.129 .NET Code-Based Access Control CSE 333 The Determination of What a Piece of Code is Allowed to Do is Decided by the Origins and Intentions of the Code Itself Can Be Decomposed Into Evidence Based Security, Permissions, and a Security Policy During Execution, the CLR Reviews Evidence of an Assembly Determines an Identity for the Assembly Looks up and Grants Permissions Based on the Security Policy for That Assembly Identity SOA+MW-1.130 .NET CBAC Evidence Based Security CSE 333 Used by the CLR to Determine the Origin(s) of an Assembly At Runtime the CLR Examines the Meta-data of an Assembly to Determine the Origin of the Code Determine the Creator of the Assembly Determine the URL and Zone That the Assembly Came From A Zone Represents the Domain That the Assembly Is From, E.G., Internet, LAN, Local Machine, Etc. The Association of the Meta-data and Its Corresponding Assembly Is Verified by the CLR SOA+MW-1.131 .NET CBAC Permissions CSE 333 An Assembly will Request Permissions to Execute Requests are Answered at Runtime by the CLR, Assuming that the Assembly Has Provided Evidence Partially Denied Requests; the CLR Dynamically Assigning the Assembly a Lower-level Permission Than Requested Permissions are Grouped Into Sets Where Each Set Has the Same Level of Security and Trust Example: An Assembly that has Originated From the Internet Zone May Be Granted an Internet Permission Set that Pertains to the Execution of Un-trusted Code, Allowing the Behavior of Nonlocal Code to Be Tightly Controlled SOA+MW-1.132 .NET CBAC Security Policies (SPs) CSE 333 The Grouping of Assemblies Establishes Different Security Policies for Different Code Groupings Security Policy Groups Are Hierarchically Categorized Based on the Identity That the CLR Determines From the Evidence in the Meta-data An Actual Security Policy can be Specified As Permissions for All Assemblies in a Group This is Accomplished Using Security Policy Files to Capture Security Requirements A Policy File May Limit the Permissions of Another Policy File, but Can’t Entirely Restrict It SOA+MW-1.133 .NET CBAC Security Policies CSE 333 SP is Set by an Admin to Make Permission Decisions for Assemblies and Domains Three Policies: Total Enterprise, Machine Executing Code, Requesting User Any Policy File May Partially Restrict Permissions of Another Policy File SP Groups Code into Hierarchical Categories Based on Identity Determined by the CLR SP Determines Permissions for Assembly After Code is Grouped and Categorized SOA+MW-1.134 .NET Role-Based Access Control CSE 333 A Role Represents a Logical Grouping of Users (e.g., in a Health Care Application: Physician, Nurse) .NET Uses Role-based Security to Authenticate an Identity and to Pass on That Identity to Resources Resources Authorize the Users Playing Roles Access According to Policies and Permissions Principal Defines a Role Membership, and the Permissions of Role-based Security are Managed by the Principalpermission Object Windows Authentication, Passport Authentication, IIS Authentication, Impersonation Authentication SOA+MW-1.135 .NET Secure Code Verification/Execution CSE 333 Security Checks Verified During the Code Execution: Stack Integrity, Bytecode Structure, Accessibility Buffer Overflows, Semantics ‘Java Sandbox’ of .NET is Called the Application Domain Multiple Assemblies May Be Loaded into the Same Application Domain No Way for an Object to Directly Reference Another Object in a Different Application Domain All of the Security Checks to Verify Code are Done on Managed Code in a the CLR SOA+MW-1.136 .NET Secure Communication CSE 333 Transmission and Communication of Sensitive Data Across Systems Must Be Securely Accomplished Secure Communications Occurs at the Application Level Via SSL and Transport Layer Security (TLS) .NET Applications Can Use the Windows SSPI, but Only As Unmanaged Code With Managed Wrappers .NET Promotes the Exclusive Use of IIS IIS Supports SSL and TLS But IIS has an Extensive History of Security Flaws SOA+MW-1.137 .NET Secure Code and Data Protection CSE 333 Any Code/data Loaded by the System Must Supply Evidence of Its Source, Version Signature Proof That There Hasn’t Been Any Unauthorized Modification .NET Uses Strong-named Assemblies That Include the Assembly Name and Version Information Assemblies Are Signed With an RSA Keypair Nullifying the Chance of Unauthorized Modification Version Information is Included in Order to Avoid DLL Conflicts During Execution .Net’s Encryption Functionality is Tied to the Windows Cryptographic API SOA+MW-1.138 J2EE Security Capabilities CSE 333 Platform Independent Java Bytecode That Is Able to Execute Either Locally or Remotely Bytecode Execution Process Involves a Number of Different Components: The Class Loader (With Bytecode Verifier) Java Class Libraries (Apis) Java Virtual Machine (JVM) Which Interacts With the OS All Three Provide a Secure Runtime Environment The Security Manager and Access Controller Examine and Implement the Security Policy SOA+MW-1.139 J2EE Security Capabilities CSE 333 SOA+MW-1.140 J2EE Code-Based Access Control CSE 333 CBAC Implemented Through the JVM, Class Loader, and the Security Manager and Access Controller. The Hierarchy of the Class Loader Prevents Unauthorized and Untrusted Code From Replacing Any Code in the Base Classes Multiple Class Loaders Are Permitted, Each With Its Own Namespace, Are Simultaneously Active. Namespaces Allow the JVM to Group Classes Based on Where They Originated (Local, Remote) Namespaces Insure an Application Can’t Affect the Rest of the Runtime Environment Bytecode Verifier: All Untrusted Code Is Verified Before Permitting Execution Within a Namespace SOA+MW-1.141 J2EE CBAC: The Security Manager CSE 333 The Security Manager Enforces the Boundaries Around the Sandbox by Implementing and Imposing the Security Policy for Applications All Classes Must Ask the Security Manager for Permission to Perform Certain Operations By Default, an Application Has No Security Manager, So All Operations Are Allowed Java Only Has Two Security Policy Levels, One for the Executing Machine, and One for the User Each Level Can Expand or Restrict All of the Permissions of Another Level There Can Be Multiple Policy Files at Each Level SOA+MW-1.142 J2EE CBAC Permissions CSE 333 Permissions Are Determined by the Security Policy at Runtime Granted by the Security Policy Based on Evidence, a Publisher Signature and Location Origin Permissions Are Also Grouped Into Protection Domains (Similar to Security Policy Domains in CORBA and to Security Policy Files in .NET) Permissions Are Associated With Groups of Classes in Java, and Classes Are Grouped by Their Origins CBAC Isn’t Automatic in J2EE, but Requires Programmatic Effort by the Software Engineer SOA+MW-1.143 J2EE Role-Based Access Control CSE 333 J2EE Uses the Java Authentication and Authorization Service (JAAS) JAAS: an Integrated Package That Implements a Java Version of the Pluggable Authentication Module (PAM) Framework Using JAAS, Software Engineers Are Allowed to Modify and Then Plug-in Domain/application Specific Authentication Modules JAAS Currently Supports Authentication Methods Including Unix, JNDI, and Kerberos SOA+MW-1.144 J2EE Secure Code Verification/Execution CSE 333 J2EE Security Checks Are Performed During the Code Execution Process, and Have Their Roots in the JVM and JRE. Java Interprets Compiled Bytecodes A Bytecode Verifier Traverse the Bytecodes Before It Goes to the Just-in-time (JIT) Compiler or JVM. Java's ‘Sandbox’ Protected Domains, Are Similar to Application Domains in .NET Protected Domains Constitute an Extension of the Sandbox, Determining the Domain and Scope in Which an Application Can Execute SOA+MW-1.145 J2EE Secure Code Verification/Execution CSE 333 Two Different Protected Domains Can Interact Through Trusted Code Explicit Consent of Both Parties (Remotely Possible in .NET) An Object Can Access Another Object in Another Protection Domain As Long As They Were Both Loaded From the Same Class Loader This Is Due to the Hierarchical Class Loader Structure SOA+MW-1.146 J2EE Secure Communication CSE 333 Like .NET, J2EE Supports Secure Sockets Layer (SSL) and Transport Layer Security (TLS) Java Provides Java Secure Sockets Extensions (JSSE) for Implementing Secure Communications JSSE Is a Configurable and Flexible Solution That Uses SSL and TLS to Create a Secure Connection Using Sockets (Sslsocketfactory) The Secure Connection Can Be Used for Remote Method Invocations (RMI) SOA+MW-1.147 J2EE Secure Code and Data Protection CSE 333 J2EE Provides Java Cryptography Extensions (JCE) and Java Cryptography Architecture (JCA) Java Provides the Functionality of a Message Digest Algorithm for Use of Digital Signatures A Supplier Bundles Java Code Into a JAR (Java Archive), Signing the File With a Digital Signature The JAR is Released As a Version, and the Client Can Verify the Authenticity of the Supplier by Verifying the Signature An Unsigned Class May Be Added to a JAR File, but Not to a Package Within a JAR File SOA+MW-1.148 Java CBAC vs. .NET CBAC CSE 333 Permissions Are Grouped Into Protection Domains and Associated W/ Groups of Classes Permissions Are Grouped Into Sets and Associated with Code Groups Classes Are Grouped by Their Origin Like Code Is Categorized by Assembly’s Zone No Security Manager by Default in Java J2EE Has 2 Security Policy Types: Executing Machine & Requesting User .NET Provides a Lot of Standard Permissions Stronger Credentials Needed for Permissions in .NET (Evidence) SP Files Are More Configurable in Java, but Doesn’t Help W/o All Perm Sets SOA+MW-1.149 J2EE RBAC vs. .NET RBAC CSE 333 .Net Supports Both Imperative and Declarative Role Permission Checking Java Servlets Provide Declarative Checking at the Servlet Level EJB’s Provide Declarative Checking Down to Method Level JAAS Provides Imperative Checking Within Method Level .Net Flexibility is Limited Severely IIS is Only Supported Server of .Net Framework Passport Requires Users to Be Members of Microsoft Passport Service SOA+MW-1.150 Code Verification/Execution CSE 333 Prevent System Weaknesses Exposure by Application Errors; Malicious or Not .NET and Java Perform Security Checks During Code Execution Stack Integrity, Bytecode Structure, Buffer Overflows, Semantics Application Domains Have Static Boundaries Protection Domains Have Dynamic Boundaries All Security Checks to Verify Code Are Done on Managed Code Both .NET and Java Allow Unmanaged Code to Bypass the CLR and JRE SOA+MW-1.151 Concluding Remarks CSE 333 Objective of this Material: Detail Security Requirements for Middleware (CORBA’s Meta Model) Illustrate the Realization of the Meta-Model (Microsoft’s .NET and Java’s J2EE) Compare and Contrast .NET and J2EE Touching Only Surface of Capabilities and Functionalities See Paper on Web Site and Various References for Additional Detail SOA+MW-1.152 Interoperability via Architectures CSE 333 Reviewing Simple Architectural Variants Java Client to Legacy Appl. via RDBS ORB Integration of Java Client and Legacy Application Java Client with Wrapper to Legacy Appl. One COTS and One Legacy Appl. to Java Clients Explore Java Based Architectural Variants Two Tier Three Tier Four Tier Pros/Cons – What to Use When? SOA+MW-1.153 Java Client to Legacy App via RDBS CSE 333 Transformed Legacy Data Java Client Updated Data Relational Database System(RDS) Extract and Generate Data Transform and Store Data Legacy Application SOA+MW-1.154 ORB with Java Client & Legacy Application CSE 333 Java Client Legacy Application Java Wrapper Object Request Broker (ORB) CORBA is the Medium of Info. Exchange Requires Java/CORBA Capabilities SOA+MW-1.155 Wrapped Java Client to Legacy Application CSE 333 Java Client Java Application Code WRAPPER Mapping Classes JAVA LAYER Interactions Between Java Client and Legacy Appl. via C and RPC C is the Medium of Info. Exchange Java Client with C++/C Wrapper NATIVE LAYER Native Functions (C++) RPC Client Stubs (C) Legacy Application Network SOA+MW-1.156 Two-, Three-, & Four-Tier Architectures CSE 333 From: http://java.sun.com/javaone/javaone98/sessions/T400/index.html SOA+MW-1.157 Wombat Securities CSE 333 Web Access to Brokerage Accounts Only HTML Browser Required on Front End "Brokerbean" EJB Provides Business Logic Login, Query, Trade Servlets Call Brokerbean Use JNDI to Find EJBs, RMI to Invoke Them Order and History Records from Java Blend Product Records Mapped to Oracle Tables, JDBC Calls SOA+MW-1.158 Four-Tier Architecture Example CSE 333 SOA+MW-1.159 Nocturnal Aviation, Inc. CSE 333 Passenger Check-in for Regional Airline Local Database for Seating on Today's Flights Clients Invoke EJBs at Local Site Through RMI EJBs Update Database and Queue Updates JMS Queues Updates to Legacy System DBC API Used to Access Local Database JTS Synchs Remote Queue With Local Updates SOA+MW-1.160 Three-Tier Example CSE 333 SOA+MW-1.161 Santa Cruz Widgets CSE 333 Small Manufacturer Previously on C++ New Order Entry, Inventory, and Invoicing Applications in Java Programming Language Existing Customer and Order Database Most of Business Logic in Stored Procedures Tool-generated GUI Forms for Java Objects Located Company on Web Using Widgets and Tcl, but Not Widgets and Java SOA+MW-1.162 Santa Cruz Widgets (2-tier) CSE 333 SOA+MW-1.163 Architecture Comparisons CSE 333 Two-tier Through JDBC API: Simplest Multi-tier: Separate Business Logic, Protect Database Integrity, More Scaleable JMS Queues Vs Synchronous (RMI or IDL): Availability, Response Time, Decoupling JMS Publish & Subscribe: Off-line Notification RMI IIOP Vs JRMP Vs Java IDL: Standard Cross-language Calls or Full Java Functionality JTS: Distributed Integrity, Lockstep Actions SOA+MW-1.164